# NIfTI transform ambiguity **URL:** \ **Category:** Wiki\ **Tags:** troubleshooting\ **Created:** [February 9, 2019, 12:34pm UTC](https://community.mrtrix.org/t/nifti-transform-ambiguity/2254 "2019-02-09T12:34:17Z")\ **Posts on this page:** 1\ **Page:** 1
**Author:** ![rsmith](https://community.mrtrix.org/user_avatar/community.mrtrix.org/rsmith/32/2672_2.png) [@rsmith](https://community.mrtrix.org/u/rsmith)\ **Post date:** [February 9, 2019, 12:34pm UTC](https://community.mrtrix.org/t/nifti-transform-ambiguity/2254/1 "2019-02-09T12:34:17Z")
In the [NIfTI & NIfTI-2 (.nii)](https://mrtrix.readthedocs.io/en/latest/getting_started/image_data.html#nifti-format) image format, there is not one, but _two_ items stored in the image header that provide information regarding the localisation of the image within physical space (the image [transform](https://mrtrix.readthedocs.io/en/latest/getting_started/image_data.html#the-image-transfom)): - The “ `qform` ” entry is _intended_ to specify a _rigid_ transformation from voxel coordinates into a spatial location corresponding to the subject’s position within the scanner. - The “ `sform` ” entry is _intended_ to specify an _affine_ transformation from voxel coordinates into a spatial location within the space of some template image. While the storage of both of these fields within a single image was [well-intentioned](https://nifti.nimh.nih.gov/nifti-1/documentation/faq#Q19), the practical reality is that there is no robust way for any software to know which of the two transforms should be used. Furthermore, while software developers will typically ensure that the handling of these fields is internally consistent within their own software, this handling can differ _between_ packages, causing problems for those who utilise multiple software tools. The handling of this information in _MRtrix3_ is as follows: - When _reading_ NIfTI images: - When _writing_ NIfTI images, _MRtrix3_ will: * * * ### What if the `qform` and `sform` transformations differ on image read? As stated previously, if a NIfTI file being read by _MRtrix3_ contains valid data for both of the two transformations, yet the two transformations differ, a decision must be made regarding which of the two transforms will be used. While a command-line warning will always be issued by _MRtrix3_ whenever this occurs, which of the two transformations is chosen depends on a couple of factors: #### Software version The default transformation selected depends on the particular version of _MRtrix3_ installed: - `3.0_RC2` and prior: `sform` - `3.0_RC3`: `qform` - `3.0_RC4` onwards: `sform` Historically _MRtrix3_ had been configured to use the `sform` transformation by default, as it was more likely to be the transformation _most recently updated_ by prior image processing. With the `3.0_RC3` update, this was changed to the `qform` transformation, based on the _intent_ of NIfTI whereby the `qform` represents the spatial localisation of subject-specific data (consistent with the standard used throughout _MRtrix3_ of operating on positions / directions defined in real space / scanner space) and is additionally constrained to be orthonormal based on the quaternion representation of the transformation, whereas the `sform` represents an affine transformation to some template space (which is neither constrained to be orthonormal nor corresponds to the subject’s location in space). Unfortunately the disadvantages of this selection were not appreciated in full until after the release of `3.0_RC3`; in particular a loss of precision due to floating-point rounding of the quaternion representation, and the fact that some softwares may update the `sform` matrix in-place yet leave the `qform_code` flag set and not correspondingly update the `qform` transformation. As such, from `3.0_RC4` onwards, _MRtrix3_ will revert to using the `sform` transformation by default in such cases. #### Config file It is possible to manually control which of the two transformations are read by _MRtrix3_ in cases of ambiguity, by setting a value for entry [`NIfTIUseSform`](https://mrtrix.readthedocs.io/en/latest/reference/config_file_options.html#cmdoption-arg-niftiusesform) in the _MRtrix3_ [configuration file](https://mrtrix.readthedocs.io/en/latest/getting_started/config.html). Note that even in this scenario, _MRtrix3_ will still provide a command-line warning to alert the user of the potential ambiguity.