Inconsistent qform /sform on nifti image


Hi all,

I’ve recently upgraded MRtrix to the last available version (3.0_RC3-9-g8cef8321). In order to start testing the commands newest version, I ran some of them (for example mrinfo) on images that I’ve obtained with an older version of MRtrix (mrtrix_version: 0.3.15-482-g5159ea35) but, for some subjects, the following message appeared:
[WARNING] qform and sform are inconsistent in NIfTI image "dwi_raw.nii" - using qform

I read this topic and I checked what fslhd reports:

qform_name Scanner Anat
qform_code 1
qto_xyz:1 -0.932456 -0.038162 0.285776 121.982002
qto_xyz:2 0.038914 -0.936672 0.019370 156.352997
qto_xyz:3 0.088980 0.009728 2.986296 -38.749401
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 Scanner Anat
sform_code 1
sto_xyz:1 -0.932456 -0.038167 0.285776 121.982002
sto_xyz:2 0.038911 -0.936672 0.019369 156.352997
sto_xyz:3 0.088980 0.009728 2.986297 -38.749401
sto_xyz:4 0.000000 0.000000 0.000000 1.000000
sform_xorient Right-to-Left
sform_yorient Anterior-to-Posterior
sform_zorient Inferior-to-Superior

Should I see the inconsistency reflected there?

So taking in mind that doesn’t happen to all my subjects, how can this inconsistency affect an output file of any newest version command? how can I fix it?



You can get the full precision transformation that is used with mrinfo image.nii -transform. You can set the MRtrix config file option NIfTIUseSform: true to check whether there is a significant difference between sform and qform.

We made some changes to the part of the code that handles qforms (issue). These might trigger this warning.

For context, this warning is issued if the FOV corner differs between both transformations by more than 1e-3 voxels. Depending on the number of voxels, the precision you are seeing using fslhd might not be sufficient to see this difference.


Hi Stella,

I have unfortunately also encountered this issue since the 3.0_RC3 tag; we had hoped we’d resolved the issue, but it seems that there are still edge cases.

For clarity, there are a few changes surrounding this terminal warning that are worth separating:

  • On NIfTI image load, if both qform and sform are flagged as present within the image, MRtrix3 will now uses the qform transform by default; in previous versions, it would automatically use the sform.

    • If only one or the other is defined, then the transform that is defined will always be used.

    • This behaviour can be reverted by setting NIfTIUseSform: true in the MRtrix3 config file. MRtrix3 will then always use the sform transform in cases where both are present.

  • If both transforms are present, then MRtrix3 will additionally compare the two transformations. If they are effectively identical, then the decision of which transform to use is effectively irrelevant. If however they differ, then MRtrix3 will present you with the warning you have observed, basically stating that there is some ambiguity about where the image should be positioned in space and telling you what decision it has made.

  • There has additionally been a small fix to how qform transforms are imported, due to numerical precision issues when converting between quaternion and matrix representations.

Given that this warning is still appearing, it’s possible that:

  • Our qform import code is not quite robust enough.

  • Our numerical tolerances between manipulation of the transformation data, and testing for equivalence between the transforms, are somehow unbalanced.

So what would help us here to find a solution that works as advertised for all use cases would be, whenever somebody encounters this warning (and believes that the warning is erroneous), if you could provide:

  • The output of fslhd

  • The output of mrinfo -transform

  • The output of mrinfo -transform, after having set NIfTIUseSform: true in the MRtrix3 configuration file.


I note that the qform and sform transforms reported by fslhd match up to 4 digits. There’s still scope for the positions of the corner voxels to differ by >1e-3 voxels if the matrix is large enough – a mismatch of 1e-4 might lead to shift of 1e-2 for the position 100 voxels away. Maybe we really just need to relax the tolerance around these tests. There is a fundamental precision issue introduced by the quaternion representation, given that the components are stored as 32 bit floats, which led to the issues we’d discussed here. Given these problems, we shouldn’t be surprised to find small differences, that can sometimes get (relatively) large in edge cases, even though the transforms still fundamentally match.

It’s also worth pointing out that these tests are quite a bit more stringent than those performed by FSL commands. Also, they are warnings only, and don’t otherwise affect the operation of the commands. But I agree that we would rather not see warnings appearing for data that don’t actually have any issues as such…


Hi, thanks for your responses.

