The fix for jpeg images in#5324 may be useful

This looks good. It does mean we now have two ways to flatten images. This way is more general, though, as it doesn't rely on PIL. Can you modifyprint_jpeg to call out to the newflatten_rgba function?

Also,flatten_rgba should probably live inimage.py since I anticipate it will be useful to other non-Agg backends in the future.

I wonder how much this overlaps with theimage.combine_image feature? I
know it isn't the same, but it would be good to keep similar concepts as
compact as possible.

On Fri, Nov 6, 2015 at 7:52 AM, Michael Droettboom <notifications@github.com

wrote:

This looks good. It does mean we now have two ways to flatten images. This
way is more general, though, as it doesn't rely on PIL. Can you modify
print_jpeg to call out to the new flatten_rgba function?

Also, flatten_rgba should probably live in image.py since I anticipate it
will be useful to other non-Agg backends in the future.

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

Sorry, that isimage.composite_image.

On Fri, Nov 6, 2015 at 9:41 AM, Benjamin Rootben.v.root@gmail.com wrote:

I wonder how much this overlaps with theimage.combine_image feature? I
know it isn't the same, but it would be good to keep similar concepts as
compact as possible.

On Fri, Nov 6, 2015 at 7:52 AM, Michael Droettboom <
notifications@github.com> wrote:

This looks good. It does mean we now have two ways to flatten images.
This way is more general, though, as it doesn't rely on PIL. Can you modify
print_jpeg to call out to the new flatten_rgba function?

Also, flatten_rgba should probably live in image.py since I anticipate
it will be useful to other non-Agg backends in the future.

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

I wonder how much this overlaps with theimage.combine_image feature? I know it isn't the same, but it would be good to keep similar concepts as compact as possible.

That's a good point. I think the image compositing stuff is bound to be slower than this because it's not on a solid color, but you're right there is some functionality overlap there.

Just for reference, I believe the core of theimage.composite_image code lives here:

Whether a vector graphics backend should composite several imagesinto a single image or not when saving. Useful when needing to edit the files further in Inkscape or other programs.

Let me just reiterate the issue that this PR is trying to correct. In some backends, transparency in the figures are enabled by default (nbAgg does this with and can be modified withnbagg.transparent). Matplotlib will then send images with an 8-bit alpha channel to their respective animators (sometimes using png as an intermediate file format). These animators are then forced to flatten the alpha channels and seem to get confused by either just truncating the alpha channel all together, or by picking some kind of threshold and setting the alpha to Full or None in the case of formats that handle boolean transparency (like gif).

I'm not sure it is worth having a configurable setting for turning on and off the flattening of RGBA before handing it off to animators. Ifclear_temp was accessible (I think I had to modify it from source) in the FileWrites then it might be beneficial to open theflatten keyword to the public in case someone really only wants each individual file for further processing.

whoops. Tried to --amend the1759556 commit, but obviously it didn't work out the way I planned.

@cbreeden We seem to go through the pep8 discussion with every new contributor 😉 . It really does help on the large code base to have a more-or-less uniform style.

Install an auto-linter in your editor and it becomes much less annoying.

Can you also re-base to remove that merge commit?

Pending the Travis CI tests, I think I'm done here. Unless someone wants me to add documentation for the addedflatten flag for savefig in the nbagg for png. It might also be worth looking into other backends. I had this comment from stackoverflow (http://stackoverflow.com/questions/33283274/pixelated-fonts-when-plot-is-saved-as-jpeg) when first running into this problem:

I seem to get the same results as you with nbagg, but with Agg my jpg looks much better. With the MacOSX backend both the jpg and the tiff have the pixellated fonts – tom

It might be related, but I don't have a Mac to test.

Not sure why the build failed. I'm quite certain nothing I did should impact anything that test did. I tried running the code on my local python (3.4) andtest_savefig_to_stringio worked fine. I think Travis CI just hasn't had its coffee yet.

@cbreeden about Travis you are right these failures are annoying but intermittent and not related to your work

@cbreeden This sadly needs a re-base now 😞

@tacaswell no worries. I am quite new to git. In fact, I only picked it up so I could try to make this patch. Now I got the chance to handle my first rebase conflict; and I think I did it correctly, even 😥

@cbreeden Sorry this fell off my radar.

Could you rebase this again?

I'm not seeing the original issue in nbagg, and I know some work was done to fix the transparency issues recently. I'm going to close as abandoned but if there is important work in here, please feel free to re-open....