Repository navigation
Internally dropping use of separate alpha value #7430
Description
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.
Activity
tacaswell commentedon Nov 9, 2016
It may have to be handled on an artist-by-artist case. For
AxesImageit is very nice to have an artist level alpha independent of the alpha in the color map.anntzer commentedon Nov 9, 2016
Could the alpha value not simply be overwritten to (a copy of) the colormap?
tacaswell commentedon Nov 9, 2016
But you would like to persist the alpha value if you change the color map.
anntzer commentedon Nov 10, 2016
Good point.
anntzer commentedon Nov 21, 2016
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 commentedon Dec 20, 2016
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 commentedon Jan 8, 2019
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:
collection_level_alphavalue < 1 is a request for the collection being transparent to a certain levelcollection_level_alpha)In summary, I suggest to take the product of
collection_level_alphaand 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 commentedon Apr 2, 2023
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 commentedon Apr 2, 2023
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 commentedon Apr 2, 2023
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 commentedon Apr 6, 2023
@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 commentedon Apr 8, 2024
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!