Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Supporting different alphas for face and edge colours #1954

Merged
merged 8 commits into from

4 participants

@Westacular

This is a set of changes that solve the issues raised by #1899 and #1938.

Linestyles

Ignore what I said before in #1899 about linestyles.

Turns out it was working correctly for patches, but the dashes and dots were all overlapping at linewidth=5. The culprit is a single line in Patch.draw() that was setting the gc to use 'projecting' capstyle. This capstyle causes the rendered length of dashes and dots to increase in proportion to the width, however, the spacing between them (which ignores the caps) remains constant. At linewidth=5 the spaces are completely covered by the caps, making it look like linestyle='solid'.

Letting capstyle='butt', the default, fixes this.

(Also, there was a bug in the PGF backend that was causing Collections (or anything with a custom dash pattern) to always use a solid linestyle. Fixed that.)

Also, for some reason, in the SVG header stroke-linecap:square(the translation of capstyle='projecting') was being set as the default, even though the default for most objects is butt. This was causing a problem with the rendering of the PathCollection, because (at least on WebKit) the style for the collection, which did specify butt, was not overriding that default. The net effect was the same as the above problem for patches.

Mixed Edge and Face Alpha Values

There was already stubs of logic (and a _forced_alpha attribute of GraphicsContext) for the notion that if an explicit alpha is set (through gc.set_alpha()) it should override any face and edge alphas, but otherwise, leave them be; however, it was largely ignored by most backends, each of which tended to do its own slightly different thing with regard which it recognized and how it handled them.

I've updated (and tested to varying degrees) the AGG, PDF, SVG, PGF, Mac OS X, and Cairo backends, along with various fixes to the backend bases and to the Patch class. As far as I can tell, that covers everything that's already paying attention to the gc.get_alpha() value.

I also fixed the bug (also discussed at #1938) where setting an alpha value on the patch would override edgecolor='none'. The new behaviour is that the value given to alpha is ignored by the edge colour if and only if edgecolor='none' exactly; edgecolor=(x,x,x,0) still gets overridden by alpha. This is the existing behaviour for facecolor, which I've not changed.

I've included the test (and changes) added by @pelson in #1899, along with correct results, and corrected the results of the clip_to_bbox test (which were previously affected by the alpha=x/edgecolor='none' bug). I've also added another test to check that the alpha attribute is overriding the alpha components of the face and edge colors.

@pelson
Collaborator

The test results are looking good - there is a lot of change here which needs to be considered, but I'd like to target this for v1.3.

Amazing work @Westacular.

@Westacular

Thanks.

Just noticed the Travis build had failed. I didn't have inkscape installed, so I didn't notice there was a regression with SVG in my own testing. I've since fixed the problem (hatches were not having their alpha applied in SVGs).

@pelson
Collaborator

I didn't have inkscape installed, so I didn't notice there was a regression with SVG in my own testing. I've since fixed the problem (hatches were not having their alpha applied in SVGs).

Wooho! Travis caught a genuine problem! :smile:

@mdboom
Owner

@Westacular: Would you mind rebasing this on current master so that this will merge cleanly and the tests will run again?

pelson and others added some commits
@pelson pelson Failing tests. ae5c2f1
@Westacular Westacular Fixes bug where linestyle always appears solid if linewidth is large …
…enough
1e7399f
@Westacular Westacular Fixes bug where if alpha is set and edgecolor='none', edges would sti…
…ll be rendered as black.

Also fixes test case result that hit this bug
1aefc52
@Westacular Westacular Changes backends to support of independent face and edge alphas
Specifically, alters the base, AGG, PDF, PGF, SVG, Cairo, and Mac OS X
backends to better enable the use of RGBA color values for both fills
and edges. An explicit alpha attribute, if set, will override the
alpha channels of the color values.

Updates test results, which are now what would be expected.

Also fixes a couple bugs with handling of linestyles.
6cc8aaa
@Westacular Westacular Add additional patch tests. a7f7cc7
@Westacular

@Westacular: Would you mind rebasing this on current master so that this will merge cleanly and the tests will run again?

Done. (Also squashed some of the commits, where it made sense.)

@mdboom mdboom commented on the diff
lib/matplotlib/backends/backend_svg.py
@@ -289,7 +289,7 @@ def _write_default_style(self):
writer = self.writer
default_style = generate_css({
u'stroke-linejoin': u'round',
- u'stroke-linecap': u'square'})
+ u'stroke-linecap': u'butt'})
@mdboom Owner
mdboom added a note

