Recompressing PNG files to shrink install package
Moderator: Forum Moderators
Recompressing PNG files to shrink install package
I tried PNGOUT to recompress files in wesnoth and got some file size decrease, for example:
mud-glob.png
Original: 1049 bytes
After recompression: 951 bytes
Try!
mud-glob.png
Original: 1049 bytes
After recompression: 951 bytes
Try!
- Attachments
-
- File after recompression
- mud-glob.png (951 Bytes) Viewed 4911 times
I believe the way pngout works is to compress the data in the png files with a zlib compression level that optimizes space at the expense of time to decompress. In short, though this makes the files smaller, it may also make them take longer to load.
I don't think this is generally worth doing for files that are stored on one's hard drive -- though it is worth doing for files on a web page. If the aim is to make the distribution package smaller for downloading, then I think it would be better to just make the package compressed with aggressive compression.
David
I don't think this is generally worth doing for files that are stored on one's hard drive -- though it is worth doing for files on a web page. If the aim is to make the distribution package smaller for downloading, then I think it would be better to just make the package compressed with aggressive compression.
David
“At Gambling, the deadly sin is to mistake bad play for bad luck.” -- Ian Fleming

Better idea: Do what I've established as a policy for my images, which I usually follow when committing them (aka, always unless I forget).
First, I save them with GraphicConverter, with settings to strip most of the metadata (including the gamma setting, which wesnoth completely ignores - this gamma setting was the culprit that made a number of my images which looked fine in-game look washed out on the web). GraphicConverter is also set to use the adaptive PNG filtering settings defined as part of the standard - this can shave a few KB off of an image.
Finally, I drop it into PNGCrush, which apparently does something completely different from the PNG filtering, something complimentary.
This isn't worth going back and applying to all images by any means, but it does mean that all images I add in the future will be smaller than they would be by simply running PNGCrush on them.
Isaac runs pngcrush on all images. 1049 bytes is the smallest it will do for that image (though I got 1048 by using -brute). Jetryl's semantic cleanups are likely to yield a larger increase, but it might be worth looking at other compression techniques.
However, the statement at http://jonof.edgenetwork.org/ did not instil great confidence in me. Closed source compression has a history of being broken.
However, the statement
Code: Select all
NOTE: The source code to PNGOUT is not being made public at this time.
This quote is not attributable to Antoine de Saint-Exupéry.
Theyre is also pngrewrite here
http://entropymine.com/jason/pngrewrite/
http://entropymine.com/jason/pngrewrite/
-
- Posts: 10
- Joined: September 12th, 2005, 11:36 am
- Location: Dubna, Russia
Thanks a lot! Some more fat stripped from this tiny mud bloblwa wrote:Theyre is also pngrewrite here
http://entropymine.com/jason/pngrewrite/

862 bytes now (orig. 1049) => 17% off... Not bad!
- Attachments
-
- mud-rewrite.png (862 Bytes) Viewed 4734 times
-
- Posts: 10
- Joined: September 12th, 2005, 11:36 am
- Location: Dubna, Russia
Problem: for elvish-captain-leading.png it says This image can't be converted because it has more than 256 colors. So ideal procedure should be "1) try to compress with pngrewrite, 2) if fails - compress with optipng or pngcrush"lwa wrote:Sound to be no convertion problems.
When I convert this mud images to CMYKA raw format with imagemagick, they are the identical to the original.
I can make a batch to test this on the full image collection if developpers are interested by.
Example script:
Code: Select all
#!/bin/bash
rm opt.*.png # remove old files
for file in `ls *.png`
do
rewrite=`pngrewrite $file opt.$file 2>&1` # trying pngrewrite first
if [[ $rewrite = *"can't be converted"* ]]
then
test=`pngcrush $file opt.$file` # using pngcrush on others
fi
done
I've passed the images direrectory with the script below then
compared the size of a gzipped tar (with best compression)
Before: 20326400 bytes
After: 19886080 bytes
With pngrewrite only: 19927040 bytes
With pngcrush only: 20285440 bytes
You only save 440KB (2.2%) using both. Searching inside the images, I noticed that some containt comments (made by the gimp or adobe)
About half of the images can't be passed by pngrewrite because
theyre large color number. On elvish-captain-leading.png, for example, 149 of 283 colors are used by one pixel only. But I'm unsure the job to to do reduce them worth the saved bytes.
compared the size of a gzipped tar (with best compression)
Before: 20326400 bytes
After: 19886080 bytes
With pngrewrite only: 19927040 bytes
With pngcrush only: 20285440 bytes
You only save 440KB (2.2%) using both. Searching inside the images, I noticed that some containt comments (made by the gimp or adobe)
About half of the images can't be passed by pngrewrite because
theyre large color number. On elvish-captain-leading.png, for example, 149 of 283 colors are used by one pixel only. But I'm unsure the job to to do reduce them worth the saved bytes.
Code: Select all
#! /bin/sh
src=/usr/X11R6/share/wesnoth/images
dst=$HOME/tmp/images
cd $src || exit 1;
find . | while read path
do
if test -d "$path"
then
mkdir -p "$dst/$path"
else
case $path in
*.png)
pngrewrite "$path" "$dst/$path"
test -e "$dst/$path" || pngcrush "$path" "$dst/$path"
test -e "$dst/$path" || cp -p "$path" "$dst/$path"
;;
*) cp -p "$path" "$dst/$path" ;;
esac
fi
done