[MRG] Add viz of auto-noisy segment detection

[hoechenberger]

This is currently non-interactive (purely static viz) until we've decided how to best add interactivity.

[agramfort]

Shall we aim to have this in the report ?

[hoechenberger]

Shall we aim to have this in the report ?

Very good point. Yes I think we should. Need to adapt the pipeline to work with the new BIDSPath first, though, before proceeding with this PR!

[jasmainak]

why is this not in MNE?

[hoechenberger]

Hey @jasmainak, so the code in this PR is based on what can be found in the Maxwell filter tutorial of MNE, see https://mne.tools/dev/auto_tutorials/preprocessing/plot_60_maxwell_filtering_sss.html#using-sss-and-maxwell-filtering-in-mne-python

You can also find an example plot there.

The reason this is currently not in "MNE proper" is that we haven't decided how to best implement this. So I'd consider the current code in this PR as temporary, until we have a better solution built right into MNE!

[jasmainak]

can you share an example plot?

[hoechenberger]

The figures are now automatically added to the report

[agramfort]

@hoechenberger can you share a rendered artifact on circle when you have one?

[hoechenberger]

@agramfort Absolutely!

… I see it just failed, need to fix that :(

[hoechenberger]

Also forgot to mention:
This now stores the scores returned by find_bad_channels_maxwell() as a JSON file, which is later used to retrieve those values when creating the figures.

[hoechenberger]

@agramfort
https://511-167957354-gh.circle-artifacts.com/0/reports/ds000248/sub-01_task-audiovisual_report.html#6

[agramfort]

beautiful !

[agramfort]

thx @hoechenberger

cc @SophieHerbst

[hoechenberger]

Feedback I got from non-neuroscience friends who know their sh*t about design and accessibility:

• the gray vertical lines are awful
• the colormap may not be optimal; should try out "inferno", "plasma", "magma"
• interactivity typically adds a huge improvement in UX and usefulness to such figures

[agramfort]

no objection !

…

[SophieHerbst]

Very nice @hoechenberger!
Do we now have a documentation somewhere of how the 'score' is computed (ideally in the bad channel detector function)?

[hoechenberger]

Do we now have a documentation somewhere of how the 'score' is computed (ideally in the bad channel detector function)?

From the "Notes" section of the find_bax_channels_maxwell() doc:

I tried to follow this through by stepping through the code line by line. I'm fine until including step 4; but step 5 either doesn't happen as described, or I'm misunderstanding something. What we do in the code in step 5, to my understanding, is we check if zscore(dk) > limit, where limit is user-supplied (and 7 by default).

What we return as the "noisy score" is zscore(dk).

@larsoner could you shed some light onto this? Am I missing something, or is the documentation outdated?

[hoechenberger]

Friendly ping to @larsoner – could you help me here? :)

[larsoner]

I tried to follow this through by stepping through the code line by line. I'm fine until including step 4; but step 5 either doesn't happen as described, or I'm misunderstanding something. What we do in the code in step 5, to my understanding, is we check if zscore(dk) > limit, where limit is user-supplied (and 7 by default).

A zscore(d) is just (d-mean)/std. So if you're checking d>mean+limit*std, equivalently you're checking (d-mean)/std>limit, i.e. zscore(d)>limit

[hoechenberger]

A zscore(d) is just (d-mean)/std. So if you're checking d>mean+limit*std, equivalently you're checking (d-mean)/std>limit, i.e. zscore(d)>limit

Bazinga! You're absolutely right, thank you!

Do you think it would make sense to adjust the user-facing documentation to make this relation between limit and dk more obvious? i.e., state that d is being z-transformed to a z-score, and that limit is, effectively, given in z-scores too?

[larsoner]

A parenthetical mentioning that this is equivalent to the zscore exceeding limit would be fine

[agramfort]

agreed