Describe the problem
Finding bad channels is a crucial step in EEG pre-processing for making the data amenable for analysis. Detecting bad channels also has implications in re-referencing the EEG data further down in the pre-processing pipeline. Currently, MNE does not have the functionality for detecting bad channels using a single function. Also, manually rejecting bad channels by visual inspection could be cumbersome and subjective.
Describe your solution
The criteria used by the PREP pipeline is quite powerful for detecting the noisy channels and is shown to be more sensitive than the EEGLAB鈥檚 pop_rejchan function. Bad channels are detected by testing for Nan values, DC values, robust standard deviation, finding correlations among 50 Hz low-pass filtered signals, finding correlations between channels using random sampling consensus prediction, high-frequency noise, and low signal-to-noise ratio.
I would like to incorporate this functionality in MNE.
Additional context
Automagic in MATLAB posses this functionality by implementing the PREP pipeline.
How does PREP compare to autoreject?
@drammock PREP in itself is an EEG preprocessing pipeline concerned with filtering, bad channel detection and re-referencing. They follow an exhaustive list for detecting bad channels which includes rejection based on the RANSAC method, high-frequency noise, and SNR, to name a few.
What I mean is, autoreject also detects and repairs bad channels (and includes an implementation of RANSAC). Can you say a little more about what (specifically) you want to add that isn't already covered by autoreject?
see https://autoreject.github.io/generated/autoreject.Ransac.html
https://autoreject.github.io/auto_examples/plot_ransac.html
the autoreject paper provides a benchmark with this method
>
@agramfort Agreed that autoreject can detect bad channels are trials based on deviation and correlation, however, in PREP, bad channels are also detected by having HF noise where the signal is 50Hz low pass filtered and the ratio of the median absolute deviation of the high and low-frequency components is used to compute the robust z-score.
yes PREP does more things than autoreject. Any contribution with example we
can
document are welcome
in practice though, it's RANSAC which PREP mostly relies on. It's what I've observed. The bad channels detected by the other methods are a subset of this.
@jasmainak not necessarily since RANSAC relies only on corrrelation.
cc @sappelhoff, and crossref to #7048 and #7053. Here are some possible ways forward:
Once we decide that, we can start discussing API / implementation details.
@sappelhoff @agramfort @jasmainak @larsoner @cbrnr any strong opinions?
I would keep this as autoreject in a dedicated package built on top of MNE.
It will speed up development and authors will keep ownership and
maintenance responsibility.
>
@drammock @agramfort Would you say autoreject, or pyprep is a better place to start? It seems like they are doing very similar things, but autoreject having more functionality?
We can start by making separate issues, and consolidating PRs to address each of these separate funcs including but not limited to:
I think it's probably up to @jasmainak and @sappelhoff whether these additions go into autoreject or pyprep. Based on sappelhoff/pyprep#2 I'm guessing Stefan is fine with pyprep as the home for this; @jasmainak is that OK with you?
Either is fine by me since we're all a happy family :) While a separate package is nice for speedy development, it duplicates efforts and fractures the ecosystem a bit. Ultimately, we want to give researchers better tools to look and process their data. Currently, we have some preprocessing code in MNE-sandbox, then a separate repository for autoreject, a separate repo for PREP now. I think there are also some separate scripts for preprocessing CTF data that are floating around. It would be helpful to consolidate all these in a single place.
That being said, I think it's fine to proceed with @sappelhoff 's repository for now and think about consolidation plans in the future.
I think that autoreject is better off remaining an "autoreject-only" repository: It keeps the codebase clean and there is a tight connection between the scientific publication and the codebase.
I also agree with Alex that it's better to keep these rather large preprocessing pipelines (PREP, autoreject, ...) as minimal repositories, separate from MNE-Python ... so that they can be more flexibly developed ... and installed on a use base.
Same reason as with autoreject, I think that the pyprep repo would be a good home for the Python implementation of PREP.
Currently, there is also some part of the FASTER pipeline in the pyprep repo, based on @wmvanvliet's code
... I am happy to get rid of FASTER (transferring to another repo), and also API changes etc. are no problem.
Great to see people picking up this kind of work! The pyprep repo seems like a good place for it. Not sure about the current API of the Noisy class though. I would personally go with either plain functions or a scikit-learn type fit()/apply() API.
馃憤 for implementing all/part of PREP in pyprep.
we need to create a page with related mne projects in the main mne.tools
pages
>
On it
The related projects page already exists, we can just add pyprep to it. https://mne.tools/stable/install/pre_install.html
On November 14, 2019 7:21:16 AM PST, Eric Larson notifications@github.com wrote:
On it
Hah! Missed that. I'll add a couple of things
Most helpful comment
Great to see people picking up this kind of work! The pyprep repo seems like a good place for it. Not sure about the current API of the
Noisyclass though. I would personally go with either plain functions or a scikit-learn typefit()/apply()API.