Animated transparent GIFs broken?

[TheRealQuantam]

It seems like opaque pixels in the first frame are being left opaque when they should be made transparent in the second frame. The dragon rider on the 5th row really shows it off well.

Without transparency (no transparency parameter to save):

With transparency (transparency = 16):

[TheRealQuantam]

Those images were generated with Pillow 9.1.1. I just updated to Pillow 9.2, but the problem is still there.

[radarhere]

Could we get a self-contained example to demonstrate this? So the code you are running, and the input image?

[TheRealQuantam]

Here.

bad_trans_anim_gif.zip
.

[radarhere]

If you add disposal=2 to the arguments when saving, I find that it works.

Disposal is a part of the GIF format, indicating how the contents of the previous frame should be treated. Should they not be disposed, and left in place, so that the next frame can build on top of that? Should they be disposed, and should we reset to the background color?

Our documentation about the disposal setting can be seen at https://pillow.readthedocs.io/en/stable/handbook/image-file-formats.html#saving

[TheRealQuantam]

Hmm. Is that how it's supposed to be done, or a workaround (i.e. should Pillow be figuring out for itself what regions can be kept and which should be overwritten)? It seems to generate significantly bigger files for images with a lot of regions that are always opaque (though that's irrelevant if the smaller ones were genuinely malformed).

[radarhere]

Is that how it's supposed to be done, or a workaround

While I can appreciate that you might like to just pass Pillow a series of images, and not worry about the
specifics of the GIF format, Pillow values backwards compatibility. This option was added in #2902, and to change the default behaviour now could break existing code.

(i.e. should Pillow be figuring out for itself what regions can be kept and which should be overwritten)?

Pillow does actually already have code that tries to ignore the parts of GIF frames that are the same.

It seems to generate significantly bigger files

#617 is an open issue for filesize concerns.

[TheRealQuantam]

Thank you.