Hi all,
I just noticed that the -export_grad_fsl option of mrinfo gives a different output than the one in mrconvert. Is this known?
mrconvert dwi.mif dwi.nii.gz -export_grad_fsl bvecs.txt bvals.txt
gives rounded bvalues, and slightly different gradients (perhaps not normalized?) than the output from
mrinfo dwi.mif -export_grad_fsl bvecs.txt bvals.txt
Now, in se that’s not an issue, although it’s not intuitive.
The issue is that I have a dataset for which in the bvals.txt file the b-value of the last image volume is 800 for mrconvert, while in the bvals.txt from mrinfo that b-value is 0. That’s quite a difference. For both versions the gradient directions are all 0.
The volume does not seem to have the intensities of a b=0 volume, but there is also no clear direction of diffusion gradient visible. I furthermore notice that dcm2nii (mricron) and MRIconvert both discard this last image volume when converting from dicom to nifti, so maybe it shouldn’t have been in the dwi.mif anyway. Is this a known phenomenon?
The data comes from a 3T Philips Achieva and I’m using mrtrix version 0.3.15-477-g55c72229
Cheers,
Thibo
Hi Thibo,
The different output you get from mrinfo and mrconvert is known. Even more, it’s intentional: mrinfo aims to export the gradient table in a format as closely related to the input image as possible, whereas mrconvert exports the gradient table to match with the output image. If you convert between file types and associated axes conventions (such as going from .mif to .nii), or select a subset of the diffusion volumes, this makes a difference.
The specific issue you describe is indeed counterintuitive. In this instance, mrconvert prepares the gradient table for the output .nii format by rescaling the b-values with the norm of the gradient direction vectors, which in your case results in 0. I am a bit surprised to see that mrinfo does not do this too; in my mind the difference between both should only relate to the gradient directions, not to the b-values.
However, I wonder if, at te end of the day, it matters in your case. What use is a b800 image if you don’t know what gradient direction was used? I’d say you either discard it, or dive in the DICOM headers to figure out what it is. Could it be a trace map with isotropic diffusion weighting perhaps?
Cheers,
Daan
That’s exactly what this is. Philips have a habit of adding that image at the end of the series for some reason (on Siemens, this type of image would be added as a different series altogether). It shows up as a volume with a zero direction vector, but a non-zero b-value. It would be discarded by any MRtrix3 application that makes any interpretation of the DW gradient table, so that it doesn’t interfere in tensor or other calculations. I guess other converters simply discard the volume wholesale, which does have the advantage of keeping things simple.
As to the difference between mrconvert and mrinfo, as @dchristiaens says, it’s all about how much interpretation is performed on the DW gradient table. For mrconvert, essentially no interpretation is performed - it’s passed through to the output unmodified. With mrinfo on the other hand, operations like b-value scaling and normalisation of vectors takes place. I can see that it can get confusing, but essentially what you get with mrinfo is the DW gradient table as it would be interpreted by MRtrix3 applications, unless you use the -raw_dwgrad option, in which case you should get the same as mrconvert would produce.
As to which of these is ‘correct’, I guess that depends on your point of view. The idea in mrinfo is to provide information about the image, as MRtrix3 understands it. This does get a bit messy when using the -export_grad_fsl option, since that’s also a conversion, and I can see that the fact that it behaves differently in mrconvert than it does in mrinfo is a bit weird. I agree it might be better to ensure consistent behaviour for the -grad_export_* options - but I’m not sure whether it’s best to modify the gradient table or leave it as-is (this is relevant for multi-shell acquisitions where the acquisition software is often ‘tricked’ into modulating the b-value by scaling the gradient vectors) - thoughts welcome.
Hi Daan and Donald,
Thanks a lot for the explanation. I know now that I can discard this volume.
Probably it’s indeed best to leave mrinfo as it is, so it can always provide information about the original data. Maybe just a sentence somewhere in the documentation can clarify the difference with the behaviour in the mrconvert command.
Anyway, it’s reassuring to know that you have already considered all these details, great job!
Cheers,
Thibo