Strangely, the image from#5302 is white in the transparent parts, so I'm not sure what Pillow is doing.

Anyway, 👍 from me, but I'm not sure where 2.0.1 fixes are going.

This is passing and ready to merge.

Just curious. Do we want to hardcode a white background, or should we be getting the color from an rcParam?

I think adding an rcParam would just add complication to this. We already have an rcParam for the figure background (savefig.facecolor). If the user really wants a different background color, they can just set that. Thisonly deals with the case where the background was accidentally set to transparent (throughsavefig.transparent or thetransparent kwarg) without realising that JPEG can't handle that.

That said, I suppose it could go tosavefig.facecolor, which by default is white.

Right... that was the param I was thinking of.

On Tue, Oct 27, 2015 at 11:05 AM, Michael Droettboom <
notifications@github.com> wrote:

That said, I suppose it could go to savefig.facecolor, which by default
is white.

—
Reply to this email directly or view it on GitHub
#5324 (comment)
.

This now gets the background color fromsavefig.facecolor as suggested by@WeatherGod.

The test failures are puzzling, and I can't reproduce locally. 😢

Perhaps add a useful message for the assert so that we can see what the value is?

prints aren't getting caught by nosetests (I think it is some sort of option set by us). Add that stuff to the assert message so that the exception will print out the relevant message.

When I first tried coming up with a patch, I tried usingtostring_rgb from the renderer but that doesn't seem to be good enough. My guess is that RGB doesn't really 'flatten' the transparency regions when converting from RGBA, which I thought would've been the ideal solution, which I think would allow for figures to be given figure.facecolor and axes to be given axes.facecolor. But honestly I don't think anyone really uses transparency; except fornbagg that insists on having transparency in the figure.

I opened up a new issue related to this#5335.

Printing does work; it's just muddled between the dots: "num colors: 181". It does not print the corner pixel because the colour count assert has already failed.

@QuLogic: Thanks for catching that. My hunch is there is some variability because it's lossy JPEG. I'll just increase the range somewhat.

@cbreeden: I suppose we could try to fixtostring_rgb as well, but it would need to have a background color as an argument added. I've created#5336 for that.

Do we want to backport this to 2.x?

Sounds reasonable to me; it can be viewed as a bugfix. But it also makes me wonder whether saving a jpg withtransparent=True, which this handles, should raise a warning.

I guess this was not backported, then?

Backported to v2.x via1e437d3.