I have some questions regarding certain pre-processing tools for diffusion data in mrtrix3.
I have read the description of ‘dwipreproc’ which states that its uses FSL tools to perform eddy correction and inhomgeneity distortion correction.
I was wondering, does it also perform intensity normalization?
Also there other tools such as ‘dwiintensitynorm’ and ‘dwinormalisation’. What is the difference between them, as they both say they perform intensity correction?
Does ‘dwinormalization’ perform intensity correction only for b=0 signal while the former performs it on other subjects too (globally)?
And what is the difference between ‘dwibiascorrect’ and inhomogeneity correction with ‘dwipreproc’ ?
Also can ‘mrinfo’ provide information about phase encoding. For instance if you receive data from third party how can you determine the acquisition phase encoding details then ?
Can one perform intensity correction for the single .mif file instead of providing input directory and the corresponding individual masks?
Numbered your questions to save the long re-quoting
No. dwipreproc purely deals with image pre-processing that is requisite for any DWI analysis. Since intensity normalisation is not strictly necessary for all possible applications (and there isn’t yet a single unambiguous “correct” way for it to be done), it’s best handled as its own explicit step.
dwinormalise computes the median b=0 value within a mask, compares it to a “target” intensity (default 1,000), and multiplies the whole volume by their ratio, such that the median b=0 value in the output image is equal to the target intensity. dwiintensitynorm performs this process across a cohort, importantly including derivation of the masks that are to be used. So you can think of dwinormalise as being the “workhorse” of dwiintensitynorm. If you’re only interested in applications rather than development, most likely you can ignore the existence of dwinormalise.
dwinormaliseapplies the correction to all DWIs; but the requisite multiplicative factor is calculated based on the b=0 intensity.
dwibiascorrect corrects for B1 image intensity innhomogeneity. dwipreproc corrects for geometric distortions due to B0 field inhomogeneity & use of EPI readout.
If you are using a Siemens scanner, are using MRtrix3 version 3.0_RC1 or updates thereof, and have not used any non-MRtrix3 tools or image formats in between DICOM conversion and your images of interest, then yes you may be able to see the phase encoding information. Some technical details here; I probably need to write a documentation page on it at some point. Look for header key-value entries “PhaseEncodingDirection”, “TotalReadoutTime” or “pe_scheme” in the mrinfo output.
Depdns on what you mean by “intensity correction”. dwinormalise is probably the functionality you’re looking for; the disadvantage here is the requirement of defining a mask within which to sample the b=0 image values for determining the multiplicative factor to apply. dwiintensitynorm makes this process more robust by defining a WM mask on a population template FA image, and warping this mask back to individual subject DWIs, rather than trying to derive a mask individually per subject (which may introduce a bias).
dwiintensitynorm makes this process more robust by defining a WM mask on a population template FA image, and warping this mask back to individual subject DWIs, rather than trying to derive a mask individually per subject (which may introduce a bias)
Just to clarify, if I have 10 DWI subjects, each with 126 directions and 5 b-values.
Then dwiintensitynorm defines a WM mask on this population template FA image and warps this mask back to individual subjects.
Cause I have been trying to use this mrtrix function and it is asking me to input the mask.
Cause I have been trying to use this mrtrix function and it is asking me to input the mask.
The dwiintensitynorm script requires a brain mask to be provided for each subject. This is different to the white matter mask that dwiintensitynorm itself calculates and then propagates back to each subject. At least I think this is the issue you’re encountering; it’s always much more clear for us if you can provide the actual error message reported at the command-line, rather than your interpretation thereof.
