search

nipreps / eddymotion

Open-source eddy-current and head-motion correction for dMRI.
https://nipreps.org/eddymotion
Apache License 2.0
13 stars 16 forks source link

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

Open oesteban opened 3 years ago

oesteban commented 3 years ago

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

arokem commented 3 years ago

Voxel coordinates.

oesteban commented 3 years ago

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

arokem commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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.