GIF89A and PIL

Discussion:

GIF89A and PIL

Stephen Hansen

2010-03-27 01:45:54 UTC

Hi, all.

Is it possible to get PIL to save GIF's in GIF89A format, instead of
GIF87A? 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.

Ahem.

But the problem is, I have a nice, small little 72 byte GIF89A file,
that I want to do some slight tweaking on and then re-save. I noticed
that even if I completely skipped the tweaking step and -just- saved,
it exploded into a 919 byte GIF87A file. And in this context, bytes
really, really matter. I picked GIF over PNG because the same file in
PNG was 120 bytes :)

I'm not an expert on graphics, so I don't actually know for certain if
its the fact that PIL is saving in GIF87A format that's causing the
size to explode, it might just be that PIL is doing.. Something Weird
when it saves it as a GIF, too.

f = open('../tiles/BaseTemplate.gif', 'rb')
d1 = f.read()
len(d1)

'GIF89a\x10\x00\x10\x00\x80\x00\x00\xff\xff\xff\x00\x00\x00!\xf9\x04\x00\x00\x00\x00\x00,\x00\x00\x00\x00\x10\x00\x10\x00\x00\x02
\x8c\x8fi\xc0\xed\xbe\x9edq\xbej\x1b\xce`go\x81\x93(\x91W\xc0AhJ\xad\xac\xa9*\xb2Q\x00\x00;'
im = Image.open('../tiles/BaseTemplate.gif')

import cStringIO
cfp = cStringIO.StringIO()
im.save(cfp, format="gif")
cfp.seek(0)
d2 = cfp.read()
d2

'GIF87a\x10[...snip...]\x00;'

len(d2)

919

--
--S

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

Lawrence D'Oliveiro

2010-03-27 04:37:10 UTC

Permalink

In message <2010032618455468300-aptshansen at gmailinvalid>, Stephen Hansen

Post by Stephen Hansen
Is it possible to get PIL to save GIF's in GIF89A format, instead of
GIF87A?

Why? What does GIF do for you that PNG doesn?t?

Stephen Hansen

2010-03-27 04:53:10 UTC

Permalink

Post by Lawrence D'Oliveiro
In message <2010032618455468300-aptshansen at gmailinvalid>, Stephen Hansen

Post by Stephen Hansen
Is it possible to get PIL to save GIF's in GIF89A format, instead of
GIF87A?

Why? What does GIF do for you that PNG doesn?t?

If I take this PSD and save it as a GIF as fully optimized as possible,
its 72 bytes; do the same with PNG, and its 120.

In this situation that difference really is very important.

--
--S

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

Alain Ketterlin

2010-03-27 15:17:46 UTC

Permalink

Post by Stephen Hansen
Is it possible to get PIL to save GIF's in GIF89A format, instead of
GIF87A?

GIF89 was patented. I guess that is why it isn't used by PIL. (The
patent has expired now, IIRC.) Anyway, PNG was supposed to replace GIF.

Post by Stephen Hansen
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.

Post by Stephen Hansen
But the problem is, I have a nice, small little 72 byte GIF89A file,
that I want to do some slight tweaking on and then re-save. I noticed
that even if I completely skipped the tweaking step and -just- saved,
it exploded into a 919 byte GIF87A file. And in this context, bytes
really, really matter. I picked GIF over PNG because the same file in
PNG was 120 bytes :)

[...]

Post by Stephen Hansen

f = open('../tiles/BaseTemplate.gif', 'rb')
d1 = f.read()
len(d1)

'GIF89a\x10\x00\x10\x00[...]'

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.

(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.)

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.

-- Alain.

Stephen Hansen

2010-03-28 02:44:54 UTC

Permalink

Post by Alain Ketterlin

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. :(

Post by Alain Ketterlin
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.

Post by Alain Ketterlin
(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.

Post by Alain Ketterlin
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.

Harishankar

2010-03-28 03:32:16 UTC

Permalink

Post by Stephen Hansen

Post by Alain Ketterlin

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. :(

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.

Post by Alain Ketterlin
(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.

Post by Alain Ketterlin
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.

This might not be of much use to you, but I've found by experience that
PNGs are almost always bigger or equal to GIFs of the same resolution,
colour depth and so on. I've never yet seen a PNG file that is smaller
than a GIF for the same set of pixels.

As mentioned above, compressing raw data stream might be more beneficial
in this situation.

Also try the pngcrush utility and see what size it gives you.
http://pmt.sourceforge.net/pngcrush/

--
Harishankar (http://harishankar.org http://literaryforums.org)

Chris Colbert

2010-03-28 05:21:18 UTC

Permalink

since the images only use a couple colors each, just run length encode it.
Depending on the image, you may be able to get a super small size that way,
and avoid the whole mess.

Post by Harishankar