Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DIPY's gradients tables -- scanner or voxel coordinates? #3

Open
oesteban opened this issue Apr 13, 2021 · 5 comments
Open

DIPY's gradients tables -- scanner or voxel coordinates? #3

oesteban opened this issue Apr 13, 2021 · 5 comments
Assignees
Labels
bug Something isn't working

Comments

@oesteban
Copy link
Member

Question for @arokem: just to be sure, what are the coordinates DIPY expects?

  • scanner (like MRTrix)
  • voxel (FSL bvec/bval)
@arokem
Copy link

arokem commented Apr 13, 2021

Voxel coordinates.

@oesteban
Copy link
Member Author

Good to know. Does it convert it to scanner coordinates internally?

@arokem
Copy link

arokem commented Apr 14, 2021

No. I might be misunderstanding, though. DIPY doesn't automatically do anything with the gradient directions. So, if you give it bvecs in world coordinates it will retain those coordinates. The GradientTable class doesn't have any knowledge of the transforms associated with the data, so it is up to the user to bring the bvecs and the data in register. Does that answer your original question?

@oesteban
Copy link
Member Author

I might be the one who misunderstands the problem itself. AFAICT, scanners differ on how you write in the gradients table and how they store it in the DICOM structure.

I believe that GE, for instance, uses voxel coordinates. But Siemens uses scanner coordinates.

When fitting the model, if the coordinate system is based on each voxel, then obviously, the voxel coordinates should be used for the gradients.

However, if the model is implemented with world (or scanner, or physical) coordinates, then you need to make sure there is no rotation of the image's coordinate system. If there's no such a rotation (or more exotic possibilities like diamond-shaped voxels), then you'd be fine. But the rotation will definitely confuse the model.

And, with parallel imaging and current EPI sequences, having rotated orientations is pretty common.

@arokem
Copy link

arokem commented Apr 14, 2021

However, if the model is implemented with world (or scanner, or physical) coordinates, then you need to make sure there is no rotation of the image's coordinate system. If there's no such a rotation (or more exotic possibilities like diamond-shaped voxels), then you'd be fine. But the rotation will definitely confuse the model.

That's exactly right: the user needs (or here, we need) to make sure that the b-vectors end up in the right coordinate frame before giving them to DIPY. DIPY will not do any of this for us.

@oesteban oesteban self-assigned this Apr 22, 2021
@oesteban oesteban added the bug Something isn't working label Apr 22, 2021
@oesteban oesteban transferred this issue from nipreps/eddymotion Dec 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants