Mrconvert flips gradients

Hi everyone,

I just realized that when converting a diffusion weighted image volume from nifti to mif and back again, the resulting bvecs are flipped: (x,y,z)->(x,-y,-z).
Is this a known issue? Btw. I used the ISMRM tractography challenge dataset and wanted to perform CSD (http://www.tractometer.org/ismrm_2015_challenge/).

Peter

There’s many ways something like this might happen, without it necessarily being a bug. Can you copy and paste the exact commands that you used so we can reproduce and investigate?

Here are my commands:

  • mrconvert Diffusion.nii.gz dwi.mif -fslgrad Diffusion.bvecs Diffusion.bvals -datatype float32 -stride 0,0,0,1 -force
  • dwidenoise dwi.mif dwi_denoised.mif -force
  • dwipreproc -rpe_pair phase0.nii.gz phase1.nii.gz AP dwi_denoised.mif dwi_denoised_corrected.mif -force
  • mrconvert dwi_denoised_corrected.mif dwi_denoised_corrected.nii.gz -export_grad_fsl dwi_denoised_corrected.bvecs dwi_denoised_corrected.bvals -force

After that, the gradients are flipped. But I also tried the short way:

  • mrconvert Diffusion.nii.gz dwi.mif -fslgrad Diffusion.bvecs Diffusion.bvals -datatype float32 -stride 0,0,0,1 -force
  • mrconvert dwi.mif dwi.nii.gz -export_grad_fsl dwi.bvecs dwi.bvals -force

Same result.

I can’t reproduce this on my end… Based on the second (shorter) approach, can you post the output of:

mrinfo Diffusion.nii.gz
mrinfo dwi.mif
mrinfo dwi.nii.gz

and also the version of MRtrix3 you’re using:

mrconvert -version

I’m wondering whether this might have something to do with the bvecs convention issue that we fixed back in April…?

Also, when you say the gradients are flipped, how are you assessing this exactly? Are you talking about the contents of the bvecs files themselves, or the way they are interpreted either within FSL or MRtrix3? This matters, since the image strides will generally affect how the bvecs are to be interpreted (and hence how they should be modified to preserve consistency). Bear in mind that modifying the strides in a NIfTI image is accomplished by modifying the transform (sform/qform) via 90°/180° rotations, etc., so this type of modification will typically require modification of the bvecs to match.

For MRtrix3, you can check consistency relatively easily using these commands:

mrinfo Diffusion.nii.gz -fslgrad Diffusion.bvecs Diffusion.bvals -dwgrad | head
mrinfo dwi.nii.gz -fslgrad dwi.bvecs dwi.bvals -dwgrad | head

That’ll just produce the first 10 lines of the DW scheme as understood by MRtrix3, in real/scanner coordinates. You just want to check that you get the same result in both cases (within numerical precision).

Assuming you’re using a recent build of MRtrix3, I’m fairly confident that will match up with FSL’s interpretation, we spent quite a bit of time making sure that was the case back in April. Clearly, if that’s not true, we’ll want to fix that ASAP…

Found the problem. It was not an mrtrix issue. The gradients were already flipped in the “original” image. I just assumed it had to be an issue in the proecssing pipeline because everything looked fine when I visualized the tensors of the original image in MITK. Looks like MRtrix is handling the gradient directions differently. The CSD ODFs reconstructed and visualized in MRtrix are flipped, regardless of mrconvert usage, but the ODF visualization in MITK looks just fine.

Bottom line, no flipping in mrconvert. I just didn’t check that thoroughly. My bad.

OK, good to hear. Sounds like MITK might suffer from the same issue we had - might be worth double-checking and feeding this information back to them. What the issue boils down to is now documented in the FAQ section of the FSL wiki (this was added in response to our interactions with them about this very issue):

The bvecs use a radiological voxel convention, which is the voxel convention that FSL uses internally and originated before NIFTI (i.e., it is the old Analyze convention). If the image has a radiological storage orientation (negative determinant of qform/sform) then the NIFTI voxels and the radiological voxels are the same. If the image has a neurological storage orientation (positive determinant of qform/sform) then the NIFTI voxels need to be flipped in the x-axis (not the y-axis or z-axis) to obtain radiological voxels.

It’s not obvious how to figure out whether your image is stored in ‘neurological’ or ‘radiological’ convention (these are grossly misleading terms since they should apply to the image display only, but are unfortunately commonly used in the context of image storage). Thankfully, they do state what they mean by that: negative determinant of the qform/sform. In other words, ‘neurological’ refers to the image axes forming a right-handed coordinate system, which is the default case in NIfTI (i.e. what you get with an identity transform/sform/qform). On the other hand, ‘radiological’ refers to the image axes forming a left-handed coordinate system, which implies that one of the axes has been mirrored (in the old Analyse format, that would have typically been the x-axis).

So you can check whether your images were stored in neurological convention using mrinfo by looking at the strides:

$ mrinfo image.nii
...
  Data strides:      [ 1 2 3 ]
...

In this example. this states that voxels are stored along +x, +y, then +z, forming a right-handed coordinate system: this would mean that the x component of the bvecs needs to be inverted, since this is ‘neurological’. Other right-handed cases entail basically any permutation of the default [1 2 3] strides that involve only a cyclic rotation and/or the simultaneous inversion of 2 axes (e.g. [ 2 3 1 ], [ -1 -2 3 ], [ 3 1 2 ], …). Any non-cyclic permutation or inversion of a single axis leads to a left-handed coordinate system (e.g. [ -1 2 3 ], [ 1 3 2], [ 2 3 -1 ], …), which would not require the x-component of the bvecs to be inverted.

Piece of cake, right? :wink:

Nice to know about this issue of mriconvert!

I tried in the past to use mriconvert to extract DTI and bvecs gradients, but I found out that it’s not reliable, because apart from the flipping that I did not notice, there is also an issue of rounding (compare the bvecs generated by mriconvert and mrtrix3, you will see that mriconvert rounds up too much and you thus lose a lot of precision).

I’m a bit confused… What’s this got to do with MRIConvert? I thought the issue was with MITK? Were the images imported via MRIConvert first?

If so, that matches our previous (limited) experience with MRIConvert (discussed here) - we encoutered quite a few issues with that particular converter. FSL themselves recommend dcm2nii, and that certainly did a much better job of it…

Yep, I’ve noticed this before with that particular dataset: the x component is flipped in the bvecs (or equivalently, the y and z components). So whatever was used to generate the final dataset, suffered from the problem @jdtournier described (and whatever shows the dataset out of the box “correctly”, also suffers from it).

Here’s a screenshot of the ground truth data (without all the simulated artifacts), simple mrconvert ... -fslgrad ... from the data and bvecs/bvals to “dwi.mif”, and then opened that one up in the viewer and amplitude display tool. Region at focus is the genu. Notice in the sagittal view the fornix looks ok. But in both coronal and axial views the genu doesn’t. So x-flip it is. :wink:

Looks like we got a major “gradient handling analysis” ahead of us in MITK :slight_smile:
The original dataset was also generated with MITK, so that fits.

1 Like

Oops my bad, I thought it was about MRIConvert. Thanks for the pointer!