Good catch -- indeed the "default" according to the SVG spec is butt.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@mdboom
Owner

Thanks for all of this work. It looks great. I think it's significant enough that it should have an entry in what's new -- and perhaps in API changes, if there's a way of summarizing changes in behavior between old and new (even though old was obviously broken)...

@pelson
Collaborator

and perhaps in API changes

Definately.

@pelson pelson commented on the diff
lib/matplotlib/backend_bases.py
((20 lines not shown))
self._rgb = fg
else:
self._rgb = colors.colorConverter.to_rgba(fg)
- if len(self._rgb) == 4 and not self._forced_alpha:
- self.set_alpha(self._rgb[3])
@pelson Collaborator
pelson added a note

This is subtle, but I think it will break the non forced alpha case.

@pelson Collaborator
pelson added a note

Question: Should calling set_alpha turn on the forced_alpha value?

set_alpha does turn on _force_alpha -- in fact, it already did, I didn't need to change anything there. (But prior these changes, practically nothing actually paid attention to it.) Calling gc.set_alpha(None) clears _forced_alpha.

This doesn't break the non-forced alpha case because the backends themselves, where appropriate, now pull the alpha value straight out of _rgb[3] in the non forced alpha case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@pelson pelson commented on the diff
lib/matplotlib/backends/backend_cairo.py
((10 lines not shown))
ctx.set_source_rgba (fill_c[0], fill_c[1], fill_c[2], alpha)
else:
- ctx.set_source_rgba (fill_c[0], fill_c[1], fill_c[2], alpha*fill_c[3])
@pelson Collaborator
pelson added a note

Ouch. We don't have cairo tests to check this either (we need to think about testing the cairo backend more). Nice spot.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@pelson pelson commented on the diff
lib/matplotlib/backends/backend_pdf.py
@@ -1443,11 +1443,21 @@ def check_gc(self, gc, fillcolor=None):
orig_fill = gc._fillcolor
gc._fillcolor = fillcolor
+ orig_alphas = gc._effective_alphas
+
+ if gc._forced_alpha:
+ gc._effective_alphas = (gc._alpha, gc._alpha)
+ elif fillcolor is None or len(fillcolor) < 4:
+ gc._effective_alphas = (gc._rgb[3], 1.0)
+ else:
+ gc._effective_alphas = (gc._rgb[3], fillcolor[3])
@pelson Collaborator
pelson added a note

Your effective alphas approach here is, IMHO, something that could be done in the GC object. The GC could then just draw an RGBA of fill and an RGBA of line color and the backend wouldn't need to know anything about _forced_alpha.

Do you know of a reason why that wouldn't be a viable approach?

@pelson Collaborator
pelson added a note

I guess what I'm suggesting is that we updated the necessary signatures (to draw_path for example) such that we pass through an RGBA rather than an RGB and expect the backend to figure out the final face RGBA color.

That actually is how draw_path is working, now, but I couldn't (or rather, didn't) guarantee that everything else worked that way.

The issue is there are instances where the GC is applying an alpha property to things that have neither fill or draw colours -- e.g., images -- which is done by setting an alpha on the backend's underlying context. (The Mac OS X backend comes to mind as an example.) Supporting that means:

  • The GC still needs to make use of its _alpha in some situations
  • We don't want this to stack on top of the RGBA specified in the colors
  • So we ought to guard against that.

I believe for draw_path itself, this isn't needed because the other changes I've made mean that gc.set_alpha isn't called for that -- the alphas (overridden or not) go directly in the edge and fill colours. But there are many other draw methods that I haven't vetted that could possibly call gc.set_alpha() and give it colours with alpha channel values and I was concerned about them clashing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@Westacular

Thanks for all of this work. It looks great. I think it's significant enough that it should have an entry in what's new -- and perhaps in API changes, if there's a way of summarizing changes in behavior between old and new (even though old was obviously broken)...

