After the command mrconvert, why changed the precision of gradient table？

1

Hi Community,
My original gradient table as shown in the following figure:
b-value

bvecs

I ran the following command:
mrconvert -fslgrad dwi.bvecs dwi.bvals dwi.nii.gz dwi.mif
In the results, the gradient table has changed as follows:

mif格式中可以包含梯度表.png544×571 23.6 KB

Any suggestions?
Thanks!

In addition, I have a small question:
what’s means the 4th dimension of image(Dimensions:107x141x101x106 and Voxel size:1.5x1.5x1.5x11, respectively ). mrinfo for dwi.mif as follows:

Can you tell me what is the problem?
Thanks!

Best Wishes,
jian

2

There are various reasons for this:

  • the file you generated with mrconvert was called dwi.mif, whereas the file you inspected with mrinfo was dwi_preproc.mif. Presumably this has been run through dwipreproc, which will update the gradient table to account for motion-induced rotations (at least for newer versions of EDDY). So that might introduce minor changes in the gradient vectors, but will not affect the b-values, so is definitely not the only source of discrepancy.

  • the bvecs are specified relative to the image axes, whereas MRtrix3 operates on these directions relative to real/world/scanner coordinates. So the first thing that happens is that the gradients vectors are rotated into the correct frame (should have no effect if the images were acquired pure axial, in which case mrinfo should report an identity transform - ignoring the non-zero translation part, i.e. the last column of the transform). Again, this would leave the actual b-values unmodified.

  • mrconvert will not itself modify the DW information any further - it just imports it from bvecs/bvals (including rotation as required above), and passes it through to the output. On the other hand, mrinfo (and other MRtrix3 applications) will potentially perform additional modifications to sanitise this information for actual use, as discussed recently in a previous post. These include:

    • normalisation of vectors, to ensure they are genuinely unit vectors. This can often introduce minor variations due to rounding errors in the original table.

    • scaling of the b-value entries by the square of the gradient vector norm. This is done to allow use of multi-shell data where the scanner only allows a single b-value to be specified, but can be fooled into performing a multi-shell acquisition by scaling the gradient vector appropriately (also discussed in this older post). This can be disabled by passing the option -bvalue_scaling 0 to the relevant applications.

To verify that mrconvert hasn’t modified the bvals as I described above, try running mrinfo -raw_dwgrad dwi.mif, I’d expect that to provide the expected b-values. As explained in this post, mrinfo -dwgrad will give you the gradient table as MRtrix3 applications will interpret it, including normalisation of gradient vectors and b-value scaling.

MRtrix3 supports images with arbitrary dimensions. The first 3 axes are invariably interpreted as the spatial axes, but what the 4th axis represents is application-specific. In fMRI for instance, that might be time. In DWI, it’s the volume axis, corresponding to an entry in the DW gradient table. In T2 relaxometry, it might be different echo times. But basically, in your case, it means you have 106 3D volumes within your dataset, presumably each with their own DW b-value & direction.

The second line is the physical distance between adjacent positions along each axis. The first 3 correspond to the voxel spatial sizes (1.5×1.5×1.5mm in your case). There also happens to be a size defined for the 4th axis, which is unusual in DWI - I’m pretty sure mrconvert would leave that blank when converting from DICOM (you’d see a ? for that last entry). However, it is important for applications like fMRI where you need to know the time interval between volumes. So I wouldn’t be surprised if your DICOM converter automatically inserts the repetition time (as read from the DICOM headers) in the corresponding field in the NIfTI output (there are equivalent entries in the NIfTI header: the pixdim array). A TR of 11s sounds about right for a DWI acquisition, does this match which your protocol?

1 Like
3

Hi Donald，

Thank you for the detailed explanation!
The first question, I inspected dwi.mif with mrinfo again, and the b-values still has minor changes. But I agree with you. The mrinfo might introduce minor changes in the b-values to sanitise this information for actual use.

The second question, you are right. It’s indeed the TR values, 11s.

Cheers,
Jian

4

OK, that’s unexpected. I’d expect these commands:

mrconvert -fslgrad dwi.bvecs dwi.bvals dwi.nii.gz dwi.mif
mrinfo dwi.mif -dwgrad -raw_dwgrad

to produce a table with the exact same b-values as were listed in the original dwi.bvals file. I’m surprised to hear otherwise…

5

Oh, I’m sorry about the result and I’m so careless. Now the result is right.

Thank you very much!
Cheers,
Jian

6

Thanks for confirming! Very reassuring… :grin: