Grand Mean scaling / Normalisation - Voxelwise vs. imagewise vs. 1 single scalefactor

[nicholst]

Currently we have exactly one term for data scaling: nidm:'grand Mean Scaling' with definition

Binary flag defining whether the data was scaled (true for scaled). Specifically, "grand mean scaling" refers to multiplication of every voxel in every scan by a common (or session-specific) value.

There are are at least 5 ways that intensity normalisation can be done:

1. No scaling at all. Always used for 2nd level fMRI and can be used with quantitative PET data.
2. Grand mean scaling. Normalisation consisting of scaling the entire dataset with a single value. In SPM, this is based on the mean of each each image's mean value value (see SPM's spm_global), scaling the data to have a grand mean of 100 ("Overall grand mean scaling" under "Global normalisation"; default for 1st level fMRI). In FSL's FEAT, this is based on the median of the mean image, scaling the data such that median mean image value is 10,000 (default).
3. Image-wise scaling. Normalisation consisting of scaling of each image. In SPM this is based on each image's mean value, with scaling bringing each image's mean to 100 ("Proportional" under "Global normalisation"). In FSL this is optional, and consists of scaling each image's mean to 10,000.
4. Voxel-wise scaling. Normalisation consisting of scaling each voxel individually. AFNI offers this option, scaling each voxel to have mean intensity 100 (truncating below at 0, and above at 200).
5. Voxel-wise ANCOVA. Normalisation is done as part of general linear model fitting. In SPM, a covariate consisting of each image's mean value (see SPM's spm_global) is created and added to the linear model.

The original definition nidm:'grand Mean Scaling' was set as binary since SPM and FSL only use 1 & 2. We are now expanding it since AFNI routinely uses 4. (Option 5 is common for PET but, notably, also corresponds to "Global Signal Regression" used in resting state fMRI analyses.)

The notion of "scaling" is encompassed by options 2-4 above, and so we could leave nidm:'grand Mean Scaling' intact and add new terms to cover these all these options.

[afni-rickr]

Adding terms seems reasonable, since it is probably a lot of work to rename and alter one (which might cause backward compatibility issues, given that it this is surely already in use).
It is hard to agree with the notion that "only options 1 & 2 are encountered in practice". We encounter only options 1 and 4, of course, and for task not really even 1.

[cmaumet]

Thank you @nicholst and @afni-rickr for your comments! To summarise, I can see two options:

1. Deprecate nidm_grandMeanScaling and replace it by nidm_dataScalingType with possible values nidm_GrandMeanScaling, nidm_ImageWiseScaling, nidm_VoxelWiseScaling, nidm_noDataScaling, or
2. Keep nidm_grandMeanScaling as it is and create new boolean attributes nidm_voxelWiseScaling and nidm_imageWiseScaling.

As @afni-rickr was pointing out, option 1 would break backward compatibility and therefore require releasing a new major version of NIDM-Results. Nevertheless, to me this first option is a better match as it prevents having grand mean / voxel-wise and image-wise scaling being specified simultaneously. It is also a simpler model to query (search for one attribute instead of three).

So, I would be in favour of option 1 but my suggestion would be to continue checking the compatibility of NIDM-Results on more AFNI examples before we release a new major version of NIDM-Results.

@nicholst, @afni-rickr, all: Does this seem reasonable?

As a side note, @nicholst: do you have an example of use case that uses 'Voxel-wise ANCOVA'? Would it make sense to consider that this case is already modelled by the design matrix entity?

[tiborauer]

@cmaumet, Do not you mean that Option 1 is preferable (one attribute instead of three)?

[cmaumet]

Yes, thanks @tiborauer!! (I've updated the text above)

[nicholst]

I guess I'm partial to not breaking NIDM-Results, but agree Option 1 is more elegant than 2. I would like to hear from the people that it potentially actually affect... e.g. would this require changes to Neurovault's NIDM reader @chrisfilo ? And @gllmflndn do you have a view?

@cmaumet If we do move from a binary nidm_grandMeanScaling, +1 for your 4 values.

[nicholst]

@afni-rickr - Fair points. I've updated my post above to point out that (my) option 4 is also common. (Option 1 is indeed common for 2nd level models as you note).

[afni-rickr]

That sounds good @nicholst and @cmaumet. Yes, it seems like a good idea to wait until we get more AFNI examples before releasing any NIDM update. We can try to limit your suffering to a single block of time, or at least modestly well clustered blocks...