Filesize concerns

[jvanasco]

I've noticed that the images created by PIL are quite large.

gifs seem to be over 4x larger than they could be.
pngs are around 130% larger

i tested this just off of pillow created files vs the same ones imported/exported through a graphics app. ie, i used lossless compression on the second time.

as a quick example, i drew some text on a canvas. a (256 color) gif from pillow was around 12k; the same gif was opened & exported to 2k using an app. pillow generated it as 3 color gif at 3k (larger filesize than the much better looking 256 color), while it was a few hundred bytes via an app.

there are a handful of advanced image 'compressing' apps out there too, which do lossless optimizations. i didn't run the images through any of them.

i'm wondering if anyone here knows any techniques or ways to address this. i thought this might have something to do with the old gif patents, but they're long expired and pngs seem to be affected.

[wiredfool]

There's a comment in the GIF c code that it's not a particularly optimized quantizer, and that there are other algorithims that would be better. There's also a outstanding issue to add pngquant support, which is an optimized png quantization library. (not sure if that would work in the gif case, it might).

[jvanasco]

i have a workaround, where i save files to a named tempfile , then run pngcrush / gifsicle / jpegtran on it... outputting into another named tempfile.

It works well on Mac/Linux. The 3 apps are available on Linux and ImageOptim.app ( http://imageoptim.com/ ) has a resources folder that has those 3 ( plus a few more ) compiled; I just add that to my path.

It has 2 huge caveats though:

1- The overhead and limitations of external processes (which can create issues when you're in a daemonized/threaded scenario )

2- It's not windows-safe. I don't think i'd ever use windows at this point, but the NamedTempfile support in windows doesn't support a second process opening up the file ( linux/bsd does )

[wiredfool]

There are a couple of methods in Pillow for saving to Gif (and jpeg) using external programs. I'm not really happy with them for a few reasons, those caveats among them.

[hugovk]

From #2480 (closed as duplicate of this):

---

What did you do?

Reverse a gif get it much bigger size on disk

What did you expect to happen?

Still the original size or only a bit more

What versions of Pillow and Python are you using?

latest Pillow and 3.6 Python

from PIL import Image, ImageSequence
from PIL import ImagePalette
with Image.open('sd.gif') as im:
    if im.is_animated:
        frames = [f.copy() for f in ImageSequence.Iterator(im)]
        frames.reverse()
        frames[0].save('out.gif', save_all=True, append_images = frames[1:])  

[jvanasco]

I'm not familiar with the exact inner workings, but #2480 is probably not the same as this (or an issue at all).

I should probably address some of the earlier comments in here too.

This ticket shouldn't have to do with quantization (which is lossy) but is meant to address bloat issues when doing a lossless encoding as gif. Perhaps Pillow is running the gif through the quantizer when it doesn't have to, and could just ignore it if the number of colors is small enough?

In terms of #2480, animated gifs are built off of deltas -- not individual frames. The bloat could also be created by:

• the original gif uses diffs, the Pillow created gif uses full frames
• reversing the image drastically changes the filesize of a few frames.
• other things (It's the end of the day!)

[wiredfool]

Actually, it's simpler than that. Pillow doesn't do compression on GIFs. It only implements the uncompressed frame format. So anything that's going to do GIF compression is going to beat it. There was code for that, but it was in the closed source PILplus extension.

Pillow does diffs of frames, though there's some subtle details of the disposal methods when writing that would mess with that. There is a new quantizer that's been merged since this issue came in, but that's also probably not the main issue anymore.

[TheRockettek]

Meanwhile my pillow just made a 800kb file into a 1.2Gb file somehow

[wiredfool]

If you’d like to contribute a gif compressor under the PIL license, go for it.