B.A.T.M.A.N attempt

Hello. Lengthy post warning!
I’m trying to create a pipeline for my DTI-data through the use of the B.A.T.M.A.N- tutorial. I’ve come across some challenges, though. I’m sorry for the many different questions.

My raw DTI-series is acquired PA, along with two separate reference b0-acquisitions;AP and PA, respectively. B-values: 0 and 1000.

I’ve done the following:

mrconvert DTI.nii.gz -fslgrad bvecs bvals DTI.mif
dwidenoise DTI.mif DTI_den.mif -noise noise.mif
mrcalc DTI.mif DTI_den.mif -subtract residual.mif

#The residual map clearly depicted the large ventricles; what does that imply? And for the noise; how do you evaluate that?

mrcalc DTI_den.mif DTI_den_unr.mif -subtract residualUnringed.mif

#how to evaluate this?

dwiextract DTI_den_unr.mif - -bzero | mrmath - mean mean_b0_PA.mif -axis 3    
mrconvert AP.nii.gz AP.mif
mrcat mean_b0_PA.mif AP.mif -axis 3 b0_pair.mif 
dwifslpreproc DTI_den_unr.mif DTI_den_unr_preproc.mif -pe_dir PA -rpe_pair -se_epi b0_pair.mif -nocleanup

#should I run -eddy_options " --slm=linear" here? Or “-eddyqc_*”?

#I didn’t run dwibiascorrect… pros and cons for this?

dwi2mask DTI_den_unr_preproc.mif mask_den_unr_preproc.mif
mrview mask_den_unr_preproc.mif -colourmap 2
dwi2response dhollander DTI_den_unr_preproc.mif wm.txt gm.txt csf.txt -voxels voxels.mif
mrview DTI_den_unr_preproc.mif -overlay.load voxels.mif

#I understood from a previous post of mine that the gm-file should be ignored in the subsequent analysis. Should I have run this command without it? The dots representing WM and CSF- voxels appeared similar as in the tutorial, whilst the GM-voxels appeared in slightly different locations than in the tutorial, yet still in what appeared to be GM.

shview wm.txt
shview gm.txt
shview csf.txt

#These looked similar to the response functions in the tutorial

dwi2fod msmt_csd DTI_den_unr_preproc.mif -mask mask_den_unr_preproc.mif wm.txt wmfod.mif csf.txt csffod.mif
mrconvert –coord 3 0 wmfod.mif -| mrcat csffod.mif  –vf.mif

#I couldn’t get the quality control of the FOD-etimation to work (Figure 7, p.13-14).I removed gmfod.mif from the command since I don’t have it, I suppose that is why I can’t seem to get the quality control up-and- running, or? I got multiple errors.
It is unfortunate not to be able to achieve GM-status, I am really insecure about how to proceed.

mtnormalise wmfod.mif wmfod_norm.mif csffod.mif csffod_norm.mif -mask mask_den_unr_preproc.mif

#I removed gmfod.mif gmfod_norm.mif from the command.

mrconvert T1.nii T1.mif
5ttgen fsl T1.mif 5tt_nocoreg.mif

#A black hole appears above the right ventricle; as if some mistake has occurred during segmentation. What have I done wrong/could I have done differently? It should be noted that the ventricles in this case are slightly enlarged. Could that be of influence?

dwiextract DTI_den_unr_preproc.mif - -bzero | mrmath - mean mean_b0_preprocessed.mif -axis 3
mrconvert mean_b0_preprocessed.mif mean_b0_preprocessed.nii.gz
mrconvert T1.mif T1.nii.gz
flirt -in mean_b0_preprocessed.nii.gz -ref T1.nii.gz -dof 6 -omat diff2struct_fsl.mat
transformconvert diff2struct_fsl.mat mean_b0_preprocessed.nii.gz T1.mif flirt_import diff2struct_mrtrix.txt
mrtransform T1.mif -linear diff2struct_mrtrix.txt -inverse T1_coreg.mif
mrtransform 5tt_nocoreg.mif -linear diff2struct_mrtrix.txt -inverse 5tt_coreg.mif
mrview DTI_den_unr_preproc.mif –overlay.load T1.mif –overlay.colourmap 2  -overlay.load T1_coreg.mif –overlay.colourmap 1

#I get the following error when I try to run the last command for mrview: “Error. Options must appear after the last argument”. When manually opening the three images, it looks as if the T1coreg has been somewhat angled compared to T1.mif and DTI_den_unr_preproc.mif. It looks as if the T1 and DTI are acceptably aligned, with the T1coreg being lowered. If that makes sense.

5tt2gmwmi 5tt_coreg.mif gmwmSeed_coreg.mif
mrview DTI_den_unr_preproc.mif -overlay.load gmwmSeed_coreg.mif

#As mentioned and as a result of the above; the gmwmSeed_coreg overlaid on the DTI appears lower and not “in the right place”. In addition some skull is included in the seed.

Well, a long one. Thank you so much for any input and your time!

Hi @Jolie,

#The residual map clearly depicted the large ventricles; what does that imply?

Depends on how clear the depiction was. In the ideal scenario the residual image would be structure-less; this is regularly not the case though, there will commonly be some anatomical structure in there. The question is whether the difference in magnitude of the residuals is so different between different anatomical regions that it is indicative of either some inherent bias in your data that the denoising algorithm is correctly identifying, or that the denoising algorithm is going awry. This is impossible to know without seeing the data.

