Suggestion: `template_<x, y, z>` for `*_electrodes.tsv` for EEG, MEG, iEEG

[marlenemeyer]

When converting EEG data into BIDS using the data2bids function from fieldtrip with .set files, the *_electrodes.tsv file is automatically created. We noticed that this does not allow to discriminate if the data in *_electrodes.tsv were recorded or come from a (layout) template. In discussion with @robertoostenveld we thought that a good solution to prevent this might be to add the option of template_x/y/z coordinates to *_electrodes.tsv, like for near-infrared spectroscopy the template_x/y/z column names for *_optodes.tsv. Would this be a useful and doable option?

[robertoostenveld]

Tagging @arnodelorme @CPernet @sappelhoff @ftadel @gllmflndn as stakeholders in this.

An example opcodes file with measured and template positions can be seen here.

[neuromechanist]

Thanks a lot for bringing up this issue.

We (@smakeig, @arnodelorme) have a similar issue with our efforts to release the Helathy Brain Network (HBN) data in BIDS format. HBN currently has EEG data for ~3000 subjects, and around half have 3D scans from the electrode locations.

We plan first to release the BIDS dataset with template electrode locations and update the dataset later on for subjects with personal electrode locations.

Besides adding columns to *_electrodes.tsv, there might be two other options that could be straightforward to implement:

1. Not including *_electrodes.tsv. This file is optional (not RECOMMENDED) in either EEG or fNIRS. Also, I could argue that with the template locations, the contents of *_electrodes.tsv may not even constitute raw data from the subject. The template electrode location information is more of a device feature. This approach does not require any change in BIDS. Rather, it requires a change in the tools not to generate a *_electrodes.tsv` when the electrode locations are not explicitly imported from an external source. I think @arnodelorme has already implemented this optin in the BIDS-Matlab-Tools. This is the approach we currently have for the HBN project.
2. An additional field in the *_eeg.json sidecar, such as electrodeLocationSource, can indicate how the electrode digitization was performed. As we know, not all digitization modalities are created the same, and there can be significant errors with some of them. Currently, there is no place to indicate which system was used for electrode digitization. Since the *_coordsystem.json is also optional if there are no *_electrodes.tsv*, it might not be a good place to indicate this information. So, having this field in the *_eeg.json sidecar ensures that the user knows about the source of electrode locations, which would be essential for transparency and reproducibility.

[CPernet]

I have no preferences, but I'd like to see a central place with a bunch of defaults shared (and maybe derivatives neighbourhood matrices)

[robertoostenveld]

@neuromechanist regarding your point 1: it should remain an option (and probably the preferred way for well-known electrode caps) to not specify the _electrodes.tsv at all. However, there are sometimes lesser known electrode caps for which (lab specific) template positions exist and which are not included in the major packages (like EEGLAB and FieldTrip). I think that especially those benefit from sharing in template_x/y/z. I agree with @CPernet that a complete and well-curated central registry of template electrode positions would be nice to have, but I consider it less likely for that to be created and to get the visibility required for BIDS to start depending on it.

Regarding point 2: Agreed that additional information about how electrode positions were recorded would be of value. Rather than storing this in the _eeg.json, I would prefer this to be represented in an _electrodes.json file. This would make it similar as the _events.json file which documents stimulus presentation computer and software details. The to-be-defined _electrodes.json file could then also document the provenance of the template electrode positions.

Consistent documenting electrode positions should also be considered in relation to iEEG, where the iEEGCoordinateProcessingReference field in the _coordsystem.json already exists. ... So perhaps an _electrodes.json would collide with that.

[ftadel]

Tagging @arnodelorme @CPernet @sappelhoff @ftadel @gllmflndn as stakeholders in this.

Hi Robert,
Please note that I quit the Brainstorm team. I am in the process of leaving neuroimaging for good and will not respond to github mentions anymore.
For anything related with Brainstorm, please contact Raymundo Cassani at McGill (@rcassani) and Takfarinas Medani at USC (@tmedani).
Cheers,
François

[robertoostenveld]

Hi @ftadel,

OK, will do. It has always been a pleasure to work with you and I wish you all the best with your continued career outside of neuroimaging!

[sappelhoff]

However, there are sometimes lesser known electrode caps for which (lab specific) template positions exist and which are not included in the major packages (like EEGLAB and FieldTrip). I think that especially those benefit from sharing in template_x/y/z.

agreed

Agreed that additional information about how electrode positions were recorded would be of value. Rather than storing this in the _eeg.json, I would prefer this to be represented in an _electrodes.json file.

agreed about specifying this in electrodes.json.

Both of this should be already possible under present BIDS rules:

1. arbitrary columns can be defined (and documented) in electrodes.tsv (and electrodes.json)
2. "additional properties" (i.e., key-value pairs where the key is not a column name in the corresponding electrodes.tsv) are already possible in electrodes.json (and the practice of documenting metadata in JSON files that goes beyond what's present in columns of the corresponding TSV file is already well established in BIDS, see: https://bids-specification.readthedocs.io/en/latest/modality-specific-files/task-events.html#stimulus-presentation-details)

HOWEVER

I would be in favor of extending the existing template_<x, y, z> metadata from NIRS to MEG, EEG, and iEEG.

• https://bids-specification.readthedocs.io/en/latest/glossary.html#template_x-columns
• see also example linked in Robert's comment above: Suggestion: template_<x, y, z> for *_electrodes.tsv for EEG, MEG, iEEG #1601 (comment)

Furthermore, if we can all agree on which metadata about measuring positions would be good to have strongly defined in BIDS, I'd be in favor of adding that as well. But I consider this to be a second issue, separate from the above.

---

• xref: Discussion: BIDS-RAW specification --> Sharing of template data ... yes/no? #318