Skip to content

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 No need to test that pydantic does this -- tested locally quickly and seems to do the right thing
  • 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
  • Changelog has been updated (docs/source/dev.md.inc)

Closes #812

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

"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!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay I finally came back to this! Things seem to be working at my end.

FYI some of the components have a kind of low probability... looked like in testing at one point one of the things labeled as blink had a probability of like 0.35 or so. So not sure if you want to add a threshold as suggested by @behinger above. But in the meantime I think this is working as intended, @behinger @jschepers feel free to try it and look etc!

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

@behinger
Copy link

ok, I tried to find time in the last month's and it didn't happen. I'd be happy if you can take a look and fix up some things if they are easy. I have some people in my team who could also take a look but o.c. aren't super familiar with the codebase

@larsoner
Copy link
Member

Okay I'll try to look next week @behinger !

@mpcoll
Copy link

mpcoll commented Mar 21, 2025

Thanks for all your work on this! I'm looking forward to seeing this functionality integrated into the pipeline.

While you're working on this, I wanted to suggest a potential enhancement: allowing users to only remove ICA components that were classified with sufficient confidence (using the "predict_proba" output from mne_icalabel). In my experience, removing everything that isn't classified as "brain" or "other" can sometimes be too conservative and may remove components unnecessarily.

This could be implemented by simply adding a probability threshold parameter in the configuration, where potentially artifactual components would only be removed if their classification confidence exceeds this threshold. This would give users more control over the artifact rejection process and potentially preserve more of the signal in ambiguous cases.

Thanks!

larsoner and others added 6 commits July 23, 2025 10:54
* upstream/main: (55 commits)
  [pre-commit.ci] pre-commit autoupdate (mne-tools#1099)
  FIX: sanitize tags (mne-tools#1097)
  [pre-commit.ci] pre-commit autoupdate (mne-tools#1098)
  [pre-commit.ci] pre-commit autoupdate (mne-tools#1096)
  [pre-commit.ci] pre-commit autoupdate (mne-tools#1095)
  Custom metadata (mne-tools#1088)
  fix mf_int_order; add mf_ext_order (mne-tools#1092)
  [pre-commit.ci] pre-commit autoupdate (mne-tools#1093)
  [pre-commit.ci] pre-commit autoupdate (mne-tools#1091)
  [pre-commit.ci] pre-commit autoupdate (mne-tools#1090)
  [pre-commit.ci] pre-commit autoupdate (mne-tools#1089)
  [pre-commit.ci] pre-commit autoupdate (mne-tools#1087)
  [pre-commit.ci] pre-commit autoupdate (mne-tools#1085)
  [pre-commit.ci] pre-commit autoupdate (mne-tools#1084)
  [pre-commit.ci] pre-commit autoupdate (mne-tools#1082)
  Properly compute rank (mne-tools#1069)
  [pre-commit.ci] pre-commit autoupdate (mne-tools#1080)
  avoid backslash in fstring and frontload fsaverage download (mne-tools#1078)
  fixup generation of template config files (mne-tools#1074)
  [pre-commit.ci] pre-commit autoupdate (mne-tools#1075)
  ...
…_label

* jschepers/merge_ic_label:
  [pre-commit.ci] auto fixes from pre-commit.com hooks
@larsoner larsoner marked this pull request as ready for review July 23, 2025 18:21
name: Install dependencies
command: |
pip install -ve .[docs]
pip install -ve .[docs] onnxruntime
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I accidentally forgot this in one run and got a reasonable message:

FAILED mne_bids_pipeline/tests/test_run.py::test_run[ERP_CORE_N170] - ImportError: Missing optional dependency. ICLabel requires either pytorch or onnxruntime. Use pip or conda to install one of them.

so I think the error message propagated to the end user is working!

@behinger
Copy link

Thanks! We have internally some improvements to the code as well, I let the research assistant know to pr/merge with your changes.

@larsoner
Copy link
Member

Yes feel free to push! I'm going to restart CIs but I expect them to come back green

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.

4 participants