Brendan Lally wrote:
> On 3/27/06, Mark Wedel <[EMAIL PROTECTED]> 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.
_______________________________________________
crossfire mailing list
[email protected]
http://mailman.metalforge.org/mailman/listinfo/crossfire
