plot_compare_evokeds should have the same defaults for `combine`

[skjerns]

Currently the function mne.viz.plot_compare_evokeds creates two different plots depending on the number of selected channels:

• If one channel is selected (or present in the evoked), it will plot the ERP.
• If two or more channels are selected (or present), it will plot the GFP.

I think this behaviour is potentially misleading, and I would expect the function to have the same defaults for different channels, i.e. mean of the evokeds. As you can see in #10465 , this created quite a bit of confusion for me (probably mainly due to me being new to ERP analysis and not knowing what GFP meant).

I see this has previously already spiked a bit of discussion (e.g. #3393) and was introduced in #6166. By now, the gfp=... parameter has been removed in favor of the combine=None parameter, which defaults to a different value depending on the present/chosen channels.

I would suggest either

• make combine have the same default for all cases
• make combine an arg, i.e. make users forcefully choose a combination mode

Additionally, the docstring should reflect the importance of the combine parameter.

What are your thoughts on this?

[agramfort]

@skjerns the docstring at https://mne.tools/stable/generated/mne.viz.plot_compare_evokeds.html says:

so maybe the API in counterintuitive but I think the docstring is explicit no?

[skjerns]

@skjerns the docstring at https://mne.tools/stable/generated/mne.viz.plot_compare_evokeds.html says:

so maybe the API in counterintuitive but I think the docstring is explicit no?

yes, would it make sense, given the importance of the parameter, that it should be one of the first, not in between various other minor plotting parameters? By skimming over it, I assumed that it was probably some plotting flavor (e.g. combine two plots). Also I think there could be a hint in the docstring of pick to the combine parameter.

[agramfort]

let's not reorder parameters and it's a painful deprecation cycle but yes please send us a PR to put this information in docstring header and/or in pick docstring

Message ID: @.***>

[jona-sassenhagen]

You can tag me on any PR for reviews cause I think I wrote this.

[jona-sassenhagen]

Ok note that the picksdocstring starts

    %(picks_all_data)s
        * If picks is None or a (collection of) data channel types, the
          global field power will be plotted for all data channels.
          Otherwise, picks will be averaged.

[skjerns]

Ok note that the picksdocstring starts

    %(picks_all_data)s
        * If picks is None or a (collection of) data channel types, the
          global field power will be plotted for all data channels.
          Otherwise, picks will be averaged.

Which is not the current behaviour, as it plots the GFP even when specifying two channels (not types), am I understanding this correct?

Would it make sense to plot the GFP when selecting data channel types and the average when giving a list of chs? I'm not familiar with GFPs, but from the name alone it seems not so applicable when i.e. selecting two neighbouring channels from a set of 306, and in this case the average would be more appropriate?

[jona-sassenhagen]

Yes IIRC GFP should only be done if you take all the channels (of one type). With a selection averaging would be better. @drammock thoughts?

[hoechenberger]

Yes, GFP only makes sense for all channels. If we plot it for lists of channels, I would consider this a bug we should fix without a deprecation cycle.

[drammock]

I agree w/ @jona-sassenhagen and @hoechenberger, this would be a bugfix. I'll tag it for the sprint for later this month, maybe someone will get to it? But in the meantime @skjerns feel free to tackle it yourself if you have time.

[ktavabi]

On a tangent, I am thinking of simplifying the nave proportions algebra in evoked. comment for the results from plot_compare_evokdes to make a more informative legend. Here is an, e.g., output screenshot

The text in evoked.comment renders unusable image file formats unless figure legends are dealt with on the fly. If that's the intended usage, then disregard this. Otherwise, I am curious if a fix is a suitable task to piggyback here?

Resulting .png