Do not load transparent pixels from subsequent GIF frames #5333
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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.
This was referenced Mar 16, 2021
This was referenced Apr 8, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.