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.

What happens if you do set_over and set_under?

I still get the inconsistent behaviour - transparent (alpha < 1) colorbar, non-transparent (alpha = 1) triangles - with set_over/set_under:

import numpy as np
import matplotlib.pyplot as plt

img = np.random.rand(10, 10)
alpha = 0.3

cmap = plt.get_cmap('Greys').copy()
cmap.set_under('r')
cmap.set_over('b')

plt.imshow(img, alpha=alpha, cmap=cmap, vmin=0.25, vmax=0.75)
plt.colorbar(extend='both')
plt.show()

I actually think the behaviour of the Colorbar alpha matching the alpha of the image is questionable behaviour

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?

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)

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.

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.

Better in this case would be to make the colormap have an alpha

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.

Right, I guess I just think our API gets to be messy because of too many automatic hooks that then overlap in functionality.

I would like to work on this. Is anyone working on it?

@kkoutris Go for it! If there is not a linked PR it is safe to assume there is not active work going on.

@tacaswell if you have the time, can you guide me a bit on what to change to fix this issue?

@kkoutris #22970 (comment) basically says how to fix the issue.

Since I don't see a PR, @kkoutris are you still working on this or could I pick up this issue?