# Nrrd vs nii regarding affine data and transforms

**URL:** <https://discourse.slicer.org/t/nrrd-vs-nii-regarding-affine-data-and-transforms/1896>\
**Category:** Support\
**Tags:** transforms, nrrd\
**Created:** [January 22, 2018, 2:05pm UTC](https://discourse.slicer.org/t/nrrd-vs-nii-regarding-affine-data-and-transforms/1896 "2018-01-22T14:05:07Z")\
**Posts on this page:** 4\
**Page:** 2

<div class="post-metadata">

**Author:** ![lassoan](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/lassoan/32/13_2.png) [@lassoan](https://discourse.slicer.org/u/lassoan)\
**Post date:** [February 28, 2020, 5:40pm UTC](https://discourse.slicer.org/t/nrrd-vs-nii-regarding-affine-data-and-transforms/1896/21 "2020-02-28T17:40:59Z")

</div>

Thanks for the detailed response.

> [@Chris\_Rorden](#):
>
> To be clear, this is an limitation with ITK not NIfTI. One could just as easily create a [NRRD](http://teem.sourceforge.net/nrrd/format.html) header where `space directions` defines a shear and ITK will treat the volume as rectangular

ITK states that it is allowed to store sheared volumes in itk image data objects ([source](https://itk.org/Doxygen/html/classitk_1_1ImageBase.html#a23ebc76de3b60bb1eeabf66cd4dabc48)). I’ve tested current ITK behavior now and found the followings:

- ITK can _read_ sheared volumes - direction matrix contain shear - from mha and nrrd formats (could not test others, as I could not modify headers to introduce shear)
- ITK orthogonalizes direction matrix when writing images in all formats I tested (mha, nrrd, nifti, mgz, mnc)

So, there is definitely fundamental inconsistency within ITK between reading and writing files.

A short-term solution could be that we refuse writing volumes with non-orthogonal axes in Slicer. That way we could avoid accidental data corruption. The difficulty is reliable detection of non-orthogonal axes without false alarms.

---

<div class="post-metadata">

**Author:** ![gcsharp](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/gcsharp/32/863_2.png) [@gcsharp](https://discourse.slicer.org/u/gcsharp)\
**Post date:** [March 12, 2020, 5:19pm UTC](https://discourse.slicer.org/t/nrrd-vs-nii-regarding-affine-data-and-transforms/1896/22 "2020-03-12T17:19:31Z")

</div>

I consider the version of the NIfTI implemented in ITK that does not support affine to be obsolete. I do not consider NIfTI v1 and NIfTI v2 obsolete!

---

<div class="post-metadata">

**Author:** ![Research5](https://avatars.discourse-cdn.com/v4/letter/r/85f322/32.png) [@Research5](https://discourse.slicer.org/u/Research5)\
**Post date:** [February 25, 2021, 5:27am UTC](https://discourse.slicer.org/t/nrrd-vs-nii-regarding-affine-data-and-transforms/1896/23 "2021-02-25T05:27:35Z")

</div>

My research group encountered the same issue. Was there a resolution to either executing the conversion of Nrrd to Nii while taking into account the orthogonal considerations or completing a step beforehand to account for the differences?

---

<div class="post-metadata">

**Author:** ![lassoan](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/lassoan/32/13_2.png) [@lassoan](https://discourse.slicer.org/u/lassoan)\
**Post date:** [February 25, 2021, 5:52am UTC](https://discourse.slicer.org/t/nrrd-vs-nii-regarding-affine-data-and-transforms/1896/24 "2021-02-25T05:52:44Z")

</div>

Until ITK does not support writing of non-orthogonal axes, probably the best is to resample the volume on a rectilinear grid using one of the image resample modules. For example, you can use “Crop volume module”; or use “Resample scalar/vector/dwi volume” module and set “Manual output parameters”.

[Previous page](https://discourse.slicer.org/t/nrrd-vs-nii-regarding-affine-data-and-transforms/1896.md?page=1)