Mrconvert [WARNING]: transform matrix contains invalid entries - resetting to sane defaults

Dear MRtrix community,

I’m a bit worried about this message I get when trying to convert some NIFTI files to MIF format with

mrconvert -fslgrad bvecs bvals dti.nii.gz dwi.mif

Strangely, the message pops up only for some of my subjects.

Is this something to worry about or is it safe to assume that downstream tractography won’t be affected by this?

Sorry if this comes with very few details since I did not perform the DICOM to NIFTI conversion (I assume that it was done coherently for all subjects).
Below is an example of an mrinfo output for a file where the warning appears vs. where it doesn’t appear.

Thanks!

-Mike

Subject A:

-bash-4.2$ mrinfo dti.nii.gz


Image: “dti.nii.gz”


Format: NIfTI-1.1 (GZip compressed)
Dimensions: 128 x 128 x 25 x 63
Voxel size: 1.79688 x 1.79688 x 5.19979 x 5.02
Data type: unsigned 16 bit integer (little endian)
Data strides: [ -1 -2 3 4 ]
Intensity scaling: offset = 0, multiplier = 1
Comments: DTI_20dir_5Minuten
Transform: 1 0.000388 1.728e-05 -113.3
-0.000388 0.996 0.0889 -123
1.728e-05 -0.0889 0.996 -24.57
0 0 0 1

Subject B:

-bash-4.2$ mrinfo dti.nii.gz
mrinfo [WARNING]: transform matrix contains invalid entries - resetting to sane defaults


Image: “dti.nii.gz”


Format: NIfTI-1.1 (GZip compressed)
Dimensions: 128 x 128 x 25 x 63
Voxel size: 1.79688 x 1.79688 x 5.19977 x 5.02
Data type: unsigned 16 bit integer (little endian)
Data strides: [ 1 2 3 4 ]
Intensity scaling: offset = 0, multiplier = 1
Comments: DTI_20dir_5Minuten
Transform: 1 0 0 -114.1
0 1 0 -114.1
0 0 1 -62.4
0 0 0 1

That is strange. So first off:

Yes, I think it is, assuming your conversion command is as stated (i.e. you are providing the correct bvecs/bvals). Since the bvecs/bvals format is relative to the image axes, it shouldn’t matter how the image is oriented, and resetting the transform shouldn’t affect that. But as always, best to check visually that your tracts do line up with the expected anatomy in these subjects.

Well, I would at least like to know exactly what the issue was and how it came about, if only to be sure that you don’t need to worry about it. The most obvious issue here would be that the NIfTI header itself doesn’t contain any orientation information, or this information is badly formatted. Probably the simplest thing to do here is to use FSL’s fslhd command to dump the NIfTI header, you can then look at what was actually there. That way, we can at least determine whether the issue is with the original conversion to NIfTI, or there is some other issue within MRtrix3 that we’d need to fix (hopefully not…).

Thanks for the information so far!

Here is the fslhd output for a subject where the warning appears:


filename dti.nii.gz

sizeof_hdr 348
data_type UINT16
dim0 4
dim1 128
dim2 128
dim3 25
dim4 63
dim5 1
dim6 1
dim7 1
vox_units mm
time_units s
datatype 512
nbyper 2
bitpix 16
pixdim0 0.000000
pixdim1 1.796875
pixdim2 1.796875
pixdim3 5.199770
pixdim4 5.020000
pixdim5 0.000000
pixdim6 0.000000
pixdim7 0.000000
vox_offset 352
cal_max 0.0000
cal_min 0.0000
scl_slope 1.000000
scl_inter 0.000000
phase_dim 2
freq_dim 1
slice_dim 3
slice_name alternating_increasing
slice_code 3
slice_start 0
slice_end 24
slice_duration 0.200729
time_offset 0.000000
intent Unknown
intent_code 0
intent_name
intent_p1 0.000000
intent_p2 0.000000
intent_p3 0.000000
qform_name Scanner Anat
qform_code 1
qto_xyz:1 -1.796875 -0.000000 0.000000 118.373497
qto_xyz:2 0.000000 -1.796416 -0.117520 109.601524
qto_xyz:3 0.000000 -0.040611 5.198442 -22.090021
qto_xyz:4 0.000000 0.000000 0.000000 1.000000
qform_xorient Right-to-Left
qform_yorient Anterior-to-Posterior
qform_zorient Inferior-to-Superior
sform_name Unknown
sform_code 0
sto_xyz:1 0.000000 0.000000 0.000000 0.000000
sto_xyz:2 0.000000 0.000000 0.000000 0.000000
sto_xyz:3 0.000000 0.000000 0.000000 0.000000
sto_xyz:4 0.000000 0.000000 0.000000 0.000000
sform_xorient Unknown
sform_yorient Unknown
sform_zorient Unknown
file_type NIFTI-1+
file_code 1
descrip DTI_20dir_5Minuten
aux_file


and the mrinfo output for the same subject:


mrinfo [WARNING]: transform matrix contains invalid entries - resetting to sane defaults


Image: “dti.nii.gz”


Format: NIfTI-1.1 (GZip compressed)
Dimensions: 128 x 128 x 25 x 63
Voxel size: 1.79688 x 1.79688 x 5.19977 x 5.02
Data type: unsigned 16 bit integer (little endian)
Data strides: [ 1 2 3 4 ]
Intensity scaling: offset = 0, multiplier = 1
Comments: DTI_20dir_5Minuten
Transform: 1 0 0 -114.1
0 1 0 -114.1
0 0 1 -62.4
0 0 0 1


Now, here is the fslhd output for a subject where no warning appears


filename dti.nii.gz

sizeof_hdr 348
data_type UINT16
dim0 4
dim1 128
dim2 128
dim3 25
dim4 63
dim5 1
dim6 1
dim7 1
vox_units mm
time_units s
datatype 512
nbyper 2
bitpix 16
pixdim0 0.000000
pixdim1 1.796875
pixdim2 1.796875
pixdim3 5.199789
pixdim4 5.020000
pixdim5 0.000000
pixdim6 0.000000
pixdim7 0.000000
vox_offset 352
cal_max 0.0000
cal_min 0.0000
scl_slope 1.000000
scl_inter 0.000000
phase_dim 2
freq_dim 1
slice_dim 3
slice_name alternating_increasing
slice_code 3
slice_start 0
slice_end 24
slice_duration 0.200729
time_offset 0.000000
intent Unknown
intent_code 0
intent_name
intent_p1 0.000000
intent_p2 0.000000
intent_p3 0.000000
qform_name Scanner Anat
qform_code 1
qto_xyz:1 -1.796875 0.000000 0.000000 114.983665
qto_xyz:2 0.000000 -1.789760 0.462280 104.247231
qto_xyz:3 0.000000 0.159749 5.179199 -44.851036
qto_xyz:4 0.000000 0.000000 0.000000 1.000000
qform_xorient Right-to-Left
qform_yorient Anterior-to-Posterior
qform_zorient Inferior-to-Superior
sform_name Unknown
sform_code 0
sto_xyz:1 0.000000 0.000000 0.000000 0.000000
sto_xyz:2 0.000000 0.000000 0.000000 0.000000
sto_xyz:3 0.000000 0.000000 0.000000 0.000000
sto_xyz:4 0.000000 0.000000 0.000000 0.000000
sform_xorient Unknown
sform_yorient Unknown
sform_zorient Unknown
file_type NIFTI-1+
file_code 1
descrip DTI_20dir_5Minuten
aux_file


and the mrinfo output for the same subject:


Image: “dti.nii.gz”


Format: NIfTI-1.1 (GZip compressed)
Dimensions: 128 x 128 x 25 x 63
Voxel size: 1.79688 x 1.79688 x 5.19979 x 5.02
Data type: unsigned 16 bit integer (little endian)
Data strides: [ -1 -2 3 4 ]
Intensity scaling: offset = 0, multiplier = 1
Comments: DTI_20dir_5Minuten
Transform: 1 0.000388 1.728e-05 -113.3
-0.000388 0.996 0.0889 -123
1.728e-05 -0.0889 0.996 -24.57
0 0 0 1


OK, there seems to be an issue with the qform handling then. Can I confirm that this is a recent build? Assuming it is, can you send me one of the problematic datasets, I’ll have a look into it.

Here’s the build (I’m using it on a supercomputer, didn’t build it myself):

mrinfo -version
== mrinfo 04b6fb8e-dirty ==
64 bit release version, built Jan 18 2016, using GSL 1.16

I’ll send you a problematic dataset in a private email.
Thanks, again.

Thanks for sending the problematic image through. (Un)fortunately, it works just fine on my system:

$ mrinfo dti.nii.gz 
************************************************
Image:               "dti.nii.gz"
************************************************
  Dimensions:        128 x 128 x 25 x 63
  Voxel size:        1.79688 x 1.79688 x 5.19977 x 5.02
  Data strides:      [ -1 -2 3 4 ]
  Format:            NIfTI-1.1 (GZip compressed)
  Data type:         unsigned 16 bit integer (little endian)
  Intensity scaling: offset = 0, multiplier = 1
  Transform:                    1           0           0      -109.8
                               -0      0.9997     -0.0226      -118.5
                               -0      0.0226      0.9997      -27.25
  comments:          DTI_20dir_5Minuten

So this makes me wonder how up to date your installation is. In fact, looking at your version information, I don’t even know where it comes from… Specifically:

  • I can’t find that specific version checksum (04b6fb8e) anywhere in the entire history of MRtrix (including MRtrix 0.2).

  • There is no tag information - normally you’d see an actual version number (e.g. 0.3.15) before the checksum; this is what my version reports:

     == mrinfo 0.3.15-482-g5159ea35 ==
    64 bit release version, built Jan  9 2017, using Eigen 3.3.1
    
  • It’s still build against the GSL - we switched over to Eigen back in March 2016.

  • The version string includes the word dirty, which means modifications were made to the code before it was compiled, and these changes were not recorded in the history.

So basically, we have no record in our history of that specific commit, and on top of that it’s been modified further beyond that actual commit. I can only assume that these changes might have been made by your local admins to get MRtrix3 to build on their HPC. Regardless, your version dates back quite a while (a year in a long time in MRtrix3:wink:), before bugs in the qform handling were fixed (but then these bugs were introduced by the switch to Eigen, so the problems you’re coming up against probably predate that and are no longer current).

Not sure where that leaves you in terms of getting on with your analysis, but the best course of action will be to update your MRtrix3 install. I appreciate this might not be trivial on a HPC, but hopefully you have a friendly sysadmin…?

1 Like

Thanks a lot for this detailed and very helpful information – it clarifies a lot. I’ll make sure to get the most recent MRtrix version :slight_smile: