GIF89A and PIL

[Chris Colbert]

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.

On Sat, Mar 27, 2010 at 11:32 PM, Harishankar <v.harishankar at gmail.com>wrote:

> On Sat, 27 Mar 2010 19:44:54 -0700, Stephen Hansen wrote:
>
> > 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.
>
> 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)
> --
> http://mail.python.org/mailman/listinfo/python-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20100328/74aa2ecd/attachment.html>