Error mapping values and descriptions for events_id

Hi MNE experts!

I was trying to generate BIDS-format events.tsv files for my meg data. However, I always found a mismatch between the events data I retrieved from the stim_channel and from the annotations.

  • MNE-Python version: 0.22.0
  • operating system: Ubuntu 16.04.5 LTS

the code was

import numpy as np
import mne
import mne_bids

# load raw data
sub_path = mne_bids.BIDSPath(subject='01', run=1, task='movie', session='movie', root=bids_dir)
raw = mne_bids.read_raw_bids(sub_path)

# get event data from stim channel
event_raw = mne.find_events(raw, stim_channel='UPPT001', min_duration=2/['sfreq'])

# save annot event data from stim channel
events_id = {'desp_{0}'.format(i) : i for i in np.unique(event_raw[:,-1])}
annot = mne.annotations_from_events(event_raw,['sfreq'], 
                                    event_desc={v: k for k, v in events_id.items()}, first_samp=raw.first_samp)

# get event data from annot
event_from_annot = mne.events_from_annotations(raw)

# compare event data from stim channel and annotation
event_raw == event_from_annot

It turns out that the third column (marker value) of [event_raw] and [event_from_annot] are not identical. Output details please see the pic blow. It seems to be related to the sorting somewhere.

Could you guys help me with this problem?



Hello, thank you for your report! This has actually been fixed in the latest development version of MNE-BIDS, and the fix will be included in MNE-BIDS 0.7, which we hope will be released within the next few days.

If you are impatient, you can install the development version via:

pip install -U

Best wishes,


Thanks! Perfect, I’ll update it to the latest dev version.

Hi Richard,

Thanks for your suggestions!

I tried it out with mne==0.23.dev0, mne_bids==0.7.dev0. It really works.
But it turned out that the bug was fixed with writing specifying events data in write_raw_bids:

write_raw_bids(raw, bids_path=bids_path, overwrite=True
               events_data=events, event_id=events_id)

but the bug remained when using annotations to write events data automatically:

write_raw_bids(raw, bids_path=bids_path, overwrite=True)

Hope with could help.


The annotations themselves don’t contain any event IDs we could use during writing, so this is actually to be expected. This is a limitation in MNE-Python.

What we probably could do, however, is: if the data contains annotations and you pass an event_id dict that maps event types (which, in this case, would be annotation names) to IDs, we can use this information to retain the correct event IDs. This would need to be discussed first, though…

Another thing we could do is extend MNE’s Annotations to gain an “event ID” field, but I’m not sure how difficult this would be

@sappelhoff @agramfort @larsoner WDYT?

Oh I see, it explains everything.
Thanks you very much!

Another thing we could do is extend MNE’s Annotations to gain an “event ID” field, but I’m not sure how difficult this would be

From the I/O end I would say it’s pretty easy to expand mne.Annotations to have this field.

I don’t really like it conceptually, though, since it’s storing something related to and specific to epoching in MNE-Python (the event_id str->int dict mapping, really having int in there at all) in the raw object, so I’m -1 on adding it.

Yes I agree, it’s not a good idea. I’ve started working on something in MNE-BIDS to make it easier to assign event IDs to existing annotations upon BIDS conversion. Nothing we need to solve in MNE-Python.