GeezerVison

This is important/asked for enough that I'd consider it a major feature, so docs would be a plus.

@story645, there are some doc updates here. What sort of additional documentation do you have in mind? A further extension of the docstring or an example similar to https://github.com/matplotlib/matplotlib/blob/master/examples/images_contours_and_fields/image_masked.py? If an example, do you have a preference for adding this to an existing example or creating a dedicated one?

Adding to an existing example would be great, or as a new one in the color section of the examples.

It looks like we could update this example with the new implementation. In particular, the following no longer applies:

While imshow makes it easy to visualize a 2-D matrix as an image, it doesn't easily let you add transparency to the output.

Happy for me to rewrite while keeping the generated images the same?

that'd be perfect, thanks!

@ruidazeng, what information would you like to see specifically?

@jklymak, @story645, any additional thoughts on this?

@tillahoffmann I'm happy with the docs, thanks!

I restarted the appveyor CI which looks like it had a worker fail. Given that azure passed, I don't think that this is a windows related bug.

Is there a reason to allow vectorized alpha only for images, and not just every ScalarMappable?

Is there a reason to allow vectorized alpha only for images, and not just every ScalarMappable?

Hm, yes, good point. @ImportanceOfBeingErnest, are you suggesting adding the handling of alpha arrays here?

Yes, naively I would think one could have ScalarMappable._alpha which can be a scalar or of the same shape as ScalarMappable._A. However there might be problems because alpha is usually a property of the artist, not the mixin. But if there are no problems, having every ScalarMappable being able to profit from vectorized alphas would be nice. E.g. there are many cases where you cannot use imshow so sooner or later people would ask to have it implemented for pcolor-like functions as well.

If the intention is to broaden to all ScalarMappables this should move to 3.3. I don't think we have a clear enough view and enough testing time to bring such a major change into 3.2.

Are there any possible problems with merging this as is for imshow only and think on a generalization later?

On the other hand it would be a pity to delay it if it turns out that a more general solution is not desireable. I think the real question is: Does the implementation as shown here prevent a more general solution in the future (in the sense of needing to deprecate newly introduced stuff again etc.)?

We can always tag the current approach as experimental (as we did for constrained_layout).

I believe the approach proposed by @ImportanceOfBeingErnest is certainly preferable over the implementation in this PR, but I don't think we'd have to break any interface in the future if we wanted to support vector-alpha at the level of the ScalarMappable mix-in.

I am in favor of merging this now and addressing generalizing it in 3.3. It is better to get useful, but incomplete code out rather than wait for perfect general solutions.

This does not add any public API other than allowing imshow to take a greater range of inputs.

This also connects to #8738