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.harishan...@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.shan...@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 >
-- http://mail.python.org/mailman/listinfo/python-list
