Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork8.1k
Fixed background colour of PNGs saved with a non-zero opacity.#1868
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Good catch!
Westacular commentedMar 31, 2013
Hi, I'm the one who posted that question on Stack Overflow. I've tested this code, and it doesn't fix the underlying problem -- the "cleared" (alpha=0) contents of the renderer are still being blended into the desired background color; the problem is merely masked with the included test because the test background and the cleared renderer are both black. I did some Googling and some digging into AGG (notably, findingthis) and I've found the culprit: It's the use of Should I submit a pull request with that fix, and some improvements to the test case? |
pelson commentedMar 31, 2013
Sure. You can submit them as PRs against my PR, or its own PR to mpl. Cheers@Westacular |
lib/matplotlib/tests/test_figure.py Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Comment now incorrect.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Oh! Oops. Can you fix that?
My reasoning for the colour change was to choose something that's likely to show a problem were the blending issue (or something like it) to reoccur, regardless of if it's being blended with black or white. So, zero for one colour channel, one for another, and something else for the third.
I changed the alpha to 0.4 simply because I was hand-calculating what the correct blended colour should be in the red circle, and (in theory) 0.4 leads to less round-off error when the values and calculations are being handled as uint8s.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Yep, I'll change it. I agree with your color test - it covers all the bases.
mdboom commentedApr 11, 2013
Thanks for the work on this. We've found a lot of subtle things out about Agg lately, haven't we? @pelson: I wonder whether if maybe we should rebase this on v1.2.x, since it's really sort of bugfix. I guess I'm waffling -- because obviously it will change behavior who are expecting transparent to come out as white in the PNG. There have been a few other notable bugfixes on v1.2.x since 1.2.1, and I'm wondering if it might be nice to have a 1.2.2 sooner rather than later. |
pelson commentedApr 11, 2013
Yes. As we speak I'm going through the Agg backend to have another look at compound rendering, so I might turn over some more too...
I certainly have a couple of bugs that need my attention before a v1.2.2, but I also note that v1.3 athttps://github.com/matplotlib/matplotlib/blob/master/doc/users/whats_new.rst#new-in-matplotlib-1-3 lists more new features than any other release. There is definitely a debate to be had on the dev mailing list about when to start aiming for a v1.3 (I hate sounding like a broken record 😄 - I'm sorry about that!). |
pelson commentedApr 12, 2013
I've updated this (with a trival change). I think this is now good to go. |
mdboom commentedApr 12, 2013
Can you rebase this on master -- it currently won't merge cleanly. That will give us another go around with Travis, too. |
efiring commentedApr 28, 2013
The only conflict is a trivial one in doc/users/whats_new.rst. Tests look OK, with 1 error and 2 failures related to fonts; I don't think there is any relation to this PR. |
pelson commentedApr 29, 2013
I've squashed and rebased. Just waiting for travis-ci to do its thing & then I think it's good to go. |
mdboom commentedApr 29, 2013
My only hesitation is that the PDF backend isn't matching Agg now. Have you had a chance to look into that, or should I? |
Westacular commentedApr 29, 2013
I'm not sure what you're referring to. What is the issue/mismatch with PDF? |
mdboom commentedApr 29, 2013
The |
Westacular commentedApr 30, 2013
As far as I can tell, the PDF being produced is correct. The ghostscript conversion of the PDF, however, insists on blending the PDF data with a white page background colour (eliminating all transparency in the process), and I've been unable to figure out a way around that. (The options that do support transparency seem to consider it an all-or-nothing matter.) I've also been unable to find a way specify page colour within the PDF, and I suspect there isn't one. Converting the PDF to PNG using Inkscape gives a PNG with the correct colours and alpha values. |
mdboom commentedApr 30, 2013
Ah, I see. Well, maybe we should just update the comment then, to On Apr 29, 2013 9:06 PM, "Wes Campaigne"notifications@github.com wrote:
|
pelson commentedMay 1, 2013
I've just added that comment@mdboom in an appended commit. I always find it odd that I can modify the history of another author with git... |
…2, which fixes a problem with alpha-blending partially transparent backgrounds.
pelson commentedMay 1, 2013
Woops, pushed the wrong branch. Fixed now. |
Fixed background colour of PNGs saved with a non-zero opacity.
pelson commentedMay 1, 2013
Thanks for merging@efiring. Great work@Westacular - this is really nitty-gritty matplotlib. Thanks for your contribution! |
The following code (a derivative ofhttp://stackoverflow.com/questions/15691297/how-to-directly-set-alpha-channel-value-for-matplotlib-figure-background-colour) was producing a png with an unexpected background colour. This PR fixes the problem so that the background colour of a PNG is as expected (and consistent with SVG).
Yields:
After this change, the result is:
I'm not certain why the value is not exact, but I'm comfortable with the approximation.
There remains a problem with PDF creation (& other backends not tested). I do not propose to fix the PDF issue in this PR.