Mrtransform changes strides (but also qform)


#1

Dear Mrtrixers,

I have encountered a problem in changing the strides of a diffusion weighted MRI file.
Currently, the strides are 1,2,3,4, and I wish to change them to -1,2,3,4 (as it seems to be the appropriate form of input for a TractSeg analysis). I do so using the following command:

mrtransform -strides -1,2,3,4 fileOrig.nii.gz fileStrides.nii.gz  -force

The unexpected problem I found is that the xform has changed not only in terms of the x axis, but also in terms of the y and z axes. For example, the original file had the following output for mrinfo (-norealign):

  Dimensions:        81 x 106 x 76 x 104
  Voxel size:        2 x 2 x 2 x 8.125
  Data strides:      [ 1 2 3 4 ]
  Format:            NIfTI-1.1 (GZip compressed)
  Data type:         signed 16 bit integer (little endian)
  Intensity scaling: offset = 0, multiplier = 1
  Transform:                    1           0           0         -80
                                0           1           0        -120
                                0           0           1         -60
  comments:          Raw Eddy Corrected

While the new file has:

  Dimensions:        81 x 106 x 76 x 104
  Voxel size:        2 x 2 x 2 x 8.125
  Data strides:      [ 1 2 3 4 ]
  Format:            NIfTI-1.1 (GZip compressed)
  Data type:         32 bit float (little endian)
  Intensity scaling: offset = 0, multiplier = 1
  Transform:                   -1           0           0          80
                               -0           1           0        -105
                               -0           0           1         -75
  comments:          Raw Eddy Corrected
  mrtrix_version:    unknown

As you can see, not only did the x axis flip (as expected), but also the y and z origin values changes. Ir order to keep the rest of the analysis output consistent with other aligned scans from the same subject, I had to manually change the xform of the output file (replacing rows 2-4 with those of the original file).

Does this change in the xform following mrtransform make sense to you? Does the workaround I suggested sound reasonable?

Many thanks!
Enjoy your weekend,
Roey


#2

Hi Roey,

That is indeed unusual; for an identity transformation at least, the offsets of the other two axes should not be affected by the reversal of the first.

  • Is this something that arises for one specific image, or a pattern that you see recurring for some or all images?

  • Does the command issue any warning about a mismatch between sform and qform transformations for the input image?

  • I can’t help but notice:

    mrtrix_version: unknown

    How was your MRtrix3 installation done? Can you provide the output of mrinfo -version so that we can cross-check the version of the code that you are using (since I can’t reproduce it currently)?


#3

Hi Rob,

Thank a lot for this answer.

This happens with all the images I have tried so far, not just this one.

While I could not find any inconsistencies between the sform and qform (as determined by the qto_xyz and sto_xyz field read by the readFileNifti command), I did get the following warnings, which seem relevant:

     mrtransform: [00;31m[WARNING] the input linear transform is not orthonormal and therefore applying this without the -template option will mean the output header transform will also be not orthonormal[0m
     mrtransform: [00;31m[WARNING] transform matrix contains invalid entries - resetting to sane defaults[0m

Unfortunately I cannot say how MRtrix3 was installed, although I can find out and let you know.
I the mean time, I was able to reproduce this on two machines, each with its own version. The outputs of mrinfo -version are:

== mrinfo 3.0_RC3-135-g2b8e7d0c ==
64 bit release version, built Mar 17 2019, using Eigen 3.2.92

and

== mrinfo 3.0_RC3-86-g4b523b41 ==
64 bit release version, built Aug 20 2018, using Eigen 3.2.92

Is there anything else I can provide to help get to the bottom of this?
Many thanks again,
Roey


#4

OK, this is a trivial bug, due to not defaulting to an identity transform when no other transformation is specified. I’ve committed the fix, hopefully I’ve got this right, and it’ll be approved and merged to master relatively quickly…

Thanks for reporting!


#5

Wonderful. Thank you, @rsmith and @jdtournier!