[Insight-developers] nii+itk

[brian avants]

hans , everyone

currently, the main issue we've discussed is what to do with the nii
sform.  it seems that most neuro-related programs (mricro, spm, fsl)
prioritize the sform over the qform and itk does the reverse.   one
solution (for consistency) is to switch this preference and also map
the sform to a rotation matrix (though we'd lose the sform's
scaling/shearing, if it has any).  this is done already, but only if
qform=0.   a second option is to put the onus entirely on the
application developer and also yell loudly at them when s/he tries to
read a nii image with sform --- and point them to a library of basic
solutions.

here are some more thoughts from phil cook, most related to the intent
codes that exist in nii and would also be possible to support in hdf5
:

1. qform_code is set to NIFTI_XFORM_ALIGNED_ANAT and sform_code is set
to NIFTI_XFORM_SCANNER_ANAT in all images

qform and sform codes are changed in the output regardless of their
initial values.


2. sform transformation is ignored unless qform=0, and overwritten in all cases

Even if sform_code is explicitly defined as a transform to another
space, such as NIFTI_XFORM_MNI_152, it will be overwritten by ITK and
replaced with the transform derived from the quaternion parameters.

If qform = 0 and sform > 0, the operation goes the other way -
quaternion parameters will be estimated from the sform matrix. Then
the sform is overwritten as usual.

I'm OK with sform not being used, at least by default, but I'm less
happy about it being overwritten.

3. Automatic re-ordering from lower to upper triangular DT images

I'm not sure this is really a problem, but it is something to be aware
of. If you read a DT into a program that expects vector input, it will
be set to a vector image in the output. Example:

 WarpImageMultiTransform 3 dtsymmatrix.nii.gz dtvector.nii.gz --Id -R
dtsymmatrix.nii.gz

The input is dtsymmatrix (intent NIFTI_INTENT_SYMMATRIX, lower
triangular)  but a vector  image (intent NIFTI_INTENT_VECTOR, upper
triangular) is output.

Subsequent ITK operations on the image are unaffected, since ITK
expects upper triangular when intent=NIFTI_INTENT_VECTOR. It is mostly
an interoperability problem, though arguably not on ITK's end since
other software should check intent also. It would be more convenient
from a user perspective if everything was lower triangular, because
then you could do vector things (like apply a binary mask to each
component) without having to change the volume ordering of the output
image. But it might be problematic for developers because ITK / VTK
want upper triangular matrices internally.