[crossfire] Indexed PNGS, was Re: Protocol & compression.

[Mark Wedel]

Brendan Lally wrote:
> On 3/27/06, Mark Wedel <mwedel at sonic.net> wrote:
>>   I just ran a quick test (find . -name "*.png" -exec gzip -vc {} > /dev/null
>> \;) , and this is a somewhat typical result of the entire arch tree:
>>
> <snip>
>>   Some files not compressible, some marginally compressible, and some very
>> compressible.

(the ones very compressible are indexed images, not RGB)

< Portion about Brendan using png crush to reduce image sizes somewhat deleted>

> Note however, that the images which most benefited from this are /not/
> the same ones that gzip seems to be able to compress well. (if anyone
> wants to try and recreate this, I used pngcrush -fix -l 9 with version
> 1.5.10) - I think this is something to do with palette utilisation in
> indexed images.

  Briefly looking over the pngcrush page, it seems what it really does is uses 
maximum (and not default) compression level, as well as delete portions of the 
PNG file not really needed (comments, etc).  It doesn't seem to actually change 
the form of the PNG - an indexed image will remain and indexed image.

  IMO, pngcrush may be of marginal value - next time someone loads up that PNG 
and does any work on it, when they save it out, it will go back to being at 
normal compression level and any fields removed might get added.

  But the question of whether to go through the arch try and convert any indexed 
images to RGB is still there.  My bet is that it is purely a factor of what 
format the editor used to create them was set to use, and not anything 
intentional (I'd have to look over the list - it could in fact be that the xpm 
-> png conversion used indexed images).  If no complaints, I'll look at doing 
this - have to see what tool(s) will work best to do so.