Running optipng (http://optipng.sourceforge.net/) on the tree yields some savings (~115615 bytes for paths that don't have '/(ref)test' in them when using -o7). Even though the gain isn't much, we should do this. Attached is the (slightly mangled) output from my run with files and their results. I'm not sure we want to run this on test images, but probably wouldn't hurt (?).

https://bugzilla.mozilla.org/attachment.cgi?id=521135 contains an Archive from the other Report.

OptiPNG is a very valuable tool, but you'll usually get better results using PNGOUT (command line and free version of PNGOUTWin) followed by DeflOpt. The punypng site also provides an online optimization tool. There are some scripts like pngslim that make heavy use (hundreds of random runs) of these tools. I have developed CryoPNG which is a kind of preprocessing tool for RVB+Alpha PNG files since it replaces fully transparent pixels by a value that will be zeroed once the line is filtered (and not before as most "dirty transparency" enabled optimizers do by just putting black pixels). PNGOUTWin (GUI Windows): http://www.ardfry.com/pngoutwin/ PNGOUT (command line for Windows): http://www.advsys.net/ken/utils.htm PNGOUT (command line for Linux, Mac OS X, FreeBSD): http://www.jonof.id.au/kenutils PNGOUT tutorial: http://www.advsys.net/ken/util/pngout.htm DeflOpt (command line Windows): http://www.walbeehm.com/download/ (can be run on Linux using Wine) pngslim (command line Windows, drag and drop) http://people.bath.ac.uk/ea2aced/tech/png/pngslim.zip (works better under XP since pngoptimizercl is buggy under Vista and 7) PunyPNG (online service): http://punypng.com/ CryoPNG (still experimental, ask me if you want to give it a run). Anyhow if the Mozilla team would like to use extremely optimized PNG files I could produce them.

Here are two examples of what can be achieved: /browser/themes/gnomestripe/browser/Geolocation-64.png Size : software used to optimize 8056 original 8056 optipng 8035 optipng + deflopt 7842 pngout + deflopt (custom "mad" script) 7710 cryopng + pngout + deflopt (custom "cryogenx" script) /browser/themes/gnomestripe/browser/Privacy-64.png Size : software used to optimize 4828 original 4827 optipng 4755 optipng + deflopt 4589 pngout + deflopt (custom "mad" script) 4234 cryopng + pngout + deflopt (custom "cryogenx" script)

Please notice that the following files are actually APNG files (animated throbbers) and not standard PNG files. ./browser/themes/gnomestripe/browser/tabbrowser/loading.png ./browser/themes/gnomestripe/browser/tabbrowser/connecting.png ./browser/themes/gnomestripe/browser/places/searching_16.png ./browser/themes/gnomestripe/browser/sync-24-throbber.png ./browser/themes/gnomestripe/browser/sync-16-throbber.png ./browser/themes/winstripe/browser/tabbrowser/loading.png ./browser/themes/winstripe/browser/tabbrowser/connecting.png ./browser/themes/winstripe/browser/sync-throbber.png ./browser/themes/winstripe/browser/places/searching_16.png ./browser/themes/winstripe/browser/places/searching_16-aero.png ./browser/themes/pinstripe/browser/tabbrowser/loading.png ./browser/themes/pinstripe/browser/tabbrowser/connecting.png ./browser/themes/pinstripe/browser/sync-throbber.png ./browser/themes/pinstripe/browser/places/searching_16.png

Once stored in a zip archive I get: 1184175 original-pngs.zip 1027477 cryopngx-optimized-pngs.zip cryopngx-optimized-pngs.zip is available here for at least 30 days: http://dl.free.fr/nKRpaYpCf

Frédéric thanks for you work, I think the reasonable thing to do here is to submit bugs specifically about the biggest png files(ie about-background.png) to get them replaced with more efficient versions.

I submitted Bug 653001 let me know if it's okay this way.

Actually, I'd like to avoid having lots of bugs for specific image tweaks. Through I'll take a few if there's work on a better system... Might be worth discussing this on the newsgroups, but I think we should have an automated way of doing this. For example: 1) Put tools into the tree (or make them build dependencies), and have one of the build / package steps do this 2) Same, but do this over in releng instead of in-tree 3) Add an hg commit hook to reject non-optimized images (under theme/ at least) A good first step would be to get an in-tree script that someone can run to generate a patch for optimized images. Then the paranoid among us can avoid worrying about other image changes slipping into giant 3rd party patches. :)

Another one: Bug 653038, this image appears twice in the Windows version, maybe there's something to do at this level, like a "common" folder for files that belong to both skins (aero and non-aero). Submitting images one by one is such a hassle... I'll stop it for now.

If icons are the same for both Aero and non-Aero Windows, then a single image in the tree is sufficient, with the appropriate jar.mn magic to refer to the same image in both flavors.

(In reply to Justin Dolske [:Dolske] from comment #11) > 1) Put tools into the tree (or make them build dependencies), and have one > of the build / package steps do this > 2) Same, but do this over in releng instead of in-tree > 3) Add an hg commit hook to reject non-optimized images (under theme/ at > least) > > A good first step would be to get an in-tree script that someone can run to > generate a patch for optimized images. Then the paranoid among us can avoid > worrying about other image changes slipping into giant 3rd party patches. :) I think those all sound like great ideas! I have been using ImageOptim for any new and updated images. It would be nice to have an automated way to reduce image size for all new images as well as a way to optimize images already in the tree.

as a side note, there are also a few PNG in data: URIs scattered around the tree: http://mxr.mozilla.org/mozilla-central/search?string=data:image/png