[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.

[ruuskas]

Sorry for the delay, I forgot to reply after checking the comments last week.

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?

This sounds good to me. The only possible problem I see here is that in case (1), it is possible that the contours with the largest absolute values might be quite a bit smaller than vlim depending on the data. This would mean that the colorbar would not show the actual extent of the data (since it is capped at the smallest and largest contours).

For the implementation of the above, I would probably use matplotlib.ticker.MaxNLocator as before but simply discard the first and last ticks, which are outside the specified vlim bounds.

[larsoner]

This would mean that the colorbar would not show the actual extent of the data (since it is capped at the smallest and largest contours).

Perhaps the colorbar limits in all cases should be capped wherever the vlim limits are

[ruuskas]

This would mean that the colorbar would not show the actual extent of the data (since it is capped at the smallest and largest contours).

Perhaps the colorbar limits in all cases should be capped wherever the vlim limits are

That could be one solution. In that case, there wouldn't be ticks at the extrema, since vlim are usually not "nice" numbers unless specified by the user.

[larsoner]

I think that's okay. That's often the case for matplotlib plots so perhaps expected behavior

[ruuskas]

Ok. I can implement that and see if it works as expected.

[ruuskas]

Let's continue this in #13063