You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Feature request: allow a default line alpha to be set in mpl.rcParams #5461
Currently, one can set default line properties like color, marker style, line width, etc. with mpl.rcParams. However, the ability to set a default line alpha seems to be missing. It would be great to have 'lines.alpha' as a key in the rcParams dict, similar to 'lines.color', 'lines.marker', etc.
changed the title [-]Feature request: allow a default alpha to be set in mpl.rcParams[/-][+]Feature request: allow a default line alpha to be set in mpl.rcParams[/+]on Nov 11, 2015
@mdboom, the hex colorspec does not support the optional alpha channel. It
is an open feature request to add such support. If the support is there
deep in the colors.py code and I did not see it, then the validator needs
to be updated.
Ok -- sorry for creating confusion. If it isn't supported, I think it should be. I think separating color from alpha has been a long term mistake. To the extent that we're cleaning up color usage and specification, I think we should encourage more use of RGBA.
This issue also makes #6196 (Qt editor drops alpha) difficult to solve. I am willing to tackle this but would also like to take advantage of this to deprecate some old stuff (because there's going to be some API breakage anyways).
I think the public color conversion API should be something like:
is_color_like (any -> bool),
to_hex (3-tuple -> #rrggbb, 4-tuple or other color-like -> #rrggbbaa),
to_rgba (any -> 4-tuple),
to_rgba_array
(module-level functions)
and drop out rgb2hex, hex2color (both are confusing in the presence of alpha) and the whole colorConverter class (by the way I haven't managed to make the "Cn" syntax work but it looks like caching on that class would lead to issues if someone changes the rcParams in between?).
Activity
[-]Feature request: allow a default alpha to be set in mpl.rcParams[/-][+]Feature request: allow a default line alpha to be set in mpl.rcParams[/+]mdboom commentedon Nov 11, 2015
You can choose a color that includes alpha, i.e. #ffffff88.
evandhall commentedon Nov 11, 2015
Thanks, I also see this is a duplicate of issue #5132.
WeatherGod commentedon Nov 11, 2015
@mdboom, the hex colorspec does not support the optional alpha channel. It
is an open feature request to add such support. If the support is there
deep in the colors.py code and I did not see it, then the validator needs
to be updated.
On Wed, Nov 11, 2015 at 8:57 AM, evandhall [email protected] wrote:
mdboom commentedon Nov 11, 2015
Ok -- sorry for creating confusion. If it isn't supported, I think it should be. I think separating color from alpha has been a long term mistake. To the extent that we're cleaning up color usage and specification, I think we should encourage more use of RGBA.
anntzer commentedon May 5, 2016
This issue also makes #6196 (Qt editor drops alpha) difficult to solve. I am willing to tackle this but would also like to take advantage of this to deprecate some old stuff (because there's going to be some API breakage anyways).
I think the public color conversion API should be something like:
is_color_like(any -> bool),to_hex(3-tuple -> #rrggbb, 4-tuple or other color-like -> #rrggbbaa),to_rgba(any -> 4-tuple),to_rgba_array(module-level functions)
and drop out
rgb2hex,hex2color(both are confusing in the presence of alpha) and the whole colorConverter class (by the way I haven't managed to make the "Cn" syntax work but it looks like caching on that class would lead to issues if someone changes the rcParams in between?).tacaswell commentedon May 6, 2016
It is not obvious to me that this requires breaking any API or removing any functionality.
We need to keep the rgb only version around because some backends (ps) do not support alpha.
anntzer commentedon May 19, 2016
I think this and #5132 should be closed by #6382.
WeatherGod commentedon May 19, 2016
closed via #6382