-
Notifications
You must be signed in to change notification settings - Fork 68
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 the code from PR "Add support for MNE-ICALabel #812" #1018
base: main
Are you sure you want to change the base?
Conversation
…input whether to do eog or ecg detection on ICs
…input whether to do eog or ecg detection on ICs
Hello! 👋 Thanks for opening your first pull request here! ❤️ We will try to get back to you soon. 🚴🏽♂️ |
for more information, see https://pre-commit.ci
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like a good start! Just a bunch of minor stuff here. Let me know if you want me to push some commits to make CIs happy
```python | ||
eeg_reference = "average" | ||
ica_l_freq = 1 | ||
h_freq = 100 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We might want to add a ica_h_freq
param
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
that would be a breaking change then?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nah doesn't have to be -- we can use ice_h_freq=None
as the default (as None
is what we use now), and people wanting to use icalabel would need to set it to 100.
"other", | ||
] | ||
], | ||
Len(1, 7), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we are really going for broke on this one, we should use the unique
pydantic workaround
pydantic/pydantic-core#820 (comment)
If you don't want to implement it here maybe add it as a # TODO:
comment in the ICA preprocessing scripts somewhere? (Don't add it in this file as it would make it messier.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I dont think I can really follow you there. Maybe something got lost, but what does "going for broke" mean?
@jschepers I dont actually see where we really select components to be excluded, but in their tutorial it is also quite confusing. I remember we looked at it, but it was some time ago. E.g. in eeglab you specify "remove muscle if probability >80%" and similar. How is this done here, do you remember? Else I will try to give this another spin in debug mode
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I dont think I can really follow you there. Maybe something got lost, but what does "going for broke" mean?
Sorry it's just an idiom -- in this case I mean if you want to put forth potentially a lot of effort to try to come up with a more complete/cool solution, you could. What we want here in not just a list with length between 1 and 7 with elements from a set of possible choices, but rather that they are unique elements (i.e., a user shouldn't put in ["eye blink", "eye blink"]
). But what you have here is already good enough!
if cfg.ica_use_icalabel: | ||
# The ICALabel network was trained on extended-Infomax ICA decompositions fit | ||
# on data flltered between 1 and 100 Hz. | ||
assert cfg.ica_algorithm in ["picard-extended_infomax", "extended_infomax"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
An equivalent check should probably live up in _config_import.py
``` | ||
""" | ||
|
||
icalabel_include: Annotated[ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think to be consistent all ICA-related stuff should be prefixed by ica_
so this should be
icalabel_include: Annotated[ | |
ica_icalabel_include: Annotated[ |
@@ -48,6 +48,8 @@ dependencies = [ | |||
"autoreject", | |||
"mne[hdf5] >=1.7", | |||
"mne-bids[full]", | |||
"mne-icalabel", | |||
"onnxruntime", # for mne-icalabel |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
... shouldn't this be in the deps of mne-icalabel
? At least maybe in an optional form like mne-icalabel[something]
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm a bit confused on this one, it is an explicit requirement for mne-icalabel:
https://mne.tools/mne-icalabel/stable/install.html#dependencies (pypi-tab)
but one could choose pytorch as well. My gutfeeling was that pytorch is the larger one of these two
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ohhh this:
The ICLabel model requires either pytorch or Microsoft onnxruntime.
I don't think we should make this choice for people in mne-bids-pipeline
requirements (i.e., shouldn't do it in our pyproject.toml
), and instead tell them to install one or the other, just like mne-icalabel
does. And in our CIs we can do that (either PyTorch or onnxruntime)
thanks for the quick feedback! We will still need some time to work on this, too many parallel things going on. Because we mainly develop in Julia, not everything is clear to us. I will ask some clarifications on the workflow. Just foreshadowing two PRs we want to submit:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks for the quick feedback! We will still need some time to work on this, too many parallel things going on.
Okay! FWIW I don't think it would be too much work for me to push a commit or two to address my comments if it would help. Happy to do it if it makes your life easier! But also happy to wait if you're motivated to do the work.
eyelink synchronisation: we understand it is a bit specific, but it is implemented in MNE, so we added a new step to support it (80% ready for PR)
Ooof this one is trickier. From working on a project recently where I had to do this for EEG and MEG data that were recorded simultaneously on two different systems... it wasn't trivial. Sometimes events were missing from one system at the beginning or end, other times for the other system, etc. And even if they aren't, you somehow have to specify which events are shared between the two systems, via events or annotations, and which to keep or discard, etc. In the end for that dataset I synchronized manually and concatenated the instances before BIDSifying them. So I think this deserves an issue to discuss first at least...
zapline: this will be added to the filter thing as a quasi-replacement for 50/60Hz notch filtering, based on meegkit (only just started with the planning of that one).
Sure, I think this has been brought up in MNE-Python before, okay to add meegkit
stuff here where it makes sense. I guess it would be inserted after the frequency filtering step but before regression, like between _04_frequency_filter.py
and _05_regress_artifact.py
?
```python | ||
eeg_reference = "average" | ||
ica_l_freq = 1 | ||
h_freq = 100 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nah doesn't have to be -- we can use ice_h_freq=None
as the default (as None
is what we use now), and people wanting to use icalabel would need to set it to 100.
@@ -48,6 +48,8 @@ dependencies = [ | |||
"autoreject", | |||
"mne[hdf5] >=1.7", | |||
"mne-bids[full]", | |||
"mne-icalabel", | |||
"onnxruntime", # for mne-icalabel |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ohhh this:
The ICLabel model requires either pytorch or Microsoft onnxruntime.
I don't think we should make this choice for people in mne-bids-pipeline
requirements (i.e., shouldn't do it in our pyproject.toml
), and instead tell them to install one or the other, just like mne-icalabel
does. And in our CIs we can do that (either PyTorch or onnxruntime)
Changes
ica_use_ecg_detection
andica_use_eog_detection
to control whether MNE eog/ecg detection should be used on the ICsicalabel_include
) which labels/ICs to include. Default is["brain","other"]
.Before merging …
docs/source/dev.md.inc
)