GIF89A and PIL

Stephen Hansen apt.shansen at gmail.invalid
Sat Mar 27 22:44:54 EDT 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 
undocumented. :(

> 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
> files.

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.

-- 
--S

... p.s: change the ".invalid" to ".com" in email address to reply privately.




More information about the Python-list mailing list