Skip to content
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

Draft
wants to merge 9 commits into
base: main
Choose a base branch
from

Conversation

jschepers
Copy link

@jschepers jschepers commented Nov 7, 2024

Changes

  • Added the code from Add support for MNE-ICALabel #812 by @hoechenberger
    • Comment: In the newer version of mne-bids-pipeline the ICA is divided into two scripts, therefore I had to divide the code into these scripts.
  • @behinger added two config variables ica_use_ecg_detection and ica_use_eog_detection to control whether MNE eog/ecg detection should be used on the ICs
  • We implemented that the user can specify in the config file (using the variable icalabel_include) which labels/ICs to include. Default is ["brain","other"].
    • Comment: We should add tests for this e.g. No value given -> Default should be used, Empty list or wrong labels -> Error
  • Added plots of the excluded ICs to the report together with their labels and the probability of the labels.
    • Comment: The plotting needs improvement e.g. combine all single plots in one plot

Before merging …

  • Changelog has been updated (docs/source/dev.md.inc)

Copy link

welcome bot commented Nov 7, 2024

Hello! 👋 Thanks for opening your first pull request here! ❤️ We will try to get back to you soon. 🚴🏽‍♂️

Copy link
Member

@larsoner larsoner left a 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
Copy link
Member

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

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?

Copy link
Member

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),
Copy link
Member

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.)

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

Copy link
Member

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"]
Copy link
Member

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[
Copy link
Member

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

Suggested change
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
Copy link
Member

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]?

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

Copy link
Member

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)

@behinger
Copy link

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:

  1. 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)
  2. 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).

Copy link
Member

@larsoner larsoner left a 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
Copy link
Member

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
Copy link
Member

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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants