Repository navigation
[BUG] Evoked.plot_topomap() and Evoked.plot_joint() handle the colormaps in a suboptimal manner #13050
Description
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
vlimare specified for the topomap, use thosevlimalso to set the contours (unlesscontoursare set explicitly). The current behavior is to use theylimfrom the time series plot to determine the contours unlesscontoursis set explicitly. - If
vlimare not specified for the topomap, set the contours similar to what is now done inEvoked.plot_topomap(), usingvmax = 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.
Activity
welcome commentedon Jan 8, 2025
Hello! 👋 Thanks for opening your first issue here! ❤️ We will try to get back to you soon. 🚴
larsoner commentedon Jan 8, 2025
I had seen some colorbar badness and assumed it was a matplotlib bug, it would be great if working this out fixed it!
To build this out a bit more, I think from a user perspective the most intuitive behavior would be:
vlimorcontours, MNE setsvlimusingmax(abs(...))then chooses contours within those boundsvlimbut notcontours, MNE choosescontoursto be within thevlimcontoursbut notvlim, MNE choosesvlimto encompass thecontoursandmax(abs(...))contoursandvlim, MNE uses them as-is (and if this makes the colorbar have gaps, that's okay/correct)WDYT?
drammock commentedon Jan 8, 2025
case (3) could end up looking really weird if the user's most extreme chosen
contoursare far frommax(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 commentedon Jan 8, 2025
Yeah that's my feeling in that case. And they can work around it easily with (4) if they want.
ruuskas commentedon Jan 13, 2025
Sorry for the delay, I forgot to reply after checking the comments last week.
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
vlimdepending 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 largestcontours).For the implementation of the above, I would probably use
matplotlib.ticker.MaxNLocatoras before but simply discard the first and last ticks, which are outside the specifiedvlimbounds.larsoner commentedon Jan 13, 2025
Perhaps the colorbar limits in all cases should be capped wherever the
vlimlimits areruuskas commentedon Jan 13, 2025
That could be one solution. In that case, there wouldn't be ticks at the extrema, since
vlimare usually not "nice" numbers unless specified by the user.larsoner commentedon Jan 13, 2025
I think that's okay. That's often the case for matplotlib plots so perhaps expected behavior
ruuskas commentedon Jan 13, 2025
Ok. I can implement that and see if it works as expected.
ruuskas commentedon Jan 14, 2025
Let's continue this in #13063
Fix evoked topomap colorbars, closes mne-tools#13050 (mne-tools#13063)
Fix evoked topomap colorbars, closes mne-tools#13050 (mne-tools#13063)
Merge remote-tracking branch 'upstream/main' into cola5