Adding "EEGLAB" keyword as valid coordinate system for EEG

[arnodelorme]

It seems there is a new requirement of the BIDS validator that channel locations should be in the RAS coordinate system. I was under the impression that we could specify the coordinate system but, apparently, “RAS” is the only coordinate system allowed now (which makes defining the field "EEGCoordinateSystem" useless).

Note that of the 40 EEG datasets on OpenNeuro, NONE uses the RAS system right now (to my knowledge) and all use the ARS coordinate system. This new requirement seems it will create problems in terms of backward compatibility.

I have talked to people who exported some EEG data recently. Since the BIDS validator generated an error on defining the coordinate system as ARS, then simply removed the "EEGCoordinateSystem" JSON field (so now BIDS assumes by default channel locations are in the RAS coordinate system, while they are in fact the ARS one).

@robertoostenveld @sappelhoff please share your thoughts.

[sappelhoff]

hi @arnodelorme :wave: thanks for raising this issue.

It seems there is a new requirement of the BIDS validator that channel locations should be in the RAS coordinate system.

Where do you get that impression from? RAS was in fact never an accepted coordinate system, see Appendix VIII.

Currently the only "accepted" keywords for EEG are CapTrak, and Other. If users specify Other, they have to make an extensive description of the coordinate system in the EEGCoordinateSystemDescription field.

If you have a well defined and commonly used coordinate system, it would be great if we could add that to the BIDS specification, so that users may choose between CapTrak, Other, and your new ExampleName coordinate system. For you that'd have the benefit that you can outsource the big EEGCoordinateSystemDescription to the BIDS specification.

Please note that we are asking for exactly that in the appendix: It says:

If you believe a specific coordinate system should be added to the list of restricted keywords for MEG, EEG, or iEEG, please open a new issue on the bids-standard/bids-specification GitHub repository.

---

This new requirement seems it will create problems in terms of backward compatibility

It seems like that, that's true. However, the issue arises not because the specification has changed, but because the validator is now covering parts that it did not cover before. Thus, old issues that passed silently so far, are now revealed. RAS / ARS were always "invalid" as values for the EEGCoordinateSystem. The reason for that is, that the information is not sufficient: If you specify RAS, where is the origin of the coordinate system?

I mentioned the two solutions above (using Other+EEGCoordinateSystemDescription, or adding a new coordsystem to BIDS).

---

Finally, please have a look at #700 where I want to remedy several aspects for CoordinateSystems.

[arnodelorme]

Thank you @sappelhoff,

If you specify RAS, where is the origin of the coordinate system?

Could it be at (0, 0, 0) based on the coordinate system used for the electrodes? Then the coordinate system would only specify axes' orientations but not the coordinate of the origin.

I am reluctant to use "Others" and then add a text description to "EEGCoordinateSystemDescription". The goal is to be able to export/import channel coordinates automatically (and unambiguously). Could we add "EEGLAB" as a keyword for "EEGCoordinateSystem"?

Otherwise, what would you recommend?

[sappelhoff]

Adding eeglab as a keyword would be fine with me, if there is a commonly used coordinate system that eeglab uses internally. However it would have to be properly documented, including a description of where the origin is. I think robert may be able to chime in on this in a couple of days.

I recommend that you take a look at the documentation of the captrak coordinate system in the fieldtrip wiki (link is in the appendix viii that I linked to above). You'll see that there is not too much information required.

[arnodelorme]

Thanks. We could potentially use Captrack. I will see if it is compatible with the EEGLAB format.

[arnodelorme]

Comment contributed by @cll008

I think we previously determined the EEGLAB system is closest to the CTF (or 4D Bti if ignoring units). i.e. nose +X, origin exactly between LPA and RPA:

Captrack nose is +Y and the origin is not exactly in between LPA and RPA:

This means the system is not the same from 90-degree rotation around the Z-axis. We would need the 3 fiducial points to recalculate the coordinate system.

[arnodelorme]

I personally think it would not be intuitive for users to store files with the CTF coordinate systems and would vote to have "EEGLAB" keyword as well.

[sappelhoff]

I personally think it would not be intuitive for users to store files with the CTF coordinate systems and would vote to have "EEGLAB" keyword as well.

Yes, that would be fine with me. Could you perhaps prepare a page on your SCCN wiki (which I assume is the main EEGLAB documentation) about the "EEGLAB" coordinate system? That page would have to include all necessary information, similar to the entries in the fieldtrip wiki.

Then, afterwards, we could prepare a PR to BIDS specification to introduce "EEGLAB" as a valid keyword, and link from the BIDS specification to the SCCN wiki/EEGLAB documentation.

What do you think?

[arnodelorme]

OK, that sounds good. Let me get back to you in a week or two.

[sappelhoff]

progress is also tracked here: https://github.com/sccn/bids-matlab-tools/issues/51

[arnodelorme]

We implemented the EEGLAB keyword with @cll008 . Is it possible to add this as a recognized keyword for the BIDS validator?

[sappelhoff]

Is it possible to add this as a recognized keyword for the BIDS validator?

yes, thanks for the news @arnodelorme and @cll008. Do you have a wiki entry / website now that is describing the "EEGLAB" keyword? That is, its axes, origin, and units that are conventionally being used?

Then we can make a PR to this repo (bids-specification), and bids-validator ... and potentially even release this as part of the upcoming (in a few weeks) 1.6 release.