-
-
Notifications
You must be signed in to change notification settings - Fork 2.2k
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
GIF has transparency issues, not all fixed with PR #6176 #6260
Comments
I’ll work on this. |
For your first problem, I've pushed another commit to #6176, along the same lines of thoughts that you have. With that, and from PIL import Image
with Image.open('aniship.gif') as im:
im.save(f'new.gif', save_all=True, optimize=True, interlace=0, disposal=2) |
I've now pushed another commit to #6176 to remove transparency if it is not used. So this issue should now be resolved by that PR. Let me know if you find otherwise. |
Thank you. I must apologize about the code I posted at the top of this. I neglected the |
What did you do?
Copied an animated GIF:
What did you expect to happen?
Hoped the copy would be something like the original aniship.gif:
What actually happened?
With PR #6176 applied, I get an artifact of (apropos of the nautical theme) aqua background on first frame:
What are your OS, Python and Pillow versions?
Discussion:
Issues of transparency continue to vex GIF handling. Not sure if I have a complete handle on this yet but will try.
In
_write_multiple_frames()
there is a call to_normalize_palette()
, which calls.remap_palette()
which callsconvert("L")
which changes.info["transparency"]
. This happens after the fix of PR #6176. Also,.remap_palette()
changes the palette but does not make a corresponding change to the transparency index. So here is a proposal (not yet a PR because it conflicts with PR #6176 and because I don't know if it's a good fix):Add a function:
Then in
_normalize_palette()
changeto:
This changes
.info["transparency"]
to the remapped transparency index, if it was in the used palette to begin with. (More about this below... still a problem.)Then in
_write_multiple_frames()
put the call to_normalize_palette()
ahead of the set ofencoderinfo
:I don't know if changing the order of these statements from PR #6176 cause a problem or not.
Another problem is: what if there is a transparency index (i.e. the Transparent Color Flag is set) but the index is to an unused color? My "fix" above to
_normalize_palette()
will not changeim.info["transparency"]
and may leave it referring to a color that is used and should not be transparent. This happens with that Tazspin.gif I used in Issue #6259. Only affects about 3 pixels there so it is not visible but could be a problem for some GIFs. Maybe there's an easy way to force the index to an unused color in this case?BTW aniship.gif has no GCT, only LCTs (and they're all the same). The current 9.1.0 either with or without PR #6176 will create a reduced GCT of 8 slots (of used colors) but leaves the transparent color index at 14, pointing to a non-existent entry.
The text was updated successfully, but these errors were encountered: