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
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…).
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.
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
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… ), 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…?
), 