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:
After that, the gradients are flipped. But I also tried the short way:
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? 
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.
Looks like we got a major āgradient handling analysisā ahead of us in MITK 
The original dataset was also generated with MITK, so that fits.
Oops my bad, I thought it was about MRIConvert. Thanks for the pointer!