Happy to help. I took a crack a explaining the high-level/user-facing changes, while omitting the finer details of other bugs that were fixed or how backends were changed. Let me know what you think.

doc/api/api_changes.rst
@@ -43,6 +43,21 @@ Changes in 1.3.x
* The :func:`~matplotlib.cbook.check_output` function has been moved to
`~matplotlib.compat.subprocess`.
+* :class:`~matplotlib.patches.Patch` now fully supports using RGBA values for
+ its ``facecolor`` and ``edgecolor`` attributes, which enables faces and
+ edges to have different alpha values. If the
+ :class:`~matplotlib.patches.Patch` object's ``alpha`` attribute is set to
+ anything other than ``None``, that value will override any alpha-channel
+ value in both the face and edge colors. Previously, if
+ :class:`~matplotlib.patches.Patch` had ``alpha=None``, the alpha component
+ of ``edgecolor`` would be applied to both the edge and face.
+
+* For :class:`~matplotlib.patches.Patch`, the ``capstyle`` used is now
@pelson Collaborator
pelson added a note

This is SVG only, right?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@pelson pelson commented on the diff
doc/users/whats_new.rst
@@ -154,6 +154,16 @@ Wes Campaigne and Phil Elson fixed the Agg backend such that PNGs are now
saved with the correct background color when :meth:`fig.patch.get_alpha` is
not 1.
+Independent alpha values for face and edge colors
+-------------------------------------------------
+Wes Campaigne modified how :class:`~matplotlib.patches.Patch` objects are
+drawn such that (for backends supporting transparency) you can set different
+alpha values for faces and edges, by specifying their colors in RGBA format.
+Note that if you set the alpha attribute for the patch object (e.g. using
+:meth:`~matplotlib.patches.Patch.set_alpha` or the ``alpha`` keyword
+argument), that value will override the alpha components set in both the
+face and edge colors.
@pelson Collaborator
pelson added a note

Nicely put. And sounds like sensible behaviour too. - that is a good sign :wink:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@pelson
Collaborator

I see this as the "open heart surgery" of v1.3 (@mdboom's terminology used for a PR of mine on transforms in v1.2). I think on the whole the behaviour is more consistent, expected and desirable as a result of this PR, and it is for that reason (and the thoroughness of @Westacular's work) that I'd be comfortable merging this.

:+1: - awesome work @Westacular!

@mdboom
Owner

Agreed! Awesome work!

I know this issue has been brought up by @efiring a number of times over the years, so I thought I'd give him the opportunity to comment before merging, just in case there's anything additional.

@efiring
Owner

I'm happy to see this.

There is one change in the formally public API that could be mentioned in API_CHANGES: in GraphicsContext*.set_foreground, the isRGB kwarg is now isRGBA. I think the change is fine, and it is unlikely that user code is calling this low-level method directly, so I don't think a deprecation process is needed.

@Westacular

Ok, I've added a note about the isRGBA change.

Thanks for the kind words... And thanks for trusting me with the scalpel. :)

@efiring efiring merged commit 60e67e0 into matplotlib:master

1 check passed

Details default The Travis CI build passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Commits on May 3, 2013
  1. @pelson @Westacular

    Failing tests.

    pelson authored Westacular committed
  2. @Westacular
  3. @Westacular

    Fixes bug where if alpha is set and edgecolor='none', edges would sti…

    Westacular authored
    …ll be rendered as black.
    
    Also fixes test case result that hit this bug
  4. @Westacular

    Changes backends to support of independent face and edge alphas

    Westacular authored
    Specifically, alters the base, AGG, PDF, PGF, SVG, Cairo, and Mac OS X
    backends to better enable the use of RGBA color values for both fills
    and edges. An explicit alpha attribute, if set, will override the
    alpha channels of the color values.
    
    Updates test results, which are now what would be expected.
    
    Also fixes a couple bugs with handling of linestyles.
  5. @Westacular
Commits on May 4, 2013
  1. @Westacular
  2. @Westacular
Commits on May 8, 2013
  1. @Westacular
Something went wrong with that request. Please try again.