GIF89A and PIL
apt.shansen at gmail.invalid
Sun Mar 28 04:44:54 CEST 2010
On 2010-03-27 08:17:46 -0700, Alain Ketterlin said:
> Stephen Hansen <apt.shansen at gmail.invalid> writes:
>> If not, are there any decent other image libraries out there
>> that anyone's familiar with? The only one I could find was
>> PythonMagick, which seems completely undocumented. Or I'm blind.
> I don't know PythonMagick, but it is based on ImageMagick, which is kind
> of a swiss-knife in image manipulation and conversion. You could try the
> standalone tools first, to see if you get what you want/need.
Well, I know it -can- do what I need, except the subprocess business
isn't something I want to deal with. And the library seems utterly
> Hmm, a 16x16 image. Don't expect much from the most sophisticated
> formats (e.g, PNG), because their overhead (headers etc.) may well be
> above the size of the data. Compression isn't usually targeted at small
Yeah, I don't expect much from PNG. The images are very small but I
might be sending a LOT of them over a pipe which is fairly tight, so
50-60 bytes matters. That's why I selected GIF.
> (BTW: "slight tweaking" may have an effect on file-size if it introduces
> new colors, because GIF uses a color-table. I guess you know all this.)
Yeah, I know this is possible, which is why the tweaking was to be very
careful: these images all have only a couple indexed colors each, and I
should be able to do the tweaks and not increase the size excessively.
However, the problem is: I left out all the tweaks and it still
exploded in size.
Just opening, and then saving the same file with no changes at all,
resulted in a 72 byte file growing to 920.
I thought it was GIF87a vs GIF89a... but have since come to determine
it doesn't appear to be. I decided to give PNG a try again, since those
extra 50 bytes *matter*, but if I can't get GIF to work, 50 is better
then 900. Unfortunately, I hit the same wall there.
If I convert these itty-bitty images into PNG, they're about 120 bytes
or so. Opening one in PNG, making no changes, and saving, results in
the new file being 900 bytes too :(
So I wonder if there's just some hyper-optimization Photoshop does that
PIL can't round-trip.
> GIF uses the LZW algorithm, and so does zip and gzip (the latter with an
> additional layer of Huffmann coding). If your images are of fixed size,
> you _may_ be better off compressing the raw data with a general purpose
> compressor (i.e., gzip). Check the packages gzip and zlib.
Hm. I hadn't thought of compressing the saved version. I could do that,
I suppose: it just seems there is so much extra stuff which shouldn't
be needed that's being saved out.
... p.s: change the ".invalid" to ".com" in email address to reply privately.
More information about the Python-list