Skip to content
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

Do not load transparent pixels from subsequent GIF frames #5333

merged 3 commits into from Mar 31, 2021


Copy link

@radarhere radarhere commented Mar 16, 2021

Resolves #5307
Resolves #4650
Resolves #4313

Each frame of a GIF can have a different transparency. However, as Pillow reads the frames in, we also merge them into the result of the previous frames.

The premise of this PR is that this means that the merged second frame may have transparent pixels on one P index from the first frame, and transparent pixels from a different P index from the second frame. In other words, a single transparency is insufficient.

Instead, cherry-picking part of #3434, when loading the second frame, don't write the transparent pixels at all.

I have also added a new commit to only set info["transparency"] on the first frame, since the transparency index of subsequent frames is now meaningless to the user - the transparent pixels from those frames aren't in the merged image.

zewt and others added 3 commits March 16, 2021 23:17
Allow the transparency index to be passed to the native decoder.  If not
-1, pixels with this index will be left at their previous value.

This only adds the decoder support and isn't active yet.
Remove the special case for disposal_method == 1 and handle GIF
transparency by telling the decoder the transparent index.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
3 participants