In response to Conrad Chu’s comment from my previous blog posting (thanks for taking the time to comment, Conrad), I thought I would share a specific example of .png optimization related to punypng and PNGSlim. Conrad had asked me to share a concrete example to illustrate my “In my experimentation with the two tools, punypng has consistently only taken about half of the excess file size out of the typical .png image as PNGSlim has” comment from yesterday’s post…so since he was so gracious in commenting on my post, I wanted to quickly provide such an example.

For this experiment, I used the W3C.org validation service to check the status of my mapping firm’s home page at mapformation.com. We passed (whew), albeit with three warnings. W3C subsequently provided links to two .png files that I could post on that home page if I chose to:

Unoptimized 88×31 pixel .png graphic – 1,542 bytes

Optimized 88×31 pixel .png graphic using punypng – 1,446 bytes

Optimized 88×31 pixel .png graphic using PNGSlim – 1,267 bytes

Unoptimized 88×31 pixel .png graphic – 1,669 bytes

Optimized 88×31 pixel .png graphic using punypng – 1,605 bytes

Optimized 88×31 pixel .png graphic using PNGSlim – 1,417 bytes

Optimizing those two images from originals using punypng took 3,211 bytes of imagery and reduced them to 3,051 bytes in cumulative size, an improvement of just under five percent! Optimizing those same two unoptimized original images using PNGSlim took 3,211 bytes of imagery and reduced them to 2,684 bytes, an improvement of roughly 16.5 percent.

Conrad is absolutely correct when he says that one of the bigger drawbacks to PNGSlim is that it can be s-l-o-w…particularly when it is processing .png images with large file dimensions! Its speed has improved from what it used to be, but a LOT more improvement could still be made in that area. What I like about PNGSlim though is it can also be running in the background while I am doing other tasks, so it’s not really that big of a deal to me if it takes an extra 10 seconds here, 20 seconds there. For PNGSlim to be widely adopted as a potential .png optimization “standard” though, more work to improve the tool’s speed is most-definitely needed.

Thanks Conrad! I hope this subsequent post helps. Also, if you ever need anyone to help test-drive that “Professional” version of punypng down the road, just let me know. I’d be happy to help and give you as much feedback and ideas as I can.

Posted by datonn on Friday, October 30th, 2009 at 10:04 pm.