-
-
Notifications
You must be signed in to change notification settings - Fork 2.2k
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
Filesize concerns #617
Comments
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). |
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 ) |
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. |
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:]) |
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:
|
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. |
Meanwhile my pillow just made a 800kb file into a 1.2Gb file somehow |
If you’d like to contribute a gif compressor under the PIL license, go for it. |
Does anyone in this issue have a specific image that demonstrates this problem? |
I can try to recreate my older test images this week. |
I've got an animated gif which increases 10x in size when read, then re-stored as-is (with |
Complement: I was on a version of Pillow preceding #5291, updating to 9.2.0 does improve things significantly (the image still increases after saving but only to 400k). |
There isn't a complete example in the StackOverflow post of the resizing, but for the initial example where the user is just resaving the image, testing it with main now it is only output as 2.3mb.
This is because |
I'm hoping that between #5291 in Pillow 8.2.0 and #7568 in the upcoming Pillow 10.2.0 (reducing #617 (comment) from 408kb to 345kb), the GIF filesize concerns in this issue are now resolved. |
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.
The text was updated successfully, but these errors were encountered: