Closed karolyi closed 2 years ago
Here's an image where the decoding (image.convert(mode='RGBA')
) screws up the palette for some reason:
I've tried it out with the test code I posted above, it seems the RGBA conversion is the culprit, which is not my table.
This one's even worse, the culprit again is the RGBA conversion.
Please refrain from posting inappropriate images.
@radarhere there was no nudity on either of them, you're being a bit too sensitive. You deleted images that can be used as test for decoding failures. Fine with me though, as it seems by my experience that these images are around 2% of the animgifs I see wrongly decoded. But still, something's off with them.
Good to see they're still available in the history.
With gifs from my issue as you asked, it has the same issues as Pillow (black borders and bad frame combine), since it doesn't do anything different for loading gifs. It also looses information on frame duration (makes them all the same).
I've checked your images and seen that during the conversion, the duration
info values come through. So the culprit for F-ing up the durations is the GIF saver logic, seemingly.
Despite @karolyi 's slightly inappropriate picture, this is exactly the results I'm getting as well and it's extremely frustrating. The first frame appears fine, yet no matter what I try to do the frames after the first always look that way. Is there any workaround for this at all?
@karolyi thank you for the workaround code. I also suffered for a few days with black pixels replacing my transparency. Your code worked to correct the issue for me with some slight adjustments to meet my need.
The one limitation I have observed is that the code above does not play well with partial alpha transparency. It seems to "flatten" the alpha to fully solid colors. But it works well for transparent, moving gif animations that use only alpha channels 0 and 255.
If it's helpful to anyone else, here is a slightly adapted version of karolyi's code that is a bit easier to plug-and-play with. You can simply call the save_transparent_gif
method of this code with your list of images and durations. Minimal (if any) editing should be required:
https://gist.github.com/egocarib/ea022799cca8a102d14c54a22c45efe0
I hope that this issue can eventually be fixed.
With gifs from my issue as you asked, it has the same issues as Pillow (black borders and bad frame combine), since it doesn't do anything different for loading gifs. It also looses information on frame duration (makes them all the same).
Did you have fixed the bug?
this is the src gif but I run your code get the error result
I expect this is now resolved, as Pillow 9.0.0 has significantly improved reading animated GIFs with #5857.
I'm running into this bug on 9.0.1. Venv with example: pillowtest.zip
On further inspection, it may not be the same bug, but it seems similar. I'll take this to a new issue.
Thanks!
Hey,
after a week of fiddling around with Pillow and reading/testing the source, I've written a module that will allow for processing an animated GIF while retaining its transparency throughout all frames.
In my case, I needed to create thumbnails (various sizes) and watermark them, then bumped into the problem of Pillow not being able to properly handle these files.
Attached you will find a pillowtest.zip that contains the code and demo files for the code.
For simplicity's sake, here's the source:
Do what you want with it, I don't care. I have tried to touch the source but to me it seems such a huge mess that I rather didn't touch it after discovering/debugging the code execution paths it. You can test the conversion of all the images within the zip, most of which is a transparent animated GIF, works with every one of them. The key thing is, transparent palette indexes should be the same throughout all frames, that's what this module does.
Things I wanted to do but it seems impossible without a huge rewrite:
bytes.translate
(see the code) one would be able to process and shrink palettes very efficiently, but it makes no sense to do it in here because the final palette will get overridden inGifImagePlugin.py
anyways.All in all, the gif module in my opinion is in for a huge rewrite, but I can't offer my help since I'm busy with something else right now. Also, the compression in the C extension is highly needed to cut the generated file sizes less then half, most of the time.