Save GIF without loss of quality

[zxbzxb180]

I am currently using Pillow 9.4.0 and have noticed that the GifImagePlugin. py source code of Pillow uses this code to convert RGBA to P mode when processing GIFs, resulting in a loss of image quality. How can I resolve this issue？
im=im.convert("P", palette=Image. Palette. AdaPTIVE)

This is the input GIF

This is the saved GIF

Here is my code：

from PIL import Image, ImageSequence, GifImagePlugin
GifImagePlugin.LOADING_STRATEGY = GifImagePlugin.LoadingStrategy.RGB_AFTER_DIFFERENT_PALETTE_ONLY

gif = Image.open("input.gif")
frames = [frame.copy() for frame in ImageSequence.Iterator(gif)]
frames[0].save(
    "output.gif",
    save_all=True,
    append_images=frames[1:],
    optimize=False,
    disposal=2,
    lossless=True,
    loop=0
)

[Yay295]

If you convert the frames to mode P yourself, the first three lines of that function will be used, and they won't be converted a second time.

[zxbzxb180]

如果您自己将帧转换为模式P，则该函数的前三行将被使用，并且不会再次转换。

Yes, but if I convert it myself, the quality of the GIF will also decrease, and the final effect will be the same。

[Yay295]

This might work. I haven't tested it.

from PIL import ImagePalette
frames = [ ]
for frame in ImageSequence.Iterator(gif):
    palette = ImagePalette.ImagePalette("RGB", [x for pixel in frame.getcolors() for x in pixel])
    frames.append(frame.convert("P", dither=Image.Dither.NONE, palette=palette))

[radarhere]

You may or may not be familiar with this, but each frame of a GIF can only contain 256 colours. However, those frames can be overlaid on each other, really meaning that each frame of a GIF can introduce up to 256 new colors to the animation.

Taking a look, by the time you get to the last frame, there are 2989 colours. This is hard to convert to 256 without visible differences.

You might say that the original GIF managed it somehow. Yes, it would be by starting out with a limited number of colours and then introducing more as the animation continues.

I presume you're planning to apply some sort of transformation to these images down the line, and that will change the nature of this question again.

[zxbzxb180]

这可能有用。我还没有测试过。

from PIL import ImagePalette
frames = [ ]
for frame in ImageSequence.Iterator(gif):
    palette = ImagePalette.ImagePalette("RGB", [x for pixel in frame.getcolors() for x in pixel])
    frames.append(frame.convert("P", dither=Image.Dither.NONE, palette=palette))

Unfortunately, this will result in an error. I noticed that from the second frame onwards, getcolors() is set to None

[zxbzxb180]

您可能对此并不熟悉，但 GIF 的每一帧只能包含 256 种颜色。但是，这些帧可以相互叠加，这实际上意味着 GIF 的每一帧可以为动画引入最多 256 种新颜色。

看一下，到最后一帧时，颜色有 2989 种。这很难在没有明显差异的情况下转换为 256 种。

你可能会说原始 GIF 以某种方式实现了这一点。是的，它从有限数量的颜色开始，然后随着动画的继续引入更多颜色。

我估计你打算对这些图像进行某种转换，这将再次改变这个问题的性质。

Yes, I am planning to use Pillow to help me modify the GIF resolution and delete some frames in order to reduce the size of the GIF

[zxbzxb180]

You may or may not be familiar with this, but each frame of a GIF can only contain 256 colours. However, those frames can be overlaid on each other, really meaning that each frame of a GIF can introduce up to 256 new colors to the animation.

Taking a look, by the time you get to the last frame, there are 2989 colours. This is hard to convert to 256 without visible differences.

You might say that the original GIF managed it somehow. Yes, it would be by starting out with a limited number of colours and then introducing more as the animation continues.

I presume you're planning to apply some sort of transformation to these images down the line, and that will change the nature of this question again.

Yes, I am planning to use Pillow to help me modify the GIF resolution and delete some frames in order to reduce the size of the GIF, but I don't want this to lower the color quality.

[radarhere]

When you say 'modify the GIF resolution', are you planning on shrinking the image? If so, by how much?

[zxbzxb180]

When you say 'modify the GIF resolution', are you planning on shrinking the image? If so, by how much?

Yes, this may not be fixed, some are 300x300, some are 512x512. At the same time, I am considering deleting some frames to achieve the goal of reducing the image size, such as reducing it to below 500kb. Perhaps there are other ways?

[radarhere]

If you're interested in reducing file size, I suggest you upgrade Pillow, so that you get the benefits of #7568

[zxbzxb180]

Okay, I will try upgrading the version, but I have found that the color quality of the first frame of the saved GIF is normal, and changes only occur from the second frame onwards. At present, I have found that after running the line of code mentioned in my issue, the color quality of the frames seen by im.show() has decreased

[zxbzxb180]

Before running that code, im.show() is a normal color. I really don't know much about GIFs, so this makes me a little confused.

[zxbzxb180]

output.gif
first frame

second frame

[radarhere]

I'll try rephrasing this.

Each image in a GIF file is limited to 256 colours. That has nothing to do with Pillow, that is a limitation of the format. So the line that you have found is converting each frame from however many colours down to 256. Attempting to do so with an image with more than 256 colours can't be lossless, naturally, so that's why it comes out looking different.

But if GIF frames only have 256 colours per frame, you might ask, why isn't that already the case in the GIF file I start with?

Within your 400x400 file, the second frame does not necessarily have all 400x400 pixels written. It might only have a certain region, or it might only have the pixels that changed, leaving the others transparent. It looks normal in the end though because that frame can be pasted on top of the first one.

Because of this pasting operation, there can be more than 256 colours as the animation goes on.