-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add reader for annotations in MIT format #12660
Comments
Agreed and rather than |
If we triage based on file extension than IMO the extra param isn't necessary. But if in future triaging based on file extension becomes impractical then I agree |
Wow this would've helped my life a long time ago :p. I always thought those were junk files! Perhaps some ppl in my old lab are interested. |
Hello All! Maybe it can be incorporated into MNE? Alternatively, I don't mind implementing it myself without using the package. |
Describe the new feature or enhancement
The CHB-MIT Scalp EEG Database (physionet) has annotation files that MNE can't currently read. It's been asked about at least twice on our forum (one, two) and @Teuniz helpfully explained there what the annotation format is, which means it is possible for us to write a reader for the format.
Describe your proposed implementation
a new private func
_read_annot_mit()
or so, and accompanying logic in the existingmne.read_annotations()
function to triage to the new private func.Describe possible alternatives
A separate public function for reading just this type of annotation. Why might that be preferable? The existing
mne.read_annotations()
triages based on file extension. In the dataset linked above the file extension is.seizure
, but the annotation format was designed for ECG so it's likely that there are files in this format with.ecg
extensions out there too, and possibly other extensions as well. This makes it hard to know what file extension(s) to use to identify this format, so a separate reader would be more flexible.Another possibility is adding a new parameter to the existing reader func (
mit_format=False
or so). If this switch wereTrue
, we triage to the new private func regardless of what the file extension is.My preference is to overload the existing reader function, and (for now) only triage based on
.seizure
extension (since it's the only one we know our users want supported). We can always later add to the list of file extensions that map to this format, if users ask us to.Additional context
Here's the text of the reference spec.
Copied from the wayback machine because the original page was timing out for me on the day I opened this issue.
The text was updated successfully, but these errors were encountered: