PDF backend can now do alpha on hatches. #17049
Conversation
|
If the .png changed too (and is intended!), then that needs a what's new as well. |
|
The .png was already behaving as intended (see #16883). I'll update the PR soon with a fix of all the images that got affected. As I can tell at a glance, they're the ones involving PDF edge opacity, which apparently wasn't being handled properly (but perhaps I overlooked something). |
|
Tests should now pass. Fixed a bug with
Before And finally a PNG |
|
Thanks for this, it is really good work! I am nominally 👍 on it going in, but would like to give @jkseppan a chance to weigh in (as the primary author of the pdf backend). I am not sure that I understand why you added the extra box to the clipping though. |
|
Why I added a backdrop rectangle to the clipping test? I first did it debug-wise to be sure there was alpha on the fill. Then thought it was also good for the clipping test itself, to check that it really is a clip, not a white overlay, so I let it stay. But I have no strong feeling either way; shall I remove it? I still have to fix some linting, and apparently the Travis build is failing on macOS at the The Windows Azure builds are also failing, because of Finally, what is your policy on squashing these final small-fix commits? |
|
The macOS failure is a known issue. Squashing is up to the contributor, though it's preferred if you've changed test images multiple times. |
|
Good to know about the Mac failures. As to the Windows failures, I don't suppose there's a way of pulling the failing images out of the CI VM. I don't work on WIndows... |
More consistent behavior for edge/fill/hatch alpha vs. entire patch alpha, for both PDF and SVG. PathCollections now respect whole object alpha.
|
|
||
| The SVG and PDF backends now respect the hatch stroke alpha. Useful applications | ||
| are, among others, semi-transparent hatches as a subtle way to differentiate | ||
| columns in bar plots. |
There was a problem hiding this comment.
This could be a nice demo in the gallery, or perhaps another subplot in https://matplotlib.org/3.2.0/gallery/lines_bars_and_markers/filled_step.html
There was a problem hiding this comment.
Cool idea. As a side note, because hatch color/alpha is linked to the Patch's edge's, a simple plot with hatch alpha will usually not look so good because the translucent edge will half-overlap with the fill. One can plot edge-less with lw=0, but to have an opaque outline one must replot a full opacity, edge-only plot on top of the first.
It's a bit hackish. An independent hatch style API (#7059) would go a long way to simplifying this.
|
Ok, I'll be splitting the collection alpha into a separate PR, and try to add/update a gallery example as suggested. |
|
Is this waiting for the separate PR, or vice versa? I wonder if #10035 is a similar sort of bug for markers, as the Patch edgecolor handling. |
|
Both; this should not be merged just yet. I haven't had the time to spin-off a collections-targeted PR. As to #10035, this might very well be connected. I'll take a look. After a quick read it seems SVG supports 'knock-out' or is going to support it (not sure about the stability of that). This would further homogeneize SVG and PDF behavior. A discussion then would be on what is the intended way of displaying non-opaque edges over their fills (I vote for the cleaner-looking knockout compositing). |
|
When this is continued, maybe this issue can be considered as well? #12367 (Seems like it is most likely fixed by this PR.) |
|
Since this Pull Request has not been updated in 60 days, it has been marked "inactive." This does not mean that it will be closed, though it may be moved to a "Draft" state. This helps maintainers prioritize their reviewing efforts. You can pick the PR back up anytime - please ping us if you need a review or guidance to move the PR forward! If you do not plan on continuing the work, please let us know so that we can either find someone to take the PR over, or close it. |
PR Summary
Studied a bit of .PDF and I got this working. Turns out the transparency graphics states (
ExtGState) weren't being taught to the hatch pattern writing routine.This completes the fix of hatch alpha on SVG and PDF (#16883).
Furthermore, I noticed, after the previous PR (#16890), that there was a bit of mixed behavior between 2 cases: 1. when a Patch edgecolor (and therefore its hatch_color) has alpha; or 2. when the entire Patch has alpha. Case 1 is what I had tried to fix in #16890; however, the test I was relying on was of case 2.
Case 2 is more logically and elegantly rendered by doing edge+hatch full opacity and then within an object with alpha. Digging a bit deeper I found I could implement this case 2 behavior by extending the
forced_alphaconcept to the SVG and PDF renderers: if the parent Patch or Collection has a global alpha, ignore the ones of the elements.I updated two
test_artist.pytests to better cover these cases (no added baselines images). The following images showcase the results of the SVG and PDFhatchingtest, after conversion to PNG. The rightmost, orange-tinted shapes are the ones where alpha was set; on the top diamond only on the edgecolor, on the bottom one on the entireRectangle:SVG
Notice in the top-right shapes how the edge and face/hatch overlap. This no longer occurs if the alpha is set on the entire object (but then the fill is also affected).
PDF
Notice again in the top-right shape that PDF is cleaner in handling the edge overlap with the face and hatch of the same Patch. It's rendered as a group that is internally opaque (the edge completely occludes the fill and hatch) but still transparent at the edges (I guess this is called a knockout group? I didn't add anything specific to this end). I'm not sure SVG could allow for this but would be cool/cleaner if it did.
Feedback appreciated.
PR Checklist