mne-python icon indicating copy to clipboard operation
mne-python copied to clipboard

ENH: Repair channels on a per-epoch basis

Open larsoner opened this issue 4 years ago • 5 comments

Now that we have #8896 we can redo #1869 such that we can repair channels on a per-epoch basis.

The challenge I think will be making it efficient, but I think this will actually not be too bad if we refactor the interpolation code:

  1. Do the slowest part once: self- and cross-dots between all channels
  2. Do the faster part each time we need to: pseudoinversion based on all "from" good channels to all "to" bad channels for the given epoch
  3. Use a simple, small LRU cache to store the from-to paired pinv results (if you use more than 100 different "bad" combinations, which should be very rare, you start to pay a price for having to redo some of the pinv calls, but even this probably won't be too bad).

In principle someday we could do this on raw data, but we have to figure out how to prevent discontinuities between the original and reconstructed data segments. This should be doable with some suitable smooth windowing but it's not as easy as the epochs case.

larsoner avatar Feb 24 '21 13:02 larsoner

There is code in autoreject that does the caching. It would be great if we can copy it and autoreject uses the public API of MNE

jasmainak avatar Feb 24 '21 13:02 jasmainak

Having this in mne will simplify a lot the auto reject code !

agramfort avatar Feb 24 '21 17:02 agramfort

@jasmainak do you want to try adapting the autoreject code here (according to the plan above) now that #8896 is in?

larsoner avatar Oct 14 '21 16:10 larsoner

I guess the place to start would be with a PR to take care of #8951 first

larsoner avatar Oct 14 '21 16:10 larsoner

I could give it a go in late November if nobody beats me to it. I realized that 1. and 2. is implemented in autoreject but not 3. Furthermore, autoreject uses a data structure that is different from annotations. So, it might require non-trivial changes and not worth changing everything.

The key decision point that probably affects autoreject is the (internal) API for precomputing the cross_dots and self_dots. Currently, in autoreject this happens via _compute_dots that was pulled out of _fast_map_meg_channels and returns a tuple. I'm scared this will break one day because it heavily relies on private API of MNE. If we agree upon a common API that doesn't require too much change in autoreject, that would be great.

jasmainak avatar Oct 15 '21 19:10 jasmainak