-
-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
GIFs saving with unexpected transparency (or perhaps undefined pixels?) #8003
Comments
Testing in Firefox on my Mac, I find this is due to #7568 If you would like an immediate fix, just add frames[0].save('test.gif', save_all=True, append_images=frames[1:], loop=0, optimize=False) |
I also find that setting the disposal to 1 fixes it. frames[0].save('test.gif', save_all=True, append_images=frames[1:], loop=0, disposal=1) The GIF specification describes disposal of 1 as "Do not dispose. The graphic is to be left in place", and our default disposal of 0 as "No disposal specified. The decoder is not required to take any action". Testing further, the key part of changing the disposal is that Pillow adds the Graphic Control Extension. It is an optional block, and I think you could argue that according to the specification, that shouldn't change the image at all with the values we're giving it - meaning the bug is in Firefox, and I don't think Pillow is incorrect. Is changing the disposal in your code an acceptable solution? |
From my reading of the specification, the following Graphic Control Extension block
means that
Because the specification states that "This block is OPTIONAL", I would expect an image to render the same way if this empty block is present or not. However, while Google Chrome does behave according to my expectations, Firefox does not. To demonstrate, unless I'm mistaken, the only difference between these two GIFs should be that one contains instances of this empty block, and one does not. |
Closing this issue as no feedback has been received. |
I reported the problem to Firefox in webcompat/web-bugs#136378, but they couldn't see a problem - which is not at all what I expected. The obvious fix for this would be to add the empty GCE blocks to Pillow GIFs, but given that
I'm reluctant to do so. |
The Firefox problem was able to be replicated after all, and can be tracked at https://bugzilla.mozilla.org/show_bug.cgi?id=1895712 |
I tried simply adding a Graphic Control Extension block to the "without empty" gif and it still reproduces the problem in Firefox. So that first Graphic Control Extension block doesn't seem to be the key. There seems to be other differences between the gifs, for example in the "without empty" every Graphic Control Extension block has the transparent bit set, but in the "with empty" there are plenty of Graphic Control Extension blocks both with and without the transparent bit set. Not sure exactly what is going on yet, still investigating. |
What did you do?
Saved a gif using a library I built a while ago. Since updating Pillow to 10.2.0 (or newer) parts of the gifs would often randomly be transparent. Or so I thought: while writing this bug post it appears that undefined may be a better way to describe them.
What did you expect to happen?
None of the gif should be transparent: it was created using only a 3-channel RGB image. In this example (made using 10.1.0), the background should be black with random noise moving over it from left to right:
What actually happened?
The background is black before the random noise passes over it. After the noise has cleared, the background is sometimes black, sometimes it is not black. The colour that it is when it is not black seems to depend on the viewer. I have seen at least three different behaviours:
Some notes:
Minimally working example:
What are your OS, Python and Pillow versions?
Test machine 1:
Test machine 2:
Pillow Report Output
Details
The text was updated successfully, but these errors were encountered: