I used dwi2preproc to perform eddy correction for my diffusion data, as well as the automatic rotation of b_vectors with noclearnup command. Then I used new rotated b-vector to calculate diffusion tensor. But I got worse primary enginevector image when I overlapped FA map with V1 image (see below). After compared the raw and new files, I found the only changed thing is the values of three dimensions within b-vector txt.
Any suggestions would be appreciated. Thanks in advance!
Sounds to me like this might be related to this issue. Are you using an up-to-date version of MRtrix3? Are you processing data converted by a previous installation of MRrix3, which you have since updated? The problem is that in many cases, the bvecs written out by version 0.3.13 or earlier would be inverted with respect to the x-axis (which is the simplest explanation for what you’re showing), and if subsequently read by a later version, those directions would then be wrong. Note that the direction would appear fine if you used the same version to read and write these data, since the directions would be read with the same convention as they were written - it just happened to be the wrong convention…
If that’s the case, the simplest fix is to invert the x-component of your bvecs file (the first row).
I think the problem might be here (i.e. not an MRtrix3 versioning problem):
I used dwi2preproc to perform eddy correction for my diffusion data, as well as the automatic rotation of b_vectors with noclearnup command. Then I used new rotated b-vector to calculate diffusion tensor.
dwipreproc script will automatically make use of the rotated diffusion gradient table (if it is provided by
eddy), importing it into the final image series as output by
dwipreproc. That rotated bvec file is only valid when used in conjunction with the NIfTI image that is provided as the output from
eddy. If you use the
-nocleanup option in
dwipreproc, and manually associate the raw bvec file output by
eddy with an image that has data strides that do not match the NIfTI image output by
eddy, then that bvec file will be interpreted incorrectly; and you end up with FODs pointing in the wrong directions, as per your image.
dwipreproc script immediately imports the rotated bvec file from
eddy back into the image header in MRtrix format. So if the output of
dwipreproc is in an MRtrix format, the rotated gradient table will be present in the image header. If you use the
-export_grad_fsl options in
dwipreproc, it is the rotated gradient table that will be provided to you. But importantly, even with use of
-export_grad_fsl, the generated bvec file is only valid when used in conjunction with the image series output by