Add blend modes and blend groups for compositing - #31162
Conversation
dee65fa to
37b0b9c
Compare
|
This looks interesting. Thanks for working on it. Since I’m not into the topic I can dare to ask the stupid questions:
|
Yup, that is correct: the history of how that "background" was constructed has no bearing on how the next Artist is blended in using its specific blend mode. It's also important to remember that that the "empty" background of an Axes is solid white, and thus not actually empty as far as these blend modes are concerned. For example, using "screen" to blend in an image on a truly empty background will just return the image, but on a white background will return solid white, which can make it look instead like the image call failed. That's why I turn off the face colors in my example above. What I still need to investigate is how my changes interact with collections of Artists. A user may want "over" blending (the default) within the collection before using a different blend mode for the collection as a whole.
Yes. In principle, the transformation functions for the hue/saturation/color/luminosity operators could have more than one possibility, but in practice I think everyone has simply used the same functions for decades (as defined in the PDF specification). |
37b0b9c to
bb554e7
Compare
2221d69 to
6d49bcf
Compare
|
This is pretty cool :-)
Actually I suspect that another possibility is to want some nonstandard blending between multiple artists, then "over" blending of the result over the background. In general I suspect this would be related to adding support for temporary, intermediate rendering buffers, which is also something that would be useful for other purposes e.g. contour label overplotting (#26971 (comment)). |
|
By the way, I decided to rename "over" to "normal". That mode of blending is referred to as "normal" often enough, and it makes it readily apparent to users that it is the standard choice (and the default). |
6d49bcf to
63f53c9
Compare
63f53c9 to
c9552d5
Compare
f49e8d0 to
f7af1e4
Compare
f7af1e4 to
d313054
Compare
d04f663 to
c287d35
Compare
I think it incredibly unlikely that the blend-mode API would change. There might be reason to change the blend-group API, but that also seems unlikely to me. If I were trying to add |
I'm not sure we've ever actually changed our provisional API (subplot_mosaic was provisional for years), it's just a kind of emergency escape/hedge on mostly big changes. |
|
I have moved the fixes for contourf and pcolor/pcolormesh out of this PR to make this PR slightly more wieldy to review. The bugs are less apparent to users because it requires antialiasing to be turned on, which is not the default. I'll PR those fixes after this PR is merged. I have retained the fix to Agg Gouraud shading because the bug is easier to be encountered by users and would be immediately seen in the blend-mode gallery. |
|
Also, do you want to squash merge this when complete? |
This PR feels too hefty to be a single commit. Once the PR is approved, my inclination is to squash the review-triggered commits back into the first ~10 commits in the appropriate places. |
There was a problem hiding this comment.
Minor clarification on knockout and a bit confused on blend modes but otherwise this is awesome and thanks for your patience. Also sorry for the delay in getting back to you.
Also you might wanna make a blending mode :mpl_type:
matplotlib/lib/matplotlib/sphinxext/roles.py
Line 129 in e519c44
Done!
I have now done this, so this PR is ready for (non-squashed) merging. |
| Blending and compositing groups of artists | ||
| ========================================== | ||
|
|
||
| An advanced technique of blending artists (see :ref:`blend-modes`) is to use a |
There was a problem hiding this comment.
Just a suggestion, but since blend groups is an advanced topic depending on blend modes, I'd suggest making this a subsection of an overall "blend modes and groups" page with two subsections.
- Artist blending and compositing:
- per artist blending and compositing
- blend groups to create layers of composition.
I'm not sure a reader who doesn't know these terms would know which of these to drill down into.
There was a problem hiding this comment.
I think it's fine as is b/c @ayshih structured it so the blend_modes page comes first in the order.
|
Congrats @ayshih! Appveyor and wasm failures are unrelated. Discussed on call and decided that doc changes can happen in follow ups as there are arguments for both approaches. |
|
Thanks for the reviews and merge! |
PR summary
This PR adds support for blend modes beyond alpha blending (e.g., "screen" or "hard light"), so closes #6210. With this PR, all artists can specify
blend_mode, and they are supported by Agg-based and Cairo-based backends, and mostly supported by SVG/PDF/PGF backends.Of course,
mplcairoprovides access to these blend modes, but this PR provides blend-mode support without needingcairo.Update: This PR uses this functionality to fix a long-standing bug (e.g., fixes #27016) with Agg rendering of Gouraud shading, where the edges of triangles would become visible when transparency is involved.
Update: This PR adds support for blend groups, which can be isolated, knockout, or both.
✅ = supported, 🟡 = supported through rasterization, ❌ = not supported
color dodge, color burn, hard light, soft light,
difference, exclusion
Agg showcase
Gouraud shading can look wrong with some blend modes, for the same reason it can look wrong under normal blend mode when alpha < 1, due to overlapping trianglesNow fixedCairo showcase
Gouraud shading is apparently not supported by the Cairo backend, so I commented out the pcolormesh callI added support for Gouraud shadingWindows
macOS
SVG showcase
PDF showcase
Figure_1.pdf
PGF showcase
Figure_1.pgf.pdf
Generating code
Put off to future work:
pcolormesh.snapbehaves when the mesh edges are not horizontal/verticalcontourf()/pcolor()/pcolormesh()to beTruePR checklist