[BUG] Evoked.plot_topomap() and Evoked.plot_joint() handle the colormaps in a suboptimal manner

[ruuskas]

Description of the problem

This might be somewhat controversial as a bug report and is partially a matter of taste.

There is a combination of two issues, which leads to suboptimal results when producing plots with the default parameters using Evoked.plot_topomap() and Evoked.plot_joint().

Essentially, an unpredictable amount of whitespace is left above and below the colored portion of the colorbar when using Evoked.plot_topomap(). This is seen in all MNE examples using topomaps, for example, Plotting topographic maps of evoked data. The reason is that the colorbar ticks follow the contours (as they should), while the colored part is dependent on vlim (by default set symmetrically such that vmax = np.abs(data).max()). The default behavior is to set six contours using matplotlib.ticker.MaxNLocator, which adds locations beyond the minimum and maximum of the data to obtain "nice" values for the ticks. I wonder if it would be better to scale then also the colormap limits to match the smallest and largest ticks?

This issue can, of course, be circumvented by explicitly setting both vlim and contours.

Moreover, when using Evoked.plot_joint() without specifying vlim, the vlim for the topomaps are selected based on the data at the selected time points (inside plot_evoked_topomap). At the same time, the contours, and correspondingly, the colorbar ticks, are selected based on the ylim of the time series plot. In my opinion, it would be better to do the following:

• If vlim are specified for the topomap, use those vlim also to set the contours (unless contours are set explicitly). The current behavior is to use the ylim from the time series plot to determine the contours unless contours is set explicitly.
• If vlim are not specified for the topomap, set the contours similar to what is now done in Evoked.plot_topomap(), using vmax = np.abs(data).max() at the topomap timepoints.

Steps to reproduce

"""
Minimal working example based on the tutorial "Plotting topographic maps of evoked data".
"""

# %%
import numpy as np

from mne import read_evokeds
from mne.datasets import sample

path = sample.data_path()
fname = path / "MEG" / "sample" / "sample_audvis-ave.fif"

# load evoked corresponding to a specific condition
# from the fif file and subtract baseline
condition = "Left Auditory"
evoked = read_evokeds(fname, condition=condition, baseline=(None, 0))

# %%

times = np.arange(0.05, 0.151, 0.02)
evoked.plot_topomap(times, ch_type="mag")

# %%

evoked.plot_joint(picks='mag')

Link to data

No response

Expected results

I would like it to do this:

Actual results

Instead this happens:

Here's an example of what happens when suboptimal time points are picked:

Additional information

I don't know if this is a feature or a bug, but here's to open discussion. I can make a PR if this is something that you want to change.

[welcome]

Hello! 👋 Thanks for opening your first issue here! ❤️ We will try to get back to you soon. 🚴

[larsoner]

This is seen in all MNE examples using topomaps, for example

I had seen some colorbar badness and assumed it was a matplotlib bug, it would be great if working this out fixed it!

I wonder if it would be better to scale then also the colormap limits to match the smallest and largest ticks? ... In my opinion, it would be better to do the following:

To build this out a bit more, I think from a user perspective the most intuitive behavior would be:

1. If you don't pass vlim or contours, MNE sets vlim using max(abs(...)) then chooses contours within those bounds
2. If you pass vlim but not contours, MNE chooses contours to be within the vlim
3. If you pass contours but not vlim, MNE chooses vlim to encompass the contours and max(abs(...))
4. If you pass both contours and vlim, MNE uses them as-is (and if this makes the colorbar have gaps, that's okay/correct)

WDYT?

[drammock]

1. If you don't pass vlim or contours, MNE sets vlim using max(abs(...)) then chooses contours within those bounds

2. If you pass vlim but not contours, MNE chooses contours to be within the vlim

3. If you pass contours but not vlim, MNE chooses vlim to encompass the contours and max(abs(...))

4. If you pass both contours and vlim, MNE uses them as-is (and if this makes the colorbar have gaps, that's okay/correct)

case (3) could end up looking really weird if the user's most extreme chosen contours are far from max(abs(data)). If most extreme contours << max(abs(data)) you end up with a colorbar with all ticks clustered at the middle of the color range, or (if most extreme contours >> max(abs(data)) you get a nice looking colorbar + ticks but the topoplot itself only shows values near the center of the color range (AKA whiteish). But arguably either one of those outcomes is the user's fault for choosing contour values poorly so I guess I'm OK with it.

[larsoner]

But arguably either one of those outcomes is the user's fault for choosing contour values poorly so I guess I'm OK with it.

Yeah that's my feeling in that case. And they can work around it easily with (4) if they want.