[Suggestion] Making CoordinateSystem mandatory if Pos3D is present

[Edouard2laire]

Hello,

Is your suggestion related to a problem? Please describe.
The main objective of having access to Pos3D (sourcePos3D, detectorPos3D) is to be able to coregister the montage with a template or the subject anatomy. This can however become tricky without information about the coordinate system used.

Additionally, the co-registration can be made much easier with access to landmark position (nasion, left/right ear...)

Describe the solution you'd like

Have the coordinate system be mandatory if sourcePos3D and detectorPos3D are present.

Have landmarkPos3D and landmarkLabels be recommended if sourcePos3D and detectorPos3D are present.

Additional context

The description of the coordinate system is required when including nirs data in a BIDS dataset: https://bids-specification.readthedocs.io/en/stable/modality-specific-files/near-infrared-spectroscopy.html#coordinate-system-json-_coordsystemjson

[dboas]

@Edouard2laire , I was just looking at this coordinate system requirement in the BIDS spec today. It goes in the coordsystem.json file. I agree this would be good to get into the snirf file. And I like the way you describe the conditional requirement. I believe the validator could handle this language. But I personally wouldn't want to burden ourselves to have the SNIRF validator check if the provided coordinate system is a valid coordinate system since the BIDS validator already handles this. Unless someone volunteered to make that change to the SNIRF validator.

I was thinking that in the use cases in my lab that I would use 'other' for the 'NIRSCoordinateSystem' field and then I would indicate in the 'NIRSCoordinateSystemDescription' field that our landmarks and optodes are in the same coordinate system with mm units.

I wonder what other maintainers and steering committee members think?

[HanBnrd]

So you're suggesting to turn the /nirs(i)/probe/coordinateSystem or /nirs(i)/probe/landmarkPos3D (which are currently optional) into a required field if 3D positions are present? Could 3D distances simply be used by some users to compute source-detector distances and therefore not necessitate a coordinate system?

I agree it would be better to encourage having it though.

[dboas]

@HanBnrd , I think the suggestion is making /nirs(i)/probe/coordinateSystem required if 3D positions is present. And recommending, but not requiring /nirs(i)/probe/landmarkPos3D.

One can always using 'other' for the coordinateSystem and indicate that positions are provided in 'mm' units or something like that. So I don't see any issue for those users who aren't aware of the coordinate. In the least, they should be using physical units for the distances if they don't know the coordinate system.

[HanBnrd]

Sure, I guess I was more thinking in the case where it's made required in snirf specs, and therefore snirf-loading libraries make it impossible to load files that don't have coordinateSystem, people who want to analyse legacy files (eg. from already published open-access datasets) and were just planning to compute distances from 3D pos will not be able to load without tweaking their snirf files. But it's probably a very small use case.

Personally, I'm fine with making it a requirement, it's a good step towards standardisation I think.

[dboas]

The plan is for the validator to be aware of the snirf version number, and so this should not break older snirf files, provided they have the older version number indicated in the files contents.

[samuelpowell]

Have the coordinate system be mandatory if sourcePos3D and detectorPos3D are present.

I expect that the vast majority of fNIRS recordings are made in some arbitrary space with landmarks for registration. Most fNIRS software is written for this case and may be unlikely to support 'standard' spaces more commonly encountered in e.g. fMRI. Though of course, the data may move into a standard space during processing.

So I'd support this so long as this 'default' case is easy to specify - I guess this is as you are suggesting @dboas ?

Have landmarkPos3D and landmarkLabels be recommended if sourcePos3D and detectorPos3D are present.

This need is dependent on the specific co-ordinate system? In any case, best to say less than more unless we're enforcing something or guidance is required.

[dboas]

@samuelpowell , yes, you captured what I am suggesting. Looks like you and I are on the same page.

Do we want to request that someone make the modification to make /nirs(i)/probe/coordinateSystem required if 3D positions is present. And recommending, but not requiring the presence of /nirs(i)/probe/landmarkPos3D? And then do a pull request.

[HanBnrd]

I can work on the PR