# Saving non-orthogonal volume in Nifti format

**URL:** https://discourse.itk.org/t/saving-non-orthogonal-volume-in-nifti-format/2760
**Category:** Engineering
**Created:** [February 25, 2020, 4:12am UTC](https://discourse.itk.org/t/saving-non-orthogonal-volume-in-nifti-format/2760 "2020-02-25T04:12:29Z")
**Posts on this page:** 1
**Showing post:** 12

<div class="post-metadata">

### Author: ![spinicist](https://discourse.itk.org/user_avatar/discourse.itk.org/spinicist/32/183_2.png) [@spinicist](https://discourse.itk.org/u/spinicist)
#### Post date: [February 26, 2020, 5:29pm UTC](https://discourse.itk.org/t/saving-non-orthogonal-volume-in-nifti-format/2760/12 "2020-02-26T17:29:44Z")

</div>

Ah, I misunderstood. Nifti was specifically introduced for fMRI, I doubt CT acquisitions like this were considered among the original use cases.

If the ITK Nifti writer was updated so that a non-orthogonal `sform` could be stored, and the `sform` and `qform` codes independently controlled by the user, I would now argue that setting the `qform` code to `UNKNOWN` and `sform` to `SCANNER_ANAT` would be semantically meaningful within the Nifti specification. But I’m probably in a minority on that.

More importantly:

1. That’s a lot of work
2. Applications would have to be aware of this and special-case writing Niftis
3. As you mention, I don’t think it would guarantee all applications would read the resulting file correctly anyway\*.

I am not sure if outright refusing to write Niftis with non-orthogonal axes is correct, because:

1. As I outlined above, non-orthogonal axes as the result of an affine transform are valid and indeed explicitly catered for in the spec.
2. As in @dzenanz’s linked bug, there are DICOMs in the wild that do not have perfectly orthogonal axes, but probably should do (i.e. the headers are slightly wrong). Maybe the strictly correct thing to do would be to fix the header information before writing to Nifti?

Sadly I am not sure there is a one-size-fits-all solution.

\*As an illustrative aside, FSL’s flirt tool predates the introduction of Nifti and by default _ignores orientation information entirely_, instead inventing a co-ordinate system (you can force using the `qform` with a command-line switch). This was a deliberate choice when they wrote it, because ANALYZE header information was notoriously unreliable. The flirt algorithm is robust enough that in most cases it will still find a correct result.

---

_[View the full topic](https://discourse.itk.org/t/saving-non-orthogonal-volume-in-nifti-format/2760)._