Closed zaccharieramzi closed 3 years ago
Yeah, I'm having trouble remembering why exactly I had that line. It could be that I was working with data with some other dimension, or maybe I put it in to handle lists and multiple variably-sized k-space trajectories.
You might be able to get a 3D version just by replacing with -3
, assuming you are using a 3D radial trajectory (i.e., a "koosh-ball") with an even distribution of 3D angles. If you have some other 3D trajectory then you may need to look into the literature.
Ok thanks for the feedback.
Well so far I used this density compensation scheme also for spiral trajectories in 2D and it seemed to work fine, at least in an unrolled architecture.
I think it might not be the same story indeed for stacks of radial/spiral or even SPARKLING.
If you don't want to address this feel free to close the issue.
If you have something from the literature to add I think it would be nice, but I'm unable to add it at the moment.
There is a fair amount of research on spiral density compensations (I think this one is famous).
For stacks of radial you can use the one in the package - the Cartesian dimension doesn't require density compensation.
For now I will leave the issue open in case someone wants to Pull Request something in.
Hi,
I am interested in the way you implemented density compensation. On this line, you use
[-2:, ...]
on a tensor that is of shape[2, 324000]
. Therefore I don't understand the use of slicing in this instance.The reason I want to know more is because I want to use density compensation in 3D, and I think that in the current state, this slicing is preventing it. Other than that, do you see any reason why the current density compensation wouldn't work well for 3D trajectories?