Gradient orientation after alignment of (NIFTI) DWI data to structural data

1

Dear mrTrix3 experts,

I have aligned a DWI dataset to a whole-head anatomical volume and would like to run a CSD and tractography analysis (dwi2response, dwi2fod, ) on it. My question is how to ensure that the gradients are correctly oriented after applying the alignment to the DWI data header and whether this should be done in NIFTI or MIF format, because this seems to give different results.

My DWI data are in NIFTI format. I’ve ran FSL topup/eddy on the unaligned DWI data and i’m using the rotated bvecs output by FSL eddy. Then I computed the alignment between the eddy/motion-corrected DWI data and the structural data (not using FLIRT) and got the transformation matrix in a text file. If I now want to apply this alignment to the DWI using mrtransform, what’s the best way to do it?
Option 1: I apply the linear transformation to the NIFTI DWI file using mrtransform and then convert it to MIF format (with the -flsgrad option to include my bvals and bvecs in the header).
Option 2: I convert my NIFTI DWI file to the MIF format (also using the fslgrad option) and then applied the linear transformation.

The transformation matrix of the aligned MIF files returned by mrinfo is identical in both cases. However when I extract the gradient orientation from the aligned NIF files using mrInfo, or when I look at the FOD orientations after running the CSD analysis, the orientations are different. I don’t understand why this is happening.

An alternative would be to do the CSD/tractography analysis on my original unaligned DWI data and then align the resulting FODs to the structural data. This is not ideal though because this means that everytime I re-compute the FOD (I want to compare different algorithms), I need to re-align the resulting FOD, whereas if I can correctly align the gradient orientation to the DWI image to start with, I won’t have to worry about it… (Yet another alternative would be to align the structural data to the DWI data instead of the other way around, but I’d rather have everything in the space as the structural image).

In order to illustrate the difference between options 1 and 2 above, I’m attaching the resulting FOD overlaid onto the DWI after applying a 40 deg rotation around the Y axis (I used this instead of my actual alignment so that the difference is obvious).
Upper left is the FOD computed from the unaligned DWI (overlaid on the unaligned DWI), upper right is the same FOD rotated by 40 deg using mrtransform (overlaid on the rotated DWI). I’m assuming this gives the correct result: colors have changed and reflect the 40 deg rotation, but the FOD still have the expected orientation relative to the (rotated) DWI.
The bottom panels show the FOD correspond to option 1 (left) and 2 (right), both overlaid on the rotated DWI data.

mrTrixAlignmentProblems.jpg1660×1216 604 KB

Option 1 gives the same results as rotating the FOD, so this suggests that it is the correct method. I find this difficult to understand. If anything, I would have expected that option 2 would be more likely to be correct (since mrtransform is applied to the MIF file which contains the gradient orientations in its header and presumably should rotate them accordingly)?

Sorry for the long message and thanks in advance for any insight.
Cheers

Julien

2

OK, that clearly shouldn’t happen! mrtransform is indeed supposed to handle this internally, but it seems it’s applying the inverse of the transformation to the gradients compared to what it’s doing to the image. A quick look at the history suggests that this bug might have been introduced when the convention for the -linear transform switched from a forward mapping to an inverse mapping, to make the interface consistent between header-only changes and operations that require regridding. Unfortunately that change wasn’t propagated to the DW transformation, so that the net effect is that the inverse transformation is applied to the image header, and the forward to the DW directions. Sorry about that, we’ll fix that ASAP.

The reason that your option 1 works is because the bvecs are specified relative to the image axes, so will ‘move’ along with the image as it’s rotated. As long you don’t modify the strides of the image as you do this, then it just works. This is one of the advantages of the bvecs format - you can’t do this with the MRtrix format encoding, as the DW directions are specified relative to the scanner coordinate system, so will have to change if the image is rotated. This is what mrtransform was supposed to deal with seamlessly…

Thanks for reporting this, we’ll get that fixed now.

3

I just committed the fix, things should work as expected now after a git pull && ./build. Thanks for reporting, it’s always appreciated!

4

No problem. I checked and I now get the expected result. Thanks for fixing!

5

Hi julien，
I want to rotate my fod picture with some degrees around the y and z axis，just like your 40 degrees，so could you please tell me how to use the “mrtransform”command to do it？
Thank you so much！
Cheers，
Liang

6

The mrtransform command should do it by default if it detects a number of volumes compatible with an FOD image. See mrtransform’s -noreorientation option for details.

Note that this behaviour will change for the next release: reorientation won’t be done by default, the user will need to specify if reorientation is desired.