Rob, please find bellow the outputs you asked:

  • fslhd reports:

      filename       dwi_raw.nii
      sizeof_hdr     348
      data_type      INT16
      dim0           4
      dim1           256
      dim2           256
      dim3           44
      dim4           36
      dim5           1
      dim6           1
      dim7           1
      vox_units      mm
      time_units     s
      datatype       4
      nbyper         2
      bitpix         16
      pixdim0        0.000000
      pixdim1        0.937500
      pixdim2        0.937500
      pixdim3        3.000024
      pixdim4        12.000000
      pixdim5        1.000000
      pixdim6        1.000000
      pixdim7        56266.000000
      vox_offset     352
      cal_max        0.0000
      cal_min        0.0000
      scl_slope      1.000000
      scl_inter      0.000000
      phase_dim      0
      freq_dim       0
      slice_dim      0
      slice_name     Unknown
      slice_code     0
      slice_start    0
      slice_end      0
      slice_duration 0.000000
      time_offset    0.000000
      intent         Unknown
      intent_code    0
      intent_p1      0.000000
      intent_p2      0.000000
      intent_p3      0.000000
      qform_name     Scanner Anat
      qform_code     1
      qto_xyz:1      -0.932456  0.038163  0.285777  112.249336
      qto_xyz:2      0.038915  0.936672  0.019370  -82.498436
      qto_xyz:3      0.088979  -0.009727  2.986319  -36.268818
      qto_xyz:4      0.000000  0.000000  0.000000  1.000000
      qform_xorient  Right-to-Left
      qform_yorient  Posterior-to-Anterior
      qform_zorient  Inferior-to-Superior
      sform_name     Scanner Anat
      sform_code     1
      sto_xyz:1      -0.932456  0.038167  0.285778  112.249336
      sto_xyz:2      0.038911  0.936672  0.019370  -82.498436
      sto_xyz:3      0.088980  -0.009728  2.986319  -36.268818
      sto_xyz:4      0.000000  0.000000  0.000000  1.000000
      sform_xorient  Right-to-Left
      sform_yorient  Posterior-to-Anterior
      sform_zorient  Inferior-to-Superior
      file_type      NIFTI-1+
      file_code      1
      descrip        TE=91.09999847;sec=56266.0000
  • mrinfo -transform:

      mrinfo: [WARNING] qform and sform are inconsistent in NIfTI image "dwi_raw.nii" - using qform
        0.9946199286938637  0.04070710161471539  0.09525822443832641    -125.526990460701
      -0.04150952215963574   0.9991172472381403 0.006456457338166832   -72.57506583283318
       -0.0949113113126778 -0.01037584451551273   0.9954316575413391   -13.57908254092429
                         0                    0                    0                    1
  • mrinfo -transform after NIfTIUseSform: true:

      mrinfo: [WARNING] qform and sform are inconsistent in NIfTI image "dwi_raw.nii" - using sform
        0.9946200688680013  0.04071180423100789  0.09525857399972487   -125.5270239710808
      -0.04150480429331461    0.999117088317871 0.006456449957573755   -72.57619369775057
       -0.0949117104212443 -0.01037630041440328   0.9954316982744912   -13.57898712903261
                         0                    0                    0                    1


Yes, it looks like the y coefficient of the origin (i.e. 2nd row, last column) already differs by more than 1e-3 voxels. I think it’s a straight precision issue. Note that the origin reported by mrinfo differs from that in the NIfTI header due to MRtrix3’s internal transform reshuffle (probably best explained here), which explains why the origin reported by fslhd matches perfectly between qform and sform, but not for mrinfo. You should get the exact same results for both fslhd and mrinfo by adding the -norealign option to mrinfo – if that doesn’t match up exactly with what fslhd reports, please let us know, that shouldn’t happen.

I’ll take a look into how the qform is converted into the transformation matrix again, make sure there’s nothing we can do to improve things further. Otherwise, we might need to relax the precision of these tests. Realistically, we only need to make sure the corners correspond to the same voxels, and preferably better than that. Maybe 0.1 voxels would be sufficient for those checks…?


Here I show what is reported in each case with -norealign option:

  • mrinfo -transform -norealign (NIfTIUseSform: true):

      mrinfo: [WARNING] qform and sform are inconsistent in NIfTI image "dwi_raw.nii" - using sform
       -0.9946200688680013  0.04071180423100789  0.09525857399972487    112.2493362426758
       0.04150480429331461    0.999117088317871 0.006456449957573755   -82.49843597412109
        0.0949117104212443 -0.01037630041440328   0.9954316982744912   -36.26881790161133
                         0                    0                    0                    1
  • mrinfo -transform -norealign (NIfTIUseSform: false):

      mrinfo: [WARNING] qform and sform are inconsistent in NIfTI image "dwi_raw.nii" - using qform
       -0.9946199286938637  0.04070710161471539  0.09525822443832641    112.2493362426758
       0.04150952215963574   0.9991172472381403 0.006456457338166832   -82.49843597412109
        0.0949113113126778 -0.01037584451551273   0.9954316575413391   -36.26881790161133
                         0                    0                    0                    1



Thanks for the additional info. We’ve been discussing this issue in the meantime on GitHub (see this issue), and I think we’ve more or less got to the bottom of it. We’re now trying to figure out what to do about it, but hopefully we’ll have an acceptable solution shortly.

To recap briefly: unfortunately, that warning is correct, the transform derived from the qform can be inaccurate, and lead to appreciable differences relative to the (more stable) sform. This is the case particularly for NIfTI-1 due to the use of single-precision (32 bit) floats to store the coefficients, leading to loss of precision (in NIfTI-2, these coefficients are stored using double precision). There’s nothing we can do about this, it’s an inherent limitation of the way that information is stored in NIfTI images, and FSL produces the exact same results (although they don’t flag this with a warning like we now do).