This is a basic question about the preprocessing pipeline in the mrtrix3 manual. There are 6 steps which are easy to follow, however, I just want to confirm before moving ahead to a fixel analysis:
Step 1: dwipreproc <input_dwi> <output_dwi> - Works great and no issues
Question 1: should I be inputing the output_dwi image from step 1 here where it wants the input_dwi or should I be using the same input_dwi from step 1? Basically the same question applies for steps 3 and 4? When the step refers to input_dwi should I be carrying forward my output from the previous step or should I always be using my original dpi_image from step 1?
Looks like the “DWI pre-processing for quantitative analysis” documentation hasn’t been updated properly following prior changes to how the pre-processing is handled - I’ll make sure that’s fixed ASAP, sorry for the confusion.
The dwipreproc script should only be run once, since it deals with eddy current distortion correction, motion correction, and (if such image data are provided) susceptibility distortion correction, all in one hit. The precise usage of the script will depend on the type of DWI acquisition you have performed with respect to variations in EPI phase encoding. Here’s the two most common types of acquisition:
If you haven’t performed any variation in phase encoding, and have just run a single DWI acquisition protocol where all DWIs and all b=0 volumes have exactly the same phase encoding direction and bandwidth, then it’s not possible to correct for EPI susceptibility distortions using FSL’s topup tool. In this case, you would run (example for an A>>P phase encoding direction): dwipreproc AP input_dwi.mif output_dwi.mif -rpe_none
(’-rpe_none’ = ‘No reversed phase encoding’)
If you have acquired a pair of b=0 images, where one of the volumes has the same phase encoding direction and bandwidth as your DWIs and the second has precisely the opposite phase encoding direction (but the same bandwidth), then you would run (again example for an A>>P phase encoding direction in the DWIs): dwipreproc AP input_dwi.mif output_dwi.mif -rpe_pair b0_ap.mif b0_pa.mif
(b0_ap.mif and b0_pa.mif are the b=0 volumes with A>>P and P>>A phase encoding direction respectively, passed to the script using ‘-rpe_pair’ = ‘Reversed phase encode image pair’)
Beware that I’ve completely re-written the dwipreproc script for an incoming update, so this interface will change slightly when that update comes - the documentation and script help pages will be updated accordingly, and I’ll give instructions on this forum when the changes go out with regards to how the usage will change.
For steps 3 and 4 (brain masking & bias field correction), the brain mask should be calculated on the pre-processed DWI (i.e. the output of dwipreproc), and the bias field correction script should be run using the pre-processed DWI from step 2 and the brain mask from step 3. Generally, unless an instruction explicitly specifies that data from a specific prior step should be used, you want to be using the most recent data as opposed to outdated data (‘outdated’ from a processing perspective). For example: in the presence of severe subject motion, one would expect brain masking based on motion-corrected data to work much better than trying to derive a brain mask from image data with significant translation / rotation between image volumes.
Just to be clear: the fundamental operation of dwipreproc won’t be changing; it’s still relying on FSL’s commands to do the heavy lifting, it’s just changed in its design of how it internally generates the required data for those commands to work, and the command-line user interface will change slightly. But there’s no need to hold off on any processing until those changes are pushed, since the results themselves won’t change (that is, unless I get around to getting the script to support eddy's new outlier replacement).