I’m working on a DWI dataset which uses a 1.5T scanner, 12 directions, 1 B0 image, and b=1000. I’m interested in voxel-wise regression of the subjects’ FA and ADC map and a cognitive score using TBSS. I did the steps below to generate FA maps:
denoise
dwipreproc
biasfieldcorrection -ants (N4)
mask generation, and manually check
dwi2tensor with -mask option
tensor2metric -fa
mrconvert fa.mif to nii.gz for TBSS
When I started TBSS step 1 and visualize the fa maps, I realized some subjects have white FA maps. I checked for the tensor.mif of those subjects (attached) and they were different from other subjects, although visually bias corrected images were not different. I have two questions:
Are the steps that I did to generate FA maps correct? Do I have to also intensity normalize the data after bias field correction or is this step only required when I have to perfor FBA?
What are the possible reasons/solutions for such white FA maps?
The FA you show indeed looks strange.
The list of steps seems valid, and since it works for other datasets of yours, you probably did it well.
The intensity normalization is not necessary for DTI metrics. The FA would be the exact same when coming from data before or after intensity normalization, as the b0/dwi ratio is unchanged.
I don’t know exactly what is the cause of the strange looking FA.
Perhaps try the dwi2tensor and subsequent tensor2metric at various stages in your pipeline to find out where exactly it goes wrong: on the unprocessed data --> if normal FA, on the denoised data --> if normal FA, on the dwipreprocessed data --> etc.
That is indeed a bit odd. Given that the same exact steps work on other datasets, I’m guessing that the issue must be specific to those datasets. And given that the image contains unexpected contrast for the first component of the diffusion tensor (Dxx), my guess is the DW gradient table is corrupt in some way. Can you tell us more about where the data came from? For example:
What scanner?
Using a product sequence?
Converted from DICOM using mrconvert or some other 3rd party tool?
Who was responsible for the conversion, and did you have any control over that step?
Were the data converted to NIfTI with the DW gradients stored as bvecs & bvals? If so:
Are you using the same bvecs & bvals for all datasets? If so, how confident are you that the DW encoding was in fact always the same?
If you have bvecs/bvals pairs per subject, are you sure you are using the correct one for each subject? Are you confident about where they came from?
Do you have access to the raw DICOM data? If so, does the issue manifest in the same way for these data? If you don’t see the same issue with the raw DICOM, it’s likely that other datasets were also corrupt, but maybe in more subtle ways - I’d recommend starting afresh from the raw DICOM for the whole cohort…
For debugging, I’d follow @tbilliet’s advice: skip all the preprocessing steps - given what your images look like, I don’t expect any of the subsequent steps to introduce this kind of problem… Simply try:
directly from the DICOM folder (if you have it), or directly from the raw NIfTI (along with the -fslgrad bvecs bvals option if required), that’ll give you a quick answer as to whether it works or not…
Thanks Donald and Thibo for your responses.
All data are acquired from MCIC database site A. I did convert the dicom folder into nifti, bvalue and bvector file using dcm2nii, Then convert the resulting .nii into .mif using mrconvert. I’ve noted sometimes “dwipreproc” gives errors if I directly use mrconvert to convert DICOM to .mif; can’t detect the read-out time.
I did dwi2tensor on the raw DICOM/ - and tensor.mif file is attached. Honestly, I decided not to involve those subjects in further analysis but it was totally strange to me.
Just to note that all MRtrix3 commands will happily read your DICOM, NIfTI or mif format images natively – no need to convert to mif if you don’t want to (although I’d of course always recommend it ).
I’ve never heard of that one… Any chance you could provide the terminal output for that failed command?
Ok, that’s even worse than what you showed before… If you open the raw DICOM images using mrview, do they at least look like a brain…? I’m can’t think what could cause the tensor fit to fail so spectacularly…
I’ve noted sometimes “dwipreproc” gives errors if I directly use mrconvert to convert DICOM to .mif; can’t detect the read-out time.
Assuming you’re trying to use the -rpe_header option within dwipreproc, yes it requires that both the (signed) phase encode direction and readout time must be defined in the header. You can run mrinfo on the DICOMs directly and look for the PhaseEncodingDirection and TotalReadoutTime fields to see if they are imported. You may still be able to use dwipreproc in one of the other -rpe_* modes, depending on your acquisition.
While I won’t be able to tell why this import is failing without having access to the raw data (we can only achieve compatibility for data we’ve seen & tested), there’s an outside chance that it may be due to an issue solved within this coming patch. Conversely, if MCIC strip out any CSA headers in the hosted DICOMs, there may be no way to recover this information.
).