-
-
Notifications
You must be signed in to change notification settings - Fork 7.9k
Properly handle transparency for animations #5415
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 our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
The fix for jpeg images in #5324 may be useful |
img = self.flatten_rgba(img) | ||
_png.write_png(img, filename_or_obj, self.figure.dpi) | ||
else: | ||
_png.write_png(renderer._renderer, filename_or_obj, self.figure.dpi) |
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.
Minor point, but I think I like the way you organized the code in print_raw
better than here: i.e. set a local variable img
to the render contents and then optionally flatten it, ultimately passing img
into write_png on a single line.
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.
@mdboom I really wanted to do that at first, but I will be honest when I say that I didn't understand what was going on here:
matplotlib/src/_backend_agg.cpp
Line 28 in 0037595
RendererAgg::RendererAgg(unsigned int width, unsigned int height, double dpi) |
write_png
needed something from that or not.
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.
No -- it shouldn't matter. _write_png just converts whatever is passed in to a numpy array.
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 Also, |
I wonder how much this overlaps with the On Fri, Nov 6, 2015 at 7:52 AM, Michael Droettboom <notifications@github.com
|
Sorry, that is On Fri, Nov 6, 2015 at 9:41 AM, Benjamin Root ben.v.root@gmail.com wrote:
|
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 the matplotlib/lib/matplotlib/figure.py Line 1095 in 0037595
image.composite_image rcParam (I guess because this is new to 1.5?), and the description is given by:
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 with 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. If |
whoops. Tried to --amend the 1759556 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? |
c693df6
to
5bb8754
Compare
# Flatten RGBA if used with fileformat that doesn't handle trnasparency | ||
if kwargs.get('flatten', False): | ||
w, h = int(renderer.width), int(renderer.height) | ||
img = np.array(memoryview(img)).reshape((w, h, 4)) |
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.
Can someone verify that this is the correct reshape? For png I needed to use (h, w, 4) to avoid scanning line offsets. The images look correct.
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.
I think it should be (h, w, 4).
5af94d2
to
f0e2617
Compare
Pending the Travis CI tests, I think I'm done here. Unless someone wants me to add documentation for the added
It might be related, but I don't have a Mac to test. |
f0e2617
to
f9140ec
Compare
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) and |
@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 😞 |
…w to properly handle transparency in animations
Fix (h, w) consistency
05721b1
to
b2c4560
Compare
@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.... |
This PR is a first attempt at fixing #5335. I have added a
flatten
kwarg forsavefig
in the agg backend that will allow animation.py remove all transparency before sending it to its respective animator. I don't think it would be a good idea to merge this just yet, but was looking for feedback before proceeding.I guess I would still need to write a test. I'm not sure I handled the dimensions correctly for
_write_png
, animations look correct fromwrite='imagemagick_file
but that's definitely worth double checking.