Hi Paul,

From the nibabel perspective, I don't see any problem with extending the NIFTI_XFORM_* codes to include a generic "template but not MNI or Talairach" notion. The biggest issue will be updating tests and then trying to help users get updated to a new enough version of nibabel to be able to use files of this sort. To that end, I think an agreement that comes sooner than later will probably be best, due to the sunsetting of Python 2.

NIFTI_XFORM_GEN_STANDARD seems fine, though if the name is up for debate, something like NIFTI_XFORM_TEMPLATE_OTHER might be a little more immediately interpretable.

With regard to Satra's suggestion for NIFTI_XFORM_UNKNOWN, that triggers most software to treat the affine as missing or invalid. Nibabel, for instance, will fall back to a LAS affine based on the pixdim and dim fields, alone, and completely ignore the qform/sform contents. FSL I think does something similar. NIFTI_XFORM_ALIGNED_ANAT is preferable to that, hence its current use.

And just to be clear, this is intended to be available for qform as well as sform? The reason I bring this up is because in fMRIPrep, we've run into interoperability issues when it comes to tools that treat images with differing qforms and sforms differently. (In particular, ITK/ANTs does not respect the sform.) To eliminate sources of error, we simply abandon the idea that the original scanner orientation can be preserved in derivative images and keep the two affines synchronized. (Sorry for going a little off-topic, but while we're discussing transform codes, might as well get our abuses on the table.)

Chris