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:
- That’s a lot of work
- Applications would have to be aware of this and special-case writing Niftis
- 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:
- As I outlined above, non-orthogonal axes as the result of an affine transform are valid and indeed explicitly catered for in the spec.
- 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.