Improving EDF reading in line with specification
See original GitHub issueDescribe the new feature or enhancement
In https://github.com/mne-tools/mne-python/pull/9694#issuecomment-908135503, I realized that the EDF specification can “encode” the channel type. One can have a label string in EDF be:
EEG Fz
, implying that it is the Fz channel of eeg
type. However, it’s “optional”.
For exporting EDF data, I would like to augment the export to encode the channel type, such that if you have channels:
EOG1, ECG1, A1, A2, A3, Fz, Cz
, then they would be written to EDF like:
EOG EOG1
ECG ECG1
sEEG A1
sEEG A2
sEEG A3
EEG Fz
EEG Cz
Describe your proposed implementation
First, I would modify these lines: https://github.com/mne-tools/mne-python/blob/22cd7747529db7895345917c4d3884a482ed8ab3/mne/io/edf/edf.py#L387-L416
to allow for backwards-compatible behavior that also then sees if there is the “channel type” encoded in the label string.
Additional comments
This addition would not “hurt” our codebase, since it really just adds backwards-compatible behavior to allow for additional parsing of the channel type upon reading the EDF file. In addition, it would add more robust exporting. Overall, it is an improvement in our roundtrip of compliant EDF files.
That way I can modify the string of PRs:
See:
- https://edfplus.info/specs/edftexts.html#signals for description of string channel types in EDF
- https://edfplus.info/specs/edftexts.html#label for the specification of the channel label in EDF
Issue Analytics
- State:
- Created 2 years ago
- Comments:14 (14 by maintainers)
Top GitHub Comments
So if you have the following channels:
Then a parameter would either let their labels be written as the following in the EDF file?
or
Is there any reason to want the labels be the first way, rather than the second? Mistakes by user?
Indeed I would make a list of all the channel names that had a type that we didn’t know and say we mapped them to EEG at the end, something like: