Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #5333 from radarhere/gif_frame_transparency
- Loading branch information
Showing
8 changed files
with
64 additions
and
43 deletions.
There are no files selected for viewing
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
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
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
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
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
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
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
c54a7bb
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.
When decoding a gif, if the local color table is different from the color table referenced by values already in
image8
, the values left unchanged inimage8
will use the wrong colors. Leavingimage8
as is when decoding does not make sense when a local color table is present, pasting gif frames on top of one another should be handled outside of the decoder again where there isn't a reliance on a palette size of less than 256. I think this commit should be reversed and this issue should be fixed outside of the decoder.c54a7bb
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'd like to try and understand, so bear with me.
I would have thought that a local color table only affects the pixels coming in from that new frame, not any of the previously loaded pixels.
Take this GIF for example.
The first frame has a local color table of b'\x00\x00\x00\xff\x00\x00\x00\x00\x00\x00\x00\x00' - black, red, black, black.
The second frame has a local color table of b'\x00\x00\x00\x00\xff\x00\x00\x00\x00\x00\x00\x00' - black, green, black, black.
If we followed your suggestion, wouldn't that mean that the second frame didn't have any red - when the browser clearly thinks that the second frame should have both a red and a green box?
c54a7bb
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.
It is actually bugged as it is now. This is the current behavior if I open that gif and save it with the following code:
As you can see, with the current behavior, transparency in subsequent frames means leaving the same indices in the same position in the
image8
array, this means those indices now potentially refer to different colors in the new palette based on the new local color table.Here is that image if I revert this behavior by passing the decoder a transparency value of -1, so it does not retain any indices in
image8
:edited line 195 of GifImagePlugin.py
(bits, interlace, transparency),
to
(bits, interlace, -1),
That said, the second frame is now transparent where the first frame's red box is and the browser is layering the frames for us, the question becomes whether you want Pillow to load each frame with transparency or to do its best to stack each subsequent frame on preceding frames.