Event markers per channel

[bdyetton]

Describe the problem

Events and annotations can only be specified for all channels.

Describe your solution

A way to assign an event to a specific channel, along with plotting and analysis routines that handle that would be extremely helpful for removing specific segments of specific bad channels, or for any decoding/classification of channel-wise EEG features. Maybe an extra column in the events array which specifies the channel would be a good way to input this information.

Additional context

I understand this is a large request, but id like to start a discussion here and see if anyone else is interested in this feature.

[agramfort]

@bdyetton this feature has been requested in the past by Boris Burle in Marseille. He had goor arguments. I think it's doable in the near future with the Annotations object. Can I ask what is your use case?

[bdyetton]

We are interested in sleep features such as spindles, k-complexes, and slow oscillations. These short (~0.5-2s) generally occur in each channel independently (although sometimes they appear in many at the same time).

It would be great to:
a) Mark these events, by hand, in the plotting tool (much like you can highlight segments currently)
b) Be able to add the output of sleep feature detection algorithms (start, duration, channel) to a mne.io.RawArray so we can then plot and view them
c) Be able to save these annotation locations back to disk with the EEG data (as .fif or preferable, as .edf).

How these single channel annotations would work with the mne.Epochs object is not something I've thought about as we don't use the epochs object that much.

Marking per-channel artifacts would be nice also, as sometimes an electrode can go bad halfway through a night of sleep, but we don't want to throw away the whole channel (by marking electrode as bad), or throw away half the night (by marking a segment of all channels as bad).

p.s. @agramfort Great work on that sleep staging algorithm, we are hoping to give it a go soon ;)

[agramfort]

ok so we have the same use cases. you may also be interested in this preprint https://arxiv.org/abs/1807.05981 that will be published at MLSP Conf https://signalprocessingsociety.org/blog/mlsp-2018-2018-ieee-international-workshop-machine-learning-signal-processing let's make this happen !

[bdyetton]

O wow! I had this same idea and was tempted to try it out this year.
Glad it worked out! Will the code be made available after the conference? I'd love to try it out.

You might be interested in this: https://osf.io/8bma7/ if you want higher quality spindles for the MASS dataset.

[agramfort]

cool ! I did not know about these data.

ping @Slasnista

Yes we should make the code available at some point. We're about to send the journal paper.

[larsoner]

Annotations currently has onset, duration, description. I suggest we add ch_names which is a tuple-of-tuples of channel names that the annotations apply to (like our epochs.drop_log). If the tuple-of-tuples is all empty, we don't write it to disk (I/O the same). If it's not empty, we write it to disk, probably however we do with drop_log. I think this gets people what they want in a backward-compatible way. Then we "just" have to figure out how to draw this in raw.plot, which I think means drawing either a single fill_between like we do now when it applies to all channels, or M fill_betweens for the M visible channels out of the N channels the annotation currently applies to.

[agramfort]

yes changing annotations is not too hard but it means the plotting code needs to deal with it. I feel it's much more painful... you need to be able to annotate a subset of channels that may not be below eachother

…

[larsoner]

Having worked on the plotting code I actually don't think it's going to be very difficult actually. So if that's all that's stopping us I could give it a shot

[agramfort]

Give it a try

[cbrnr]

Visual channel-specific annotations is one thing, but are you planning to support creating them as well?

[drammock]

I am less worried about the plotting and more worried about downstream processing. See recent discussion here: https://mne.discourse.group/t/annotations-per-channels/2693/4

[larsoner]

I say we start by treating them like any other annotation -- i.e., ignore the ch_names attribute -- and things will proceed as normal, so it's just an aesthetic and bookkeeping change for people to make if they want to. For example, if some marks manually a BAD_flux_jump just for MEG0111, that entire segment would still be ignored in epoching, and treated like an acquisition skip in filtering, etc. just as it is now depending on the skip_by_annotation parameter.

However, in future PRs things like this become possible:

1. We could modify find_bad_channels_maxwell and annotate_flat to mark badness channel-by channel over time (easy)
2. Modify maxwell_filter to reconstruct BAD_-marked MEG channels just during their bad times (hard)
3. Update WIP ENH: interpolate EEG channels per epoch #1869 repair the channels on a per-epoch basis (easy to get working, medium to make computationally efficient)

In other words, we implement the marking and storage, then make things annotations-channels-aware gradually as we can. This is analogous to how we implemented annotations in the first place, then gradually made downstream functions and methods annotation-aware as we found it beneficial or necessary to do so. Most places we have a skip_by_annotation or similar argument came into being this way, and it seemed to work as both a creator of some of those PRs and as a consumer.

[cbrnr]

Sounds good!

4. Support creating channel-specific annotations in raw.plot (medium to hard)

[drammock]

Are any of these tasks suitable for the upcoming sprint @larsoner ? If so let's wait until then to implement.