Skip to content

[Bug]: Change in ListedColormap behavior in 3.10.0 #29504

Closed

Description

@jsolbrig

Bug summary

While running integration tests on a package that I maintain I'm seeing a change in the behavior of ListedColormap in 3.10.0. This appears to be a regression and is causing significant changes in some of the imagery that my tests produce.

The tests are baked into a larger system and would be difficult for matplotlib maintainers to replicate, so I wrote up a dummy script that, I think, shows the problem. I'm not sure if it is capturing the full problem or not but it's at least capturing part of it.

Code for reproduction

import numpy as np
from matplotlib import pyplot as plt
from matplotlib.colors import ListedColormap
from matplotlib import __version__ as mpl_vers


cld_type_colors = [
    "ghostwhite",
    "slategray",
    "blue",
    "royalblue",
    "cyan",
    "limegreen",
    "green",
    "yellow",
    "gold",
    "lightsalmon",
    "coral",
    "red",
    "maroon",
    "black",
]


rainbow_colors = [
    (255, 0, 0),     # Red
    (255, 64, 0),    # Reddish-Orange
    (255, 128, 0),   # Orange
    (255, 192, 0),   # Yellowish-Orange
    (255, 255, 0),   # Yellow
    (192, 255, 0),   # Yellowish-Green
    (128, 255, 0),   # Greenish-Yellow
    (0, 255, 0),     # Green
    (0, 255, 128),   # Greenish-Cyan
    (0, 255, 192),   # Cyan
    (0, 255, 255),   # Bright Cyan
    (0, 192, 255),   # Bluish-Cyan
    (0, 128, 255),   # Blue
    (0, 64, 255),    # Blueish-Purple
    (64, 0, 255),    # Purple
    (128, 0, 255),   # Violet
]
rainbow_colors = [(r / 255, g / 255, b / 255) for r, g, b in rainbow_colors]

cld_type_cmap = ListedColormap(cld_type_colors, name="cld_type_cmap")
rainbow_cmap = ListedColormap(rainbow_colors, name="rainbow_cmap")

# Create 1600x1600 array constant values in the vertial and float values ranging from
# 0-15 in the horizontal
size = 1600
num_values = 16
h_vals = np.linspace(0, num_values - 1, size)
flt_array = np.tile(h_vals, (size, 1))

# Plot float values using the cloud type colormap
fig, ax = plt.subplots(figsize=(10, 10))
ax.set_title("Float - Cloud Type Color Map - MPL Version: " + mpl_vers)
ax.imshow(flt_array, cmap=cld_type_cmap)
fig.savefig(f"float_cloud_type_{mpl_vers.replace('.', '')}.png")

# Plot float values using the rainbow colormap
fig, ax = plt.subplots(figsize=(10, 10))
ax.set_title("float - Rainbow Color Map - MPL Version: " + mpl_vers)
ax.imshow(flt_array, cmap=rainbow_cmap)
fig.savefig(f"float_rainbow_{mpl_vers.replace('.', '')}.png")

# Create a 1600x1600 array constant values in the vertial and integer values ranging
# from 0-15 in the horizontal
h_vals = np.arange(0, 16)
h_vals = np.repeat(h_vals, size // len(h_vals))
int_array = np.tile(h_vals, (size, 1))

# Plot integer values using the cloud type colormap
fig, ax = plt.subplots(figsize=(10, 10))
ax.set_title("Integer - Cloud Type Color Map - MPL Version: " + mpl_vers)
ax.imshow(int_array, cmap=cld_type_cmap)
fig.savefig(f"int_cloud_type_{mpl_vers.replace('.', '')}.png")

# Plot integer values using the rainbow colormap
fig, ax = plt.subplots(figsize=(10, 10))
ax.set_title("Integer - Rainbow Color Map - MPL Version: " + mpl_vers)
ax.imshow(int_array, cmap=rainbow_cmap)
fig.savefig(f"int_rainbow_{mpl_vers.replace('.', '')}.png")

Actual outcome

With v3.10.0 I get the following images. If you zoom in on the borders between color bands, you will see some lines of different color.

Image

Image

Image

Image

Zoomed in:

Image

Image

Image

Image

Expected outcome

With v3.9.4 I get the following output. If you zoom in on the borders between the color bands, there is a sharp transition between bands with no extra colors.

Image

Image

Image

Image

Zoomed in:

Image

Image

Image

Image

Additional information

Just for additional context, below are the really ugly images produced by our integration tests. The changes in how the colormaps are applied appear to be the cause of some of the differences here, though I don't think they actually address everything.

3.10.0

Image

3.9.4

Image

Operating system

Rocky

Matplotlib Version

3.10.0

Matplotlib Backend

agg

Python version

3.10.16

Jupyter version

No response

Installation

pip

Activity

  1. tacaswell commented on Jan 22, 2025

    @tacaswell
    Member

    This is likely due to #28061 which moved the default interpolation stage from data space to rgba space when we are aggressively down sampling.

    There is an API change note in that PR that I can not find it in the rendered docs (I need to look into that), but setting the mpl.rcParams['image.interpolation_stage'] = 'data' should restore the previous behavior.

  2. tacaswell commented on Jan 22, 2025

    @tacaswell
    Member

    also, thank you for the very detailed bug report 🎉 !

  3. biosafetylvl5 commented on Jan 22, 2025

    @biosafetylvl5

    Wow! Thank you for such a fast response - I'm going to set mpl.rcParams['image.interpolation_stage'] = 'data' and see if that changes our outputs. 🙂

  4. biosafetylvl5 commented on Jan 22, 2025

    @biosafetylvl5

    That's definitely improving our outputs! @jsolbrig will likely chime in soon with more detail on the specifics.

  5. jsolbrig commented on Jan 22, 2025

    @jsolbrig
    Author

    Thank you! As I suspected, this fixes part of our problem. The differences shown in the striped images above disappear and the image-diff from our integration tests improves. Most of our integration tests are completely fixed, but this one still has some lingering issues but I think I'll submit a different issue when I track it down.

    For reference, the image-diff prior to changing this setting is shown in the first image below where red indicates some amount of change. The second image shows the image diff after changing this setting. I have a suspicion that the remaining issues have something to do with BoundaryNorm but need to investigate further.

    Image

    Image

    The last two images show a diff that uses a threshold to look for more substantial changes. The first is without the new setting and the second is with the new setting.

    Image

    Image

  6. timhoffm commented on Dec 13, 2025

    @timhoffm
    Member

    Reason / solution see #29504 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions