Hello-

We have recently been coming across some issues with the NIFTI sform encoding -- namely, what to do with standard spaces that are neither Talairach nor MNI?

The problem involves the practical ambiguity of the "sform=2" code (see the current "Defined codes" below): sform=2 is used both for data sets that are not in a standard space ("coordinates aligned to another file's") and for data sets that are in some standard space (when that standard space is neither MNI nor Talairach "coordinates aligned ... to anatomical 'truth'"). Therefore, when we come across an sform=2, we are at a loss for knowing whether it is in an original/native space or a standard/template one. 

At present, the only sform codes to denote data in a template space assume that it is either Talairach (sform=3) or MNI (sform=4).

Given the proliferation of coordinate spaces that are neither Talairach nor MNI (e.g., pediatric and infant templates; templates of local populations/ethnic backgrounds; several macaque templates and other non-humans; etc.), it seems worthwhile to resolve this ambiguity.
We have a fairly straightforward proposal that would not break existing sform meanings, but which would allow for non-ambiguity moving forward. Specifically, we suggest introducing the definition that sform=5 be used for "coordinates in any template coordinate space" (non-MNI and non-Talairach standard spaces):


As part of this, we would recommend that, moving forward, people not use sform=2 for standardized/normalized space dsets.

While this shouldn't break any meanings of existing NIFTI files, as far as we know, we think it is likely that it will be necessary to update the Nibabel software to deal with this. At present, it looks like sform values there are "assert"ed, so that if sform=5 were to appear in a dset, it would break the Python reader. We certainly don't like breaking people's codes, but we hope that this could be easily fixed.

We don't directly use that field for anything specific, but i know fmriprep does. so perhaps chris.m can address implications for both fmriprep and nibabel.

But if this is mostly for the file to tell future software: please don't hold me to anything in particular? almost like an unknown flag? then why can't we use NIFTI_XFORM_UNKNOWN

It seems like there is something specific being said, and yet not very specific.

Hi, Satra-

I don't think the purpose of the defining a sform=5 code is to say about a dataset, "please don't hold me to anything in particular".

Let's say we have a dataset aligned to the standard D99 macaque template. What sform should it have?

At the moment, sform=1 is specific-- such a dset is in original space coordinates (so doesn't apply to our dset, since it *has* been aligned to something); sform=3,4 are specific-- such a dset has been aligned to Talairach or MNI standard space coordinates, respectively (so neither applies to our dset, because our standard space is not Talairach or MNI). Then, sform=0 is uninformative -- such a dset has an "arbitrary" or "unknown" coordinate space (doesn't apply to ours-- we *know* it has been aligned, and we know to what space). Currently, then, our "best" choice might be whittled down to sform=2, *but* this is ambiguous as to whether the alignment was to "just" a subject's anatomical or to a template-- and, again, this is a poor option for us because we *know* it has been aligned to *a* standard space (just not one in the very limited set of Talairach or MNI).

Therefore, instead of losing important information, we would like to use sform=5 to resolve this ambiguity for our case (and what will surely be a growing number of simialr ones)-- by introducing it to describe a dset that has been aligned *to* a standard space (that isn't Talairach or MNI).

One other option would be to introduce a new integer for every new template space, but that would get unwieldy and lead to constant updates. Hence our present suggestion.

And to be clear, we are not proposing to change the meaning of sform=2; it is just that that value is a bit unfortunate in its non-specificity/ambiguity.

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

Hi Chris,

NIFTI_XFORM_TEMPLATE_OTHER seems like a nice choice.

Yes, this would apply to both qform and sform. We do the same thing with synchronizing them.

- rick

FreeSurfer does not use this field, so it should have no effect on our code

Hi Paul, Rick,

What's the timeline and process for this change? I assume it'll show up in https://nifti.nimh.nih.gov/pub/dist/src/... once ratified? Will there be other announcements to watch for?

Chris

Hi Chris,

We were planning to do it soon, now that people have had a chance to voice any concerns. Posting a message to this thread once done might be the only additional announcement.

That path to nifti1.h under AFNI will indeed be updated, though the main NIFTI repository list is now on github under https://github.com/NIFTI-Imaging , where nifti1.h is at https://github.com/NIFTI-Imaging/nifti_c... . nifti_clib is its own repo, for example.

Soon we will remove those trees from AFNI.

- rick

I think the new code makes a lot of sense and would be fine with FSL.  I'd definitely avoid using the unknown code, as this would cause problems for FSL too.  I would support having the code available for qforms too, as it is quite common for users to want both the qform and sform to be the same.

Cheers,
    MJ

Hi, Mark-

Great, thanks for the comments and glad to know that it seems like a positive idea to you.

And yes, the initial post's phrasing just mentioned the sform_code, but we certainly mean to apply it equivalently to qform_code values, which, as you note, should typically (if not always?) match. 

Cheers,
pt

Hello,

The suggested change looks good to us and we will update the SPM NIfTI library accordingly.

Best,
Guillaume.

Hi, Guillaume-

Great, glad that is doable.

Cheers,
pt

Hi all,

Just a note that NIFTI_XFORM_TEMPLATE_OTHER is supported in nibabel 2.4.0+.

Chris