Since I have a little "free time" these days, I am wondering if there is some interest in adding autoreject to MNE. Although the API of autoreject (local) is not yet settled, I think adding autoreject (global) would be quite easy without any additional dependencies. We could do something like:
import mne
mne.Epochs(..., reject="autoreject",)
ICA(..., reject="autoreject")
In the autoreject repository, I can internally call the MNE function so that those relying on it are not affected. Let me know.
+1 after doing the 0.1 release :)
I'd probably not bake this into the epochs constructor though as, usually, you interact with the autoreject outputs. Where the hack does the aureject object go Mainak when you do it the way you suggest here?
I'm actually suggesting something more simple than what you are probably thinking. What I propose is to do it in small steps. So to start with, I would just move the functionality offered by this example. And of course, it wouldn't be baked into the Epochs object. It would just be one line extra to call this method inside the constructor.
I am thinking at this point we should just copy the future autoreject API
into MNE preprocessing.
Then we can copy over some of the examples.
Then eventually add reject=‘auto’ when we know how to then get fixlog /
droplog etc.
As long as you want to look at autoreject results you want to have the
object. That’s ok. Also keep in mind how reject interacts with .get_data
and preloading. You don’t want to wait for autoreject until you get your
data from disk.
On Tue 6 Mar 2018 at 01:20, Mainak Jas notifications@github.com wrote:
I'm actually suggesting something more simple than what you are probably
thinking. What I propose is to do it in small steps. So to start with, I
would just move the functionality offered by this example
http://autoreject.github.io/auto_examples/plot_estimate_global_reject.html#sphx-glr-auto-examples-plot-estimate-global-reject-py.
And of course, it wouldn't be baked into the Epochs object. It would just
be one line extra to call this method inside the constructor.—
You are receiving this because you commented.Reply to this email directly, view it on GitHub
https://github.com/mne-tools/mne-python/issues/4989#issuecomment-370615590,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AB0fiiJ5PYqbicUsFNcuIS9Zwq9BZxo3ks5tbdY1gaJpZM4Sd3w-
.
what is preventing a 0.1 release now?
Api changes that are only 80 % realized and missing tests
On Tue 6 Mar 2018 at 13:22, Alexandre Gramfort notifications@github.com
wrote:
what is preventing a 0.1 release now?
—
You are receiving this because you commented.Reply to this email directly, view it on GitHub
https://github.com/mne-tools/mne-python/issues/4989#issuecomment-370764506,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AB0fipZblXE9qm2q5WADzgsNVOT7mg_hks5tbn-igaJpZM4Sd3w-
.
okay, let's discuss it in Inria next week :-)
I like autoreject. If we're adding cutting-edge ICA like Picard, may as well add autoreject.
It's happening Jona! But not before a proper release on pip and finishing
the API transition. Good news: we will do it these days.
On Tue, Mar 6, 2018 at 11:22 PM jona-sassenhagen notifications@github.com
wrote:
I like autoreject. If we're adding cutting-edge ICA like Picard, may as
well add autoreject.—
You are receiving this because you commented.Reply to this email directly, view it on GitHub
https://github.com/mne-tools/mne-python/issues/4989#issuecomment-370950408,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AB0fiucwh9jUmJh-GyPjMuPD3A3NNw7yks5tbwwngaJpZM4Sd3w-
.
This issue is still open!!! @jasmainak @dengemann
okay for me to close it. We can keep maintaining autoreject in a separate repo for now.
Ok. Would still be cool to have it here, it's a great tool!
Most helpful comment
It's happening Jona! But not before a proper release on pip and finishing
the API transition. Good news: we will do it these days.
On Tue, Mar 6, 2018 at 11:22 PM jona-sassenhagen notifications@github.com
wrote: