Getting the Most Out of PNG

I usually rely on PNGOptimizer ( ).

PNGOut is a little better (~3% to 5% better on most files with the default options), but PNGOptimizer is just much easier to use

To compare GIF to PNG fairly; you’ll need to manually convert to 256-color mode before storing the image.

That, or you just recompress your GIFs to PNGs, or you explicitely compress full-color images to PNG/8 instead of PNG/32.

Also, about PNGOut vs PNGOptimizer, PNGOptimizer sometimes compresses better than PNGOut, especially on images with very low numbers of colors (8-32).

The nice thing, though, is that PNGOut doesn’t overwrite files it can’t compress any further, so applying PNGOptimizer then PNGOut may yield the best of both worlds.

PNG Alpha opacity in IE 5.5+ :

You know that one browser that has only a vague association with modern web standards? Yeah, Internet Explorer. Wouldn’t it be great if it supported stuff like translucent PNGs?

Well, now you can add decent PNG support to IE5.5+ on Windows with no changes to your website HTML source code. This script will add near-native PNG support with full alpha opacity, with only one line in your CSS file, that applies to all img tags and also background images!

“…between lossless GIF or lossless PNG…” I think you meant “lossy”.

Yow, quite a few misunderstandings and outright errors here. Starting at the bottom:

Erik Karulf, your image got bigger because you destroyed it by saving in JPEG in the first place. That’s what “lossy” means, and the kind of damage JPEG does is very hard on PNG’s compressor. Find the original and compress that instead.

Ozh, the color-mismatch problem in MSIE goes beyond just PNGs; MS happily ignores the gamma- and color-correction aspects of numerous standards, including HTML and CSS. See for a basic gamma test and the top of for the self-consistency argument.

Powerlord/Josh/rien/etc., neither PNG nor GIF’s compression engine is lossy, but GIF most assuredly is lossy (due to quantization) if you try to save a truecolor (24-bit) image. I suspect that’s what the original poster meant. It’s fully lossless for images with 256 or fewer colors, of course.

John, IE 5.x can display PNGs (as can 4.01+); it just doesn’t handle transparency correctly (GIF-style only; not at all for 32-bit PNGs). There are virtually no browsers in use today that can’t display basic PNGs OK.

Dave C, emacsen, et al.: neither PNG nor GIF (as formats) is copyrighted, nor (if I understand US law correctly) can they be, since they’re not “expressive.” The specs are copyrighted, but that doesn’t stop anyone from implementing the formats according to the specs. GIF was encumbered by the Unisys LZW patent; it may still be encumbered by the IBM LZW patent; and the “GIF” name is a service mark of CompuServe. PNG is believed to be unencumbered by any patents, but you can never make a blanket statement without doing an exhaustive search. I think that covers most of the legal issues…

Guy, there are no current plans (that I’m aware of) to support APNG in libpng. The APNG extension chunks have just come up for discussion (and perhaps a subsequent vote) on the PNG/MNG list.

GrahamStw, make sure you’re comparing 8-bit PNG to (8-bit) GIF. (Eamon Nerbonne made the same point above. Use something like gif2png to convert the GIFs to PNGs before running pngcrush if you want to be sure, or just do pngcheck *.png to make sure they say “8-bit” and not “24-bit”.) There are a few GIFs that PNG can’t beat–usually either extremely tiny ones or ones with between 17 and 64 colors–but the vast majority are smaller with PNG. Of course, if you’re storing a lot of ancillary crap in there–e.g., large text chunks, full ICC profiles, etc.–then all bets are off. (Use pngcheck -v *.png to see what’s inside them.)

Oh yes, one more thing: I wrote that PNG is believed to be unencumbered by patents, but that’s imprecise; what I should have said is that it is believed that PNG can be implemented in a manner unencumbered by patents. This is a key distinction, particularly in light of PNGOUT. The core deflate engine used by most PNG implementations (or its ancestor, technically) used to be noticeably better, too…but then the author discovered that he had unintentionally infringed on a patent (Fiala-Green, IIRC), so he rewrote it to avoid the patent. Nor was that the only instance of having to work around patent potholes; there are many of them covering various aspects of the LZ77 space.

Obviously I don’t know anything about the guts of PNGOUT (or KZIP), but I’d bet a fair piece of cash that it touches one or more patents. It’s not that I believe Ken did so intentionally, only that I know how much of an effort Jean-loup made to avoid doing so, and I suspect Ken was far more interested in coding than in perusing a bunch of intentionally obfuscated legalese. (Hell, even patent examiners aren’t very good at it, or they wouldn’t have granted the same patent to both Unisys and IBM.)

Just a guess, of course. I have no direct evidence, and I would be outstandingly happy to be proved wrong… But having been in the business for a couple of decades, that’s not where the smart money is.

GIF has no copyright issues, it was patented, but its patent expired so now there are no more legal issues anymore to using GIF. PNG and GIF algorithms are not copyrightable anyway. Particular implementations might be.

