Internally dropping use of separate alpha value

[anntzer]

Having a separate alpha attribute to artists is problematic, mostly because colors can carry their own alpha values, and we then have priority issues (e.g. #7375). I think a much better approach would be to internally only store colors with alpha values, and let set_alpha and friends directly change this alpha value.

[tacaswell]

It may have to be handled on an artist-by-artist case. For AxesImage it is very nice to have an artist level alpha independent of the alpha in the color map.

[anntzer]

Could the alpha value not simply be overwritten to (a copy of) the colormap?

[tacaswell]

But you would like to persist the alpha value if you change the color map.

[anntzer]

Good point.

[anntzer]

Perhaps a reasonable compromise would be to maintain a separate alpha channel only for ScalarMappables (which don't really have an internal notion of own color).

[tacaswell]

Probably collections as well still need to carry their own alpha (which maybe should be applied on top of any individual color alpha?) as well.

[stippingerm]

This is an interesting implementation question. The good user experience with graphics software tells me that instead of prioritizing one or another alpha value, one should use their combination as follows:

• a global, collection_level_alpha value < 1 is a request for the collection being transparent to a certain level
• in addition, individual RGBA values with A<1 indicate the some elements of the collection shall be made more transparent (than the most solid color allowed by collection_level_alpha)

In summary, I suggest to take the product of collection_level_alpha and A from RGBA when displaying. I wrote about that in a different context and that's what happens in Inkscape/Gimp when you set a transparency value on a layer that already contains RGBA colors.

[github-actions]

This issue has been marked "inactive" because it has been 365 days since the last comment. If this issue is still present in recent Matplotlib releases, or the feature request is still wanted, please leave a comment and this label will be removed. If there are no updates in another 30 days, this issue will be automatically closed, but you are free to re-open or create a new issue if needed. We value issue reports, and this procedure is meant to help us resurface and prioritize issues that have not been addressed yet, not make them disappear. Thanks for your help!

[anntzer]

I guess this would still be conceptually nice, but I don't really have the bandwidth to push this forward, so we may close this if no one else is interested.

[timhoffm]

The reasonable way forward would be using an internal Color class (and additionally ColorArray). This can abstract away all color handling aspects. - For example also the topic of (non-)normalization (what color representation do we return - the one that was provided or some standard (rgb(a)).

However this is not a priority. While not quite well structured, colors work reasonably well in practice.

[QuLogic]

@ksunden has added typing for, at least, the input of colours. While that does not specifically limit what gets used internally, it may inform the design of things here a bit.

[github-actions]

This issue has been marked "inactive" because it has been 365 days since the last comment. If this issue is still present in recent Matplotlib releases, or the feature request is still wanted, please leave a comment and this label will be removed. If there are no updates in another 30 days, this issue will be automatically closed, but you are free to re-open or create a new issue if needed. We value issue reports, and this procedure is meant to help us resurface and prioritize issues that have not been addressed yet, not make them disappear. Thanks for your help!