Repository navigation
[Bug]: Colorbar extend patches do not have correct alpha #22970
Description
Bug summary
When a colorbar has extend != 'neither', the triangles at the end of the colorbar always have alpha=1, even when the rest of the colorbar has a different alpha value.
Code for reproduction
#!/usr/bin/env python3
# -*- coding: utf-8 -*-
import numpy as np
import matplotlib.pyplot as plt
img = np.random.rand(5, 10)
alpha = 0.5
plt.subplot(1, 2, 1)
plt.imshow(img, alpha=alpha, cmap='RdBu')
plt.colorbar(extend='both', orientation='horizontal', label='Current behaviour')
# Temporary fix to manually set the alpha of the extend patches
# doesn't look perfect, but is an improvement over the current behaviour
plt.subplot(1, 2, 2)
plt.imshow(img, alpha=alpha, cmap='RdBu')
cb = plt.colorbar(extend='both', orientation='horizontal', label='Temporary fix')
for patch in cb._extend_patches:
patch.set_alpha(alpha)
plt.show()Actual outcome
Expected outcome
The triangles at the end of the colorbar should have the same alpha as the colorbar (i.e. roughly like the temporary fix above)
Additional information
No response
Operating system
OS/X
Matplotlib Version
3.5.2
Matplotlib Backend
module://matplotlib_inline.backend_inline
Python version
Python 3.10.4
Jupyter version
No response
Installation
conda
Activity
jklymak commented on May 4, 2022
What happens if you do set_over and set_under? I actually think the behaviour of the Colorbar alpha matching the alpha of the image is questionable behaviour.
ortk95 commented on May 4, 2022
I still get the inconsistent behaviour - transparent (alpha < 1) colorbar, non-transparent (alpha = 1) triangles - with set_over/set_under:
I think there are cases where each behaviour can be desirable, e.g. in the image above, the greys would probably be more difficult to understand if the colorbar wasn't transparent. Maybe there should be option when creating the colorbar to specify if it takes the image's alpha or just has alpha = 1?
ortk95 commented on May 4, 2022
I've just tested this with an older conda environment and the colorbar and triangles have consistent alpha with matplotlib 3.4.3, so this appears to be an issue introduced in a recent update
Figure generated using code in #22970 (comment) using matplotlib 3.4.3 (rather than 3.5.2)
greglucas commented on May 4, 2022
You can specify an RGBA fill in the over:
cmap.set_over((1, 0, 0, 0.2))
which does show a light fill, but I tend to agree that the old way was more consistent with what someone would expect. I think this is probably due to the previous versions drawing the extends as part of the primary mesh, while now it is a separate patch.
I think the fix here is to add self.alpha into the PathPatch creation of the extends.
matplotlib/lib/matplotlib/colorbar.py
Lines 729 to 735 in f8cd2c9
jklymak commented on May 4, 2022
Yes, we definitely changed how the extents are handled.
OTOH someone, at some point, went in and put plumbing in to change the Colorbar alpha to match the mappable alpha. I guess that's OK-ish if the the mappable has one alpha, but becomes meaningless if the mappable has multiple alphas (as an image can). Better in this case would be to make the colormap have an alpha. I'm not convinced that the original feature was that great.
greglucas commented on May 4, 2022
I agree. The colormap does already have an alpha, but it can be out of sync with the image here since the image/mappable has a different alpha. Sorting out how to get the colormap and image to keep their alpha's in-sync may be a bit of a bigger refactor though. I think the fix I put above is a minimal update to get this working again.
jklymak commented on May 4, 2022
Right, I guess I just think our API gets to be messy because of too many automatic hooks that then overlap in functionality.
kkoutris commented on May 10, 2022
I would like to work on this. Is anyone working on it?
tacaswell commented on May 10, 2022
@kkoutris Go for it! If there is not a linked PR it is safe to assume there is not active work going on.
kkoutris commented on May 10, 2022
@tacaswell if you have the time, can you guide me a bit on what to change to fix this issue?
jklymak commented on May 10, 2022
@kkoutris #22970 (comment) basically says how to fix the issue.
Wikignometry commented on May 26, 2022
Since I don't see a PR, @kkoutris are you still working on this or could I pick up this issue?