Evoked topomap amplitudes don't appear to match traces in Report

[hoechenberger]

Description of the problem

I'm not sure what exactly is going on here and it might not be a bug after all, but in a Report generated through MNE-BIDS-Pipeline I see things like the following for Evoked objects:

The topo color scale is somehow much bigger than the amplitude of the signal shown in the traces, hence all colors in the topomap are really faint

Steps to reproduce

I don't have a MWE yet

Link to data

No response

Expected results

Topomap value range should correspond to signal amplitudes in the traces plot

Actual results

Topomap value range is much larger

Additional information

–

[larsoner]

Top plot looks correct. Bottom plot looks like the vlim isn't set properly for some reason. Perhaps it's calculated on a longer segment (e.g. 3 or 10s) where the drift does go up to +/- 45 uV but the slider only gets created for the interval 0-1.5s or something? In that case I guess Report should be smarter about calculating the min/max vlim using only the time span of interest

[hoechenberger]

I agree, the plot shows the correct values, but the limits are somehow too wide

[larsoner]

@hoechenberger can you share the Evoked file privately with me?

If not, one possibility is that in one case the vlim is being computed before an average ref proj is added and applied for example. Another is that it's being computed before baselining is done. Another is that there is some time cropping being done somewhere (as alluded to above). If you can see which of these is likely the culprit by loading the Evoked and looking at np.abs(evoked.data).max() right on load, after .apply_proj(), after .apply_baseline((None, 0)), etc. you might be able to isolate it. And once you know which one it is, creating a MWE without sharing the data might not be too difficult for you or me.

[hoechenberger]

@larsoner I'm busy today, I'll see what I can do
Thanks for your help!

[hoechenberger]

Ah, I believe the problem is that we're taking all channels into consideration when calculating the value range, but we need to exclude the bad ones. I can try to fix it later today.

[hoechenberger]

This is the root of the issue: #12577