space filename keyword is not restricted to the controlled vocabulary

[chrisgorgo]

See https://github.com/bids-standard/bids-validator/blob/2dab5a40bf38292bf91a1bedeb4dfddfe0d06b05/bids-validator/bids_validator/rules/file_level_rules.json#L174

My reading of the spec is that the allowed values are:

• Other
• Pixels
• ACPC
• MNI152Lin
• MNI152NLin6[Sym|Asym]
• MNI152NLin2009[a-c][Sym|Asym]
• MNIColin27
• MNI305
• NIHPD
• Talairach
• OASIS30AntsOASISAnts
• OASIS30Atropos
• ICBM452AirSpace
• ICBM452Warp5Space
• IXI549Space
• fsaverage[3|4|5|6|sym]
• UNCInfant[0|1|2]V[21|22|23]

Related to https://neurostars.org/t/questions-about-appendix-viii-preferred-names-of-coordinate-systems/3758. Pinging @dorahermes and @choldgraf for confirmation

[dorahermes]

Yes, this is my understanding also. The reason for this question is that many iEEG coordinates are in the original scanner space of the T1 and there is no specific tag for this yet, and adding this tag (e.g. -orig) from the iEEG spec was not preferred.
--> therefore, my understanding is that iEEG can currently use Other (for scanner coordinates) or ACPC (if we ACPC transform the image).

[effigies]

There's discussion over in bids-standard/bids-specification#109 (currently at the bottom) about the subject-native T1w "space", and how that should be treated. Input from interested parties would be welcome.

[sappelhoff]

We made some progress, see: https://bids-specification.readthedocs.io/en/latest/99-appendices/08-coordinate-systems.html

in brief:

• MEG, EEG, and iEEG can all use the defined "standard templates" (such as MNI152Lin and many more, see also list in the OP)
• EEG can use MEG keywords and vice versa

This is now finally also validated in the JSON schemas. However it remains an open issue with the filenames: it's currently possible for someone to have a file like *_space-Foo, and a corresponding CoordinateSystem entry of CapTrak in the coordsystem.json file. That's obviously bad.

Filenames should be checked such that their space-* value corresponds to the entry in the accompanying coordsystem.json file.

As a first step however, it would probably already be an improvement to constrain the RegExps for space to the list of accepted Keywords. That way something like space-RandomStuff won't be possible anymore.

cc @adam2392

[adam2392]

My reading of the spec is that the allowed values are:

• Other
• Pixels
• ACPC
• MNI152Lin
• MNI152NLin6[Sym|Asym]
• MNI152NLin2009[a-c][Sym|Asym]
• MNIColin27
• MNI305
• NIHPD
• Talairach
• OASIS30AntsOASISAnts
• OASIS30Atropos
• ICBM452AirSpace
• ICBM452Warp5Space
• IXI549Space
• fsaverage[3|4|5|6|sym]
• UNCInfant[0|1|2]V[21|22|23]

From this list, I don't see fsnative for the T1w image of the subject from FreeSurfer? Is this encompassed in the above?

[sappelhoff]

@adam2392 the list you should look at is in appendix VIII

you could also look at the JSON schema for these fields. That is used to validate the iEEGCoordinateSystem field in coordsystem.json. The original idea as far as I can see it was that the iEEGCoordinateSystem field and space label should be aligned.

https://github.com/bids-standard/bids-validator/blob/4c1be20980b1215d45aee5e595b62c14bf2604e2/bids-validator/validators/json/schemas/common_definitions.json#L9-L53

[adam2392]

Currently discussing with @sappelhoff about some issue with the space entity here: bids-standard/bids-specification#734

The topic is usage of space entity to identify ieeg electrodes coordinates localized on the FreeSurfer T1w image. Anyone have thoughts, feel free to chime in.