I tend to use pngcrush and I don’t think I’ve ever seen an image that was smaller as a GIF. Do you have an example or can you give us some idea where you think the cut off point is Jeff?

As for IE support: this is the most often cited reason why people don’t use PNG. However it is only one aspect that is borked: alpha-transparency support. The rest works fine, including single colour transparency (like GIF), and there are well known fixes for alpha-transparency on pre-IE7 (the wikipedia page has some helpful links).

Actually, I believe PNG does support animation/multiple frames, but FireFox IE just ignore the extra frames. There’s apparently code for FF 3 that will handle PNG animations.

JJ, if my understanding is correct then this difference is due to variations in the way that Gamma Correction is applied to PNG files. GIF doesn’t have any gamma correction, so it doesn’t suffer this problem.

One simple solution is to simply remove gamma correction from the PNG file. You can do this with the command: “pngcrush -rem gAMA”.

If I’m working with the kind of small decorative images that must match up exactly with adjoining CSS colours and other images then I want the file sizes to be as small as possible. So I will usually have removed gAMA and all other ancillary chunks with the “pngcrush -rem alla” command anyway.

Note that there is or was an animated counterpart to PNG called MNG. As a format, it rocks. There is no decent, open, modern lossless traditional bitmapped animation format other than .mng.

However, it is not supported by either major browser. Sigh.

PNG rocks. However, if you think that progressive images have no benefit, you haven’t been stuck on a 56k recently :frowning:

Being able to decide quickly whether I should wait for the rest of the image to load or can go about my business is sometimes invaluable, regardless of whether it slows the overall load time of the page. This is true even for images that were initially thumbnailed - often you can tell whether it was what you were actually interested in from the miniscule thumbnail after it has loaded even the first blurry image.

How about PNGCrush?

PNG is not copyright-free. The implementations of PNG are not in the public domain.

PNG is not patent encumbered.

There is an important distinction there, and you should consider correcting the blog entry.

Progressive loading of images is very important over slower connections as it allows the user to decide if they want to continue loading of images before the entire image is downloaded. It also just looks cooler:)

apng will be more likely to succeed over mng. mng support and continued development has been lacking. It also requires the inclusion of a completely separate rendering library that duplicates much of pngs library. This is the same thing that has hampered continued jpeg development. apng is actually being incorporated into some standard png libraries so it will be supported by png natively. This is as it should be.

As emacsen says in the comment above, PNG is not copyright free. There are no copyright “issues” with PNG or for that matter with GIF.

The PNG format was, if I’m remember this rightly, created in response to a patent on the GIF format that Unisys began to enforce in the mid-90s after the web became popular. The patent expired, in the US, on June 30, 2003. Patents in other countries expired on various dates in 2004. According to the Unisys website “Unisys Corporation holds and has patents pending on a number of improvements on the inventions claimed in the above-expired patents.”

PNG is unencumbered by patents, pending or otherwise.

pngquant is another good tool I use for PNG optimization. I use it to force PNG/32 files down to PNG/8–more often than not I cannot tell a difference.

You know, I make a good number of my images into JPEG rather than PNG even when I have large swaths of color. Why? Because I don’t care about lossy images. The more lossy my image is, the less likely someone else is to borrow it without my permission.

There’s also the fact that, well, the JPEGs tend to come out smaller and I don’t have to give a crap about using programs. I have used PNGcrush and PNGOUT and a few others and I have IrfanView on my system. And I still don’t care. I know how to do it, but I use Photobucket for image hosting so its not my bandwidth.

In fact, there are so many 3rd party solutions, I don’t host anything anymore. I have blogs with Blogger. I have a personal page with LiveJournal. I have a page to host my art with and I don’t really need my own forum because internet forums inevitably breed drama. It’s easier to walk away from someone else’s forum than it is to walk away from your own.

I’ve successfully stopped giving a crap about having my own domain.

And here I thought I was ahead of the game by compressing with OptiPNG (code-o7/code). Apparently they aren’t quite as strong as PNGOut. On my directory of PNG logos, I have the following.

After OptiPNG: 2'534'962b
After PNGOut:  2'316'540b (91.4% of original)

Thanks for the heads up. And great series of articles: I’ve been trying to tweak my blog performance lately.

Great series this week.

The lack of transparency support in PNGs on IE6 is one to be aware of. My blog looks like crap in IE6 because of I have lots of small icons that are transparent PNGs when I should have made them transparent GIFs.

The number of people still using IE versions prior to 6 are not quite “statistical noise” yet.

According to the browser statistics shown at, IE5.x still commands 2.5% of users. (Granted, I’d expect that to be lower for a tech-savvy audience such as this one.)

So, before using PNG on a general purpose or consumer site, it’s good to consider how big a deal it is if around 2 or 3 out of every hundred visitors can’t see the site’s images at all.