Hello, mrtrix community! Long story short: dwi.mif and dwi_corr.mif after dwifslpreproc looks exactly the same in regard to the artefacts.
I am new to MRI data analysis and relatively new to using a command line. It is possible that I am missing a small detail.
I have a set of studies performed on a Siemens Skyra MAGNETOM 3T machine with a DTI (ep2d_diff_mddw_30_p2) sequence. To the best of my knowledge, my data is acquired in a single phase encoding direction A>>P with 30 directions of the diffusion gradient. I am working on mac under Mac OS 10.15.7. and mrtrix version 3.0.2.
My aim is to eventually perform a TBSS analysis of this data. This is my typical workflow:
Convert dicom to .nii with MRIcron ignoring derived and 2D images. It leaves me with one DWI file and a set of .bvec and .bval and .json
[WARNING] DWI header indicates no phase encoding contrast between b=0 images; proceeding without inhomogeneity field estimation
and the process goes on. I do not know whether it is a crucial warning. The problem is that the output file I receive has the same alterations in the frontal lobes as the input file.
My understanding is that I have to use slm=linear due to direction of the diffusion gradient is less than 60. I am not sure about my readout time, as I have calculated it to be 48msec and mrinfo says it is 3.7:
Voxel size: 1.71875 x 1.71875 x 5.2 x 3.7
I also try to include as much information as I have into the .mif header. Should I specify anything else for dwifslpreproc to run correctly? As I am not allowed to attach files, I would provide mrinfo output in the comments upon your request.
This is not surprising given that you don’t have the data required to perform that particular step in the correction:
which is confirmed by the warning issued:
The “inhomogeneity field estimation” mentioned here is the step required for the correction of susceptibility induced distortions, which are typically most prominent in the frontal lobes, hence your observation:
When there is no reverse phase encoding direction information, dwifslpreproc can only perform motion correction, eddy-current distortion correction, and outlier detection and replacement (which is already quite a lot!). But it can’t deal with susceptibility-induced distortion without some way of estimating the distortions, which is normally via a reversed phase encoding b=0 scan.
I’m not sure there’s a lot you can do about this, though there are reports of successful distortion correction using other approaches such as registration to a T1 template – but my (limited) experience with these approaches has not been particularly compelling. The synB0-DISCO approach is also worth looking into if you really need to correct for these artefacts (not as strong a requirement for TBSS as it would be for tractography, to be fair).
Oh, I am so relieved by your reply. Thank you! My misconception was that frontal lobe artefacts could still be corrected without the second phase encoding direction. And there is definitely room for improvement of our DWI protocol.
In the next minor MRtrix3 update (i.e. 3.1.0), dwifslpreproc will get the command-line option -topup_files, which should allow users to run synB0-DISCO independently and then feed its output to dwifslpreproc. This is already on the dev branch for anyone needing the functionality who doesn’t mind playing with git branches.
Please confirm in the terminal output from dwifslpreproc that “--slm=linear” is in fact specified to eddy. I’ve had issues with the Python argparse module where providing just one option within quotation marks like that results in the contents disappearing, and adding an otherwise-useless space at the start or end of the contents of the quotation marks is necessary.
My understanding is that I have to use slm=linear due to direction of the diffusion gradient is less than 60.
I’m not sure whether that specific advice has been provided here or elsewhere. My understanding is that that option should primarily be used when the diffusion sensitisation directions are distributed over a half-sphere rather than the full-sphere. I can see how it would potentially be useful to include with a smaller number of directions, so it may well be valid advice, I just don’t recall having come across it.