-
Notifications
You must be signed in to change notification settings - Fork 33
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 to NoisyChannel a bad_by_psd method to tackle low-frequency artefacts #143
Comments
I am a bit hesitant to start including code in this repository that goes beyond the methods included in the original PREP. Perhaps you could open an issue here, on the repo of the original PREP: https://github.com/VisLab/EEG-Clean-Tools It would be interesting to see, whether the authors had originally considered a method like the one you proposed and why it's not included. Having that said, there are minor deviations / improvements from the original PREP that I am happy to accommodate here, as for example you suggested in #142, and as is documented here: https://pyprep.readthedocs.io/en/latest/matlab_differences.html What are your opinions @a-hurst @yjmantilla? |
I understand that the ideal would be for it to be put first in the Matlab version or at least that we get the answers to our questions. But the official Matlab PREP repo https://github.com/VisLab/EEG-Clean-Tools looks a bit abandoned (i see no maj since more than 2 years, no issues/PR answered since 2 years). I use the NoisyChannel module in my own automated pipeline (I have the impression that this module is used stand-alone by a lot of users) and I would like to contribute to this module but then it would depend on what kind of future/score you envisage for the Python PREP package.
|
@sappelhoff Hey Stefan, it's been a while! Hope you're doing well 🙂 Haven't touched EEG data in a few years, but I remember having similar discussions on a smaller scale re: matching MATLAB PREP behaviour exactly vs addressing shortcomings of MatPREP when we stumble on them. The solution we settled on then for improving on the original was having a My take is that since the original PREP seems to be largely unmaintained now, it makes sense for PyPREP to extend and improve upon the original as long as there are contributors willing to do so! These extensions should probably be optional, and the For the sake of maintainability and project scope, I'd say that PRs for new options should be considered as long as:
Does that make sense as a broad strategy? Also unrelatedly I realize I never finished that API rewrite for PyPREP I started ages ago (PhD + being the equipment/programming guy for multiple labs has been quite busy). I've got a bit more software engineering experience under my belt now vs when I started it, so I'll try to make some time to polish it off sometime soon. |
Doing great, thanks! Happy to hear from you, and happy to hear about your experiences in the past years!
Thanks for taking the time and thinking through this / communicating it so coherently (also thanks to @nabilalibou for your comments in the post before). I agree with the strategy, however I believe that this is the crucial point:
--> this will oftentime require setting up tests scripts with at least two different datasets. It will require some effort. But if somebody is willing to spend that effort and work diligently on it, I would be happy to review and to eventually include such a feature in PyPrep. |
sounds great :-) |
In my opinion, for a feature such as a new way of detecting bad channel, you would need a certain amount of EEG data on which to test + the groundtruth (channels labelled good or bad by experts). |
agreed
agreed, as long as we then also document their usage in dedicated examples that showcase their usefulness
sounds good to me. If you want to take this on, I am willing to review and to eventually include it into pyprep if it meets the standards discussed above. One important note for this is though, that I probably won't be able to commit a lot of time to this, so some patience will be required on this way 🙂 |
Ok then here we go :) |
Hey,
I like to implement the NoisyChannel class in my preprocessing pipeline and to I like to complete the detection by looking at which channel has a psd value in at least one frequency that is significantly different (given a Z-score threshold) than the others.
In term of code it would simply looks a bit like this:
It has given me good results, and complements deviation and correlation detection quite well.
In essence, it's a little redundant with
find_bad_by_hfnoise()
and less explicit but there a lot of use cases where we are not interested in >50 Hz frequencies andbad_by_psd
allow to tackle channel parasitized by low delta noises (like sweat electrodes) or gamma noises.What do you think about a new way to tackle artifacts based on PSD ?
The text was updated successfully, but these errors were encountered: