FDT after mrtrix

1

Hello,

I’m having a volume mismatch between the mrtrix output and the bvec bval files. Here’s what I ran:

mrcat /AP_den_gib.mif /PA_den_gib.mif AP_PA.mif -axis 3; 
dwifslpreproc AP_PA.mif AP_PA_out.mif -rpe_all -pe_dir ap -readout_time 0.05 -export_grad_fsl AP_PA.bvecs AP_PA.bvals

This ran smoothly and I got the results.

I am interested in 2 files the AP_PA.mif and the AP_PA_out.mif. I converted both to .nii
The AP.mif and PA.mif files each has 160 volumes. The AP_PA.nii has 320 volumes as expected, but the AP_PA_out.nii has 160. Is this supposed to be the case? If yes, why?
When I try to run this file “AP_PA_out.nii” in FSL DTIFIT, I get a mismatch between the generated bvec/bval output of the above script and AP_PA_out.nii. The bvec/bval contain the 320 volume info is the reason, but my question is why is AP_PA_out.nii only 160 volumes? also how would I get the bvec/bval for that to use AP_PA_out.nii in FSL DTIFIT?

Thank you in advance.

2

That’s expected. From the description of the dwifslpreproc script:

  • All DWI directions & b-values are acquired twice, with the phase encoding direction of the second acquisition protocol being reversed with respect to the first:
    $ mrcat DWI_lr.mif DWI_rl.mif DWI_all.mif -axis 3; dwifslpreproc DWI_all.mif DWI_out.mif -rpe_all -pe_dir lr -readout_time 0.66
    Here the two acquisition protocols are concatenated into a single DWI series containing all acquired volumes. The direction indicated via the -pe_dir option should be the direction of phase encoding used in acquisition of the FIRST HALF of volumes in the input DWI series; ie. the first of the two files that was provided to the mrcat command. In this usage scenario, the output DWI series will contain the same number of image volumes as ONE of the acquired DWI series (ie. half of the number in the concatenated series); this is because the script will identify pairs of volumes that possess the same diffusion sensitisation but reversed phase encoding, and perform explicit recombination of those volume pairs in such a way that image contrast in regions of inhomogeneity is determined from the stretched rather than the compressed image.

Ok, that probably shouldn’t happen… I’m guessing that’s likely to finally tip @rsmith over the edge.

I’m not sure, but I would guess it would be enough to truncate the files produced at 160 volumes. But that would need to be confirmed…

1 Like
3

Thank you for your comprehensive answer Donald.
Ok, I will wait for the later 2 questions to be answered/confirmed.
Thanks again.

5

@rsmith
I missed to mention that the mrtrix version I use:

== mrconvert 3.0.0 ==
64 bit release version, built Apr 23 2020, using Eigen 3.3.7
Author(s): J-Donald Tournier (jdtournier@gmail.com) and Robert E. Smith (robert.smith@florey.edu.au)
Copyright © 2008-2019 the MRtrix3 contributors.
This Source Code Form is subject to the terms of the Mozilla Public
License, v. 2.0. If a copy of the MPL was not distributed with this
file, You can obtain one at http://mozilla.org/MPL/2.0/.

FSL version 6.0.4

Thanks again.

6

This should be the same issue that was raised on the forum here, appears in the 3.0.1 changelog and was fixed in #2067. Updating the software based on macro versions (i.e. 3.0.x) only brings in bug fixes, and will not change the outcomes of experiments over and above fixing those bugs, so it should be entirely safe for you to update.

2 Likes
7

Thank you Robert. Will update, rerun and circle back if need be.