Getting the Most Out of PNG

Jeff, this is your colleague from work, Will. To say “you should always choose PNG over GIF” you are leaving out the biggest exception to that rule. Yes, they are smaller. Yes, they look better. But every time I try to build a Web page where I use PNGs exclusively, I inevitably have to revert back to GIFs in many cases and not just because of the lack of 24-bit transparency support in IE6. Usually, it’s because if you create a PNG containing a specific color (e.g. #cf3dc4) and you position it next to or on top of a DIV or TD or whatever background with said color, you see two totally different colors. Ok, maybe not “totally different” but noticeable enough to the naked eye. So, I would back off your statement a bit. For now, except for basic sites, the world is not quite ready for 100% PNGs.

Usually, it’s because if you create a PNG containing a specific color (e.g. #cf3dc4) and you position it next to or on top of a DIV or TD or whatever background with said color, you see two totally different colors.

This issue has already been discuted in the comment thread, the Gamma chunk makes MSIE go bonkers, you just have to remove it, which pretty much every PNG optimizer does…

Worthy of note is what Macromedia appended to the PNG format when they introduced Fireworks (now owned by Adobe). The PNG file format is the native Fireworks format and it supports pretty much anything you’d find in an illustrator or photoshop file. Of course, if you open those PNGs in a non-Adobe application, you’ll get the flat image, but now that Adobe owns the enhanced PNG format, it seems plausible that PNG may become the universal graphics format - sort of like PDF, but instead of having everything flattened and protected from editing, enhanced PDF will basically hold whatever layers, bitmaps , vectors, text, etc. you happen to embed in it without losing editability. I’d watch the PDF format very closely over the next few years to see what Adobe does with it.

Erik: the reason you’re seeing an increase in file size when converting to PNG is is only partly due to JPEG artefacts making life harder for the PNG compressor. The real reason is because JPEG is a 24-bit format and thus, in your conversion, you’re generating a 24-bit PNG. Like GIF, PNG can also be saved with an 8-bit colour space, which will yield much better compression.

I took your image into Photoshop and saved (in the Save for Web dialog) it as 8-bit PNG with 32 colours (you can play around with this setting to see what looks good). This took it down to 51,973 bytes (50.7 KB). I ran it through PNGOut using brute force compression and squeezed it down to 47,669 bytes (46.5 KB). That’s a 54% saving. You can view the result here:

http://img412.imageshack.us/img412/1294/pennyarcadedz5.png

The fact that it was JPEG did mess things up a little: take a close look a some of the areas of flat colour, especially where dark lines meet lighter colours (the browns especially). See the random pixels of a different colour? This decreases the performance of the PNG compressor and also looks bad to the keen eye. It’s easy to solve, though: just save the file directly from Illustrator (or whatever) as an 8-bit PNG then compress using PNGOut.

Forgot to say: all of this talk of image compression reminds me of the early days of web design, where knowing how to squeeze the last drop of compression out of your images was like today’s equivalent to knowing your web standards and CSS inside out; it was utterly essential knowledge. Anyone remember using DeBabelizer? Photoshop didn’t have any web optimization and output options at the time, I don’t think it could even export to GIF. Ah, the good ol’ days. :slight_smile:

Jeff:
I created a BMP of a web-site using SnagIt. Used Paint to transform the BMP into GIF, JPEG and PNG.
Here are the file sizes:
*.bmp - 1407 KB
*.jpg - 171 KB
*.png - 57 KB
*.gif - 51 KB
Did I do something wrong? Does Paint suck? (Well, I know that but still)

Sam

Paint is not the best at PNG compression (in fact probably the worst).

SammyB:

Have a look at your gif image! It has been converted down to 256 colors (using the worst approach possible by the way), whilst the png image is true color (24 bit).

Although Paint doesn’t bother to try optimizing png images at all, you get a really lossless compressed image for only 10% more file size (compared to gif). Additionally, if you run pngout on this file, it will most likely come out smaller than the gif image.

And to put this in perspective; if your file is so small that gif might actually be smaller than png, you’re probably better off shortening your urls and stripping HTTP-headers from the requests

This isn’t strictly true. I tend to still use gifs for small navigation elements with javascript rollovers. If you have 10 navigation elements (plus 10 rollover states), each (as a .gif) is about 100-200k. Tiny .png’s like this are usually more than double the size. This makes a reasonable difference when the browser is preloading them and trying to show rollovers to the viewer almost immediately.

Daniel:
I thought the trend was rather to use CSS and positioning to apply rollover effects? It circumvents the issue of having to preload resources.

@DanielT In that case HTTP probably has a larger bandwidth overhead than the individual image files - which is why we use PNG sprite maps. Regardless of what format you choose, one set of image headers is always smaller than 2.

299 rss-feed.gif
254 podcast.gif
553 total

339 rss-feed.png
265 podcast.png
604 total

550 rss-podc.png

Check out Pixelformer http://www.qualibyte.com/pixelformer/. It is mostly an icon/bitmap editor (though it is not as simple as you may think), but also has a nice “multipass optimization” option for saving PNG’s and Vista icons (which are also PNG-compressed).

Performs at least as well as OptiPNG and PNGCrush (sometimes even better). In most cases (not always) can be slightly beaten by PNGOUT, but works much faster and offers a couple of other useful features.

Kurt, why would anyone care about any version of IE prior to 6? They’re ancient, nobody uses them, they’re statistical noise in weblogs.

As a web designer this is an attitude I come across constantly and have never understood. As of 2009, IE6 holds a 15.4% share of the browser market. Who cares right? Well I care for one if my website looks ugly to nearly 6 million people in the UK alone (based on the 2006 UK Internet user count of 38,512,837 according to Nielsen Ner//Ratings), and that doesn’t include older versions of IE either.

I would like to try explaining to my clients why 6 million people can’t see their site properly. Christ knows how many people that translates to in the US!

Whilst the PNG file compression may be lossless this doesn’t preclude any of the above-mentioned “compression” programs from performing lossy optimisation techniques (e.g. a high pass filters, etc.) between decoding and re-encoding the image data.

@HEXtaC This is true, however these compression programs have options to do either lossy or lossless.

It’s also useful to note that many people first assume GIF to compress better because they store full-color RGB images as GIF’s and PNGs and compare the two. Since GIF is 256-color only; this is a lossy compression (though usually a fine option since it doesn’t reduce sharpness) and has the unsurprising size benefits you’ld expect from lossy compression.

To compare GIF to PNG fairly; you’ll need to manually convert to 256-color mode before storing the image. This conversion presents you with a choice of palette and dithering options which affect size. It’s an obvious step; but I still see people forgetting it rather often. Photoshop has a handy “Save for Web” function which allows you to play with the different options to gauge their respective impact.

And to put this in perspective; if your file is so small that gif might actually be smaller than png, you’re probably better off shortening your urls and stripping HTTP-headers from the requests which generate the images to save bytes than you are bothering with the image. You could even consider using the data: uri scheme if you don’t care about IE support.

Jeff,

One other issue is that IE6 does not handle the full Gamut of PNGs correctly. PNGs can display with different colours when comparing IE6 and FF. For that reason alone, many people go back to using GIFs after dipping their toes into PNGs and find they “just don’t display the right colours”.

And why would you care? That all depends on who owns the site, and what they may be selling.

– JJ

Looks like there is a new contender with Google’s zopfli compressor (it’s backwards compatible):

http://encode.ru/threads/2176-Zopfli-amp-ZopfliPNG-KrzYmod

Beware though on large images because as the Wikipedia entry notes:

:warning: the output of Zopfli is typically 3–8% smaller than zlib’s maximum compression, but takes around 80 times longer

I downloaded it to test on a few random PNGs and this is the first tool I’ve ever seen that reliably produced significantly smaller PNGs than pngout! So hooray! Just beware that 80x compression time penalty…

Also, I would avoid lossy PNG “compressors”. I really don’t recommend lossy PNG:

While it is true you can safely reduce the # of colors (to 256, or 64, or 32) in some images where only a few colors are represented in the image, you should test that by hand rather than trusting a lossy compressor IMO.

1 Like

Ken Silverman was an “optimize the heck out of everything” old-style programmer. He violated all the rules of “don’t optimize”. You can find the original Duke Nukem3d code on the web, and you can see how he made it run fast in the days before floating point processors—he wrote his own floating point arithmetic software that was faster (though less accurate) than the standard. It was kind of fun to look through that C code (with lots of assembly thrown in to make it hard to read) and see how Duke ticks. He violated DYR too: for every common architecture that duke3d ran on, he had a separate floating point library optimized to it. We had some programmers like that at work—their code ran very fast, was often incomprehensible, and if there was a bug (“but I PROVED it correct!” was a common reply) only they could fix it. (One time, the guy proved it correct based on the processor’s documentation, which was itself incorrect. That’s why we test!)

One consequence----there is a bug that lives on in the latest eduke32.exe version of Duke Nukem 3d: in one level (the Star Trek Enterprise) is a nuclear reactor behind glass with spinning…somethingorother that’s supposed to be uranium or something and a health pickup on top. When you actually go through all the tunnels and get to it, the pickup is no longer there. Why? The rotation computation was inaccurate so, slowly, the pickup increased its radius from the central axle and by the time you reach it, the pickup has left the space of the level and is in no man’s land. I submitted the bug report to the eduke32 team but it’s “wont fix” because the original duke3d.exe had it and it obviously did well.

1 Like

PNGOut is like it is said the best out of all the single programs I have used. I use PNGGauntlet too ,with OptiPNG and DeflOpt turned off, since they make the process much longer and the gained size is insignificant. PNG Optimizer though is what I use the most, since it is faster than PNGOut. In the

I did a test on a batch if 15000 pictures which though a lot were small. The results are under and I added the size on disk, just cause it is on the info tab :stuck_out_tongue:

Original
Size of files: 397 MB (417,167,186 bytes)
Size on disk: 428 MB (449,069,056 bytes)

PNG Optimizer - 37 minutes
Size of files: 288 MB (303,028,157 bytes)
Size on disk: 326 MB (342,130,688 bytes)

PNGOut - 50 minutes
Size of files: 314 MB (329,867,863 bytes)
Size on disk: 351 MB (368,250,880 bytes)

Again, the pictures were tiny, but as you see PNG Optimizer was better than PNGOut. In larger pictures I have tested, PNG Optimizer is indeed much much much faster, but PNGOut gives a better compression.

If I want the absolute tiniest lossless PNG I can get, I use FileOptimizer, with it’s PNG settings being to lossless (I untick the lossy option). FileOptimizer is the best when it comes to size and probably the slowest. After checked it’s running processes it seems it run the following optimizers, in order; PNGOptimizer, TruePNG, ECT, PNGOut, OptiPNG(this takes the longest), Leanify, pngwolf, pngrewrite, advpng, DeflOpt, defluff and once more DeflOpt. I wish I could turn off OptiPNG since like in PNGGauntlet it makes the process 20 times slower (literally) and it rarely is worth of the wait. From a test on a larger file, the times were like this;

PNGOptimizer 2 seconds
TruePNG 34 seconds
ECT 0.5 seconds
PNGOut 14 seconds
OptiPNG 2 minutes 23 seconds
Leanify 1 minute 6 seconds (it did make it ever so slightly smaller)
pngwolf 37 seconds
pngrewrite 0.5 seconds
advpng 17 seconds
DeflOpt+defluff+DeflOpt in the end took together 2 seconds

FileOptimizer is definitely the best Lossless, but also lossy PNG Optimizer. For lossy, it gives equal results with sites like my favorite Compress PNG site. Sadly though OptiPNG makes the process so lengthy, that for me it is better to upload it there and instead XD