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.