Also bear in mind that based on the provided commands you are likely looking at the residuals of just the first volume, which may be a biased exemplar of the whole dataset. If you want e.g. the RMS of the residuals, this is something that needs to be calculated explicitly.

And for the noise; how do you evaluate that?

Depends on what you want to “evaluate”. As with the residuals, one expects a smooth map if all is working correctly; if there’s a voxel for which the estimated noise level is way larger / smaller than its neighobours, that would suggest there’s something awry with either the data or the estimation procedure. If you’re interested in whether the noise in your data is larger or smaller than in other acquisitions, or whether the spatial profile of the noise level is different for your receiver coil set than another, that’s a whole experiment in and of itself.

#how to evaluate this?

Again, depends on your intentions. If you don’t know the particulars of how the Gibbs ringing removal algorithm works, and wouldn’t know what to do if there were something wrong let alone how to assess such, then calculating the residuals is probably just something you can do, in order to convince yourself that the algorithm is doing something as opposed to nothing. But if it were super crucial to critically assess such before proceeding, then the documentation would likely provide greater detail on such.

#should I run -eddy_options " --slm=linear" here?

Generally the recommendation here has been based on whether or not the acquisition scheme is distributed equally around the full sphere or only on a half-sphere. See e.g. this thread (note how much harder it is to find relevant information when threads deviate from the original topic title!). If dirstat reports the scheme as being asymmetric, it’s likely worth including.

Or “-eddyqc_*”?

It’s much easier to provide -eddyqc_* and not use the resulting data than to not use it and then discover that you would like those data.

#I didn’t run dwibiascorrect… pros and cons for this?

The discussion comes up on a regular basis here. In general any bias field correction applied here will likely become redundant once mtnormalise is applied; but if your brain mask is particularly bad due to the presence of a bias field, then running dwibiascorrect prior to brain masking might help; conversely, dwibiascorrect can also introduce brain masking issues. So just assess its influence on your own data.

#I understood from a previous post of mine that the gm-file should be ignored in the subsequent analysis. Should I have run this command without it?

The dwi2response dhollander algorithm always outputs three response function text files. If you specify only two, it will give you an error. But if you have only single-shell data, the suggestion is to only utilise the WM and CSF responses.

#I couldn’t get the quality control of the FOD-etimation to work (Figure 7, p.13-14).I removed gmfod.mif from the command since I don’t have it, I suppose that is why I can’t seem to get the quality control up-and- running, or? I got multiple errors.

That particular command:

mrconvert –coord 3 0 wmfod.mif - | mrcat csffod.mif gmfod.mif – vf.mif
mrview vf.mif –odf.load_sh wmfod.mif

is not going to give the same result by simply omitting the GM ODF image. The purpose of the mrcat command here is to produce a 4D image containing 3 volumes, which mrview then automatically interprets as an RGB image and displays it accordingly. If you omit the GM ODF image, you end up with a 4D image containing 2 volumes, and mrview will just display the first of those two volumes. If you wanted to achieve a similar result, i.e. an RGB image with CSF as red and WM as blue, you would need to replace the GM ODF image in that command with an image containing all zeroes.

#A black hole appears above the right ventricle; as if some mistake has occurred during segmentation. What have I done wrong/could I have done differently? It should be noted that the ventricles in this case are slightly enlarged. Could that be of influence?

It’s interesting that you would have such an issue arising from 5ttgen fsl, since it internally uses FSL’s bet to derive a brain mask, and that’s based on constructing a bound surface rather than an intensity-based segmentation. Is it truly a “hole”, in that it’s a region outside the mask fully enclosed by voxels that are inside the mask? Or is it more so that a large portion of the brain is excluded from the mask as that outer surface encroaches into the brain?

5ttgen fsl provides the -mask / -premasked command-line options. If the internal brain masking doesn’t work, try deriving a brain mask for the T1-weighted image using some other means, and then either providing that image using the -mask option, or if the result of your masking approach is a T1-weighted image where non-brain voxels contain the value zero, use the -premasked option.

#I get the following error when I try to run the last command for mrview: “Error. Options must appear after the last argument”.

This will most likely be the suddenly-ubiquitous UTF-8 dash issue. Replace all occurrences of dashes in the copy-pasted command with a manually-typed “-” symbol.

(The reason that particular error is raised is because it thinks that “–overlay.colourmap” is an input image rather than an option, and that therefore you’ve specified command-line options before input images, which isn’t permitted in mrview)

When manually opening the three images, it looks as if the T1coreg has been somewhat angled compared to T1.mif and DTI_den_unr_preproc.mif. It looks as if the T1 and DTI are acceptably aligned, with the T1coreg being lowered.

Registration issues are always difficult to diagnose remotely. The first thing I would do is restart from the flirt call, but in addition to exporting the transformation matrix, also ask flirt to output a transformed image that has been resampled onto the voxel grid of the target image. If this image aligns nicely with the target image, then the registration worked OK and there’s some issue with the subsequent commands; if it’s misaligned, then the issue is the registration itself and the subsequent commands are red herrings. If inter-modal registration goes awry I personally instead use brain-extracted images, since otherwise image content outside of the brain can drive the image alignment process in ways that may seem bizarre, but that nevertheless optimise what the registration algorithm is optimising.

Cheers
Rob