When it comes to image formats on the internet, it's generally a three-way tie between JPEG, GIF, and PNG. Deciding which image format to use is relatively straightforward; you choose lossy JPEG when you're saving continuous-tone photographic images, and you choose between lossless GIF or lossless PNG when you're saving images with large blocks of the same or similar colors. See my comparison of GIF/PNG and JPEG if you're not clear on what the difference is. But the choice between GIF and PNG is no contest. PNG is a more modern and vastly improved version of GIF that (almost) completely obsoletes it. You should always choose PNG over GIF, except in the following two circumstances:
In every other way, PNG is the natural heir to GIF. It's copyright-free, it can store all bit depths, it can represent alpha channels, and it offers more efficient compression. But as great as PNG is, there are a few things you should know about PNG to get the most out of it.
Let's start with a representative image. I took a quick screenshot of this website, along with all the browser chrome, transparency, and shadows. ClearType font rendering is on, and there's a nice mix of text, graphics, and UI. It's a perfect candidate for the lossless PNG file format, because there are large areas of the same colors and hard transitions between them. We want nice, crisp transitions between the white and dark areas of the screenshot.
The actual size of the screenshot is 1233 x 946. When I save this file directly from Paint Shop Pro as a 24-bit PNG file, I get the following file sizes:
| PNG, interlaced | 288 KB |
| PNG, non-interlaced | 212 KB |
So here's our first lesson: never save interlaced PNG files.
212 KB is an impressively small filesize for such a large and detailed image. It's a testament to the efficiency of the PNG image format. But we can do better. If we run Ken Silverman's PNGOUT* on the files, we can crunch them down even smaller:
| PNG, interlaced | 190 KB |
| PNG, non-interlaced | 190 KB |
First, note that PNGOUT strips out any interlacing. If you have interlaced PNG images, you can expect a very substantial reduction in file size. But even without interlacing, PNGOUT reduces the file size by 22 KB, or nearly 10 percent. I know it doesn't sound like much, but PNG is by definition lossless compression. JPEG is lossy, so as file sizes decrease, more and more of the image is lost. With PNG, we haven't lost any detail in our images, we've just made them smaller. Folks, this is free bandwidth! It doesn't get much better than that.
To see how effective PNGOUT really is, I ran it on a subset of my /images folder. The trick here is that these images are already optimized; I run OptiPNG on every file in this folder periodically.
| OptiPNG | PNGOUT | |
| 267 PNG files | 4.40 MB | 4.04 MB |
It took a while to run, but we get a further 9% reduction in PNG image size beyond what OptiPNG could do. How is this possible?
I thought the name Ken Silverman sounded familiar. Ken, the author of PNGOUT, is the wunderkind behind the original Duke Nukem 3D build rendering engine, which he wrote at the age of 18.
Ken is so good, even John Carmack-- the author of Doom and Quake, who is widely regarded as a programming god-- respects him. No wonder his little PNG optimizer decimates all the other ones. Always bet on Duke.
If you're running a website of any size, and you use PNG images in any quantity, you should run them through PNGOUT to reduce their size. PNGOUT can also convert your existing GIF images to the superior PNG format along the way. And it's so easy to do; here's the Windows command prompt syntax to optimize all PNG images in a folder:
for %i in (*.png) do pngout "%i" /y
The PNGOUT optimization process isn't particularly speedy, but it hardly matters. This one-time optimization could reduce your image bandwidth usage from 10 to 30 percent. That's an offer I can't refuse.
(* thanks to Kevin Breitenstein for pointing this out to me)
Note some problems with colour profiles embedded in PNGs on Safari:
http://blogs.smugmug.com/onethumb/2007/02/14/this-is-your-mac-on-drugs/
Great article! pngout sounds very useful.
Cheers,
Tim
You should check out PNGGauntlet (http://brh.numbera.com/software/pnggauntlet/ ) - it's a GUI wrapper for PNGOUT. I'll be releasing a .NET 2.0 version soon.
Ben Hollis on March 7, 2007 10:59 AMThere's one little thing with pngout that might bite you. It removes gamma correction by default - so the images that uses gamma correction will look differently than the originals. You can tell it to keep the gamma correction for PNGs that needs it.
everling on March 7, 2007 11:09 AMIrfanview provides a GUI for PNGOUT.
everling on March 7, 2007 11:11 AMHow does PNGOUT compare to PNGCrush (http://pmt.sourceforge.net/pngcrush/ )? I've always used the latter, and it seems to offer pretty good results.
/b/ on March 7, 2007 11:13 AM/b/: This is from the PNGOUT tutorial:
"If you are already be familiar with the pngcrush utility, you may be interested to know that PNGOUT can produce even smaller files than pngcrush -brute. With PNGOUT, however, you will need to find the right options yourself."
The options are listed here:
http://advsys.net/ken/util/pngout.htm
Jeff, I think there's a small typo in the CLI syntax that you posted.
It should be:
for %i in (*.png) do pngout "%i" /y
Great post, by the way! :)
Kunal Kundaje on March 7, 2007 11:27 AMOne negative aspect of PNG is it is not 100% compatible with all versions of IE on windows. This is such a large issue I would say it's mostly why it is not used more.
Kurt Moore on March 7, 2007 11:36 AMKurt, why would anyone care about any version of IE prior to 6? They're ancient, nobody uses them, they're statistical noise in weblogs.
The only PNG issue with current versions of IE is that IE6 does not support PNG transparency:
http://homepage.ntlworld.com/bobosola/pngtest.htm
.. whereas IE7 does.
Jeff Atwood on March 7, 2007 11:50 AMJeff, which screen capture software do you use? Thanks.
bowkrk on March 8, 2007 1:04 AMI'm so glad you talked about PNGOUT, most people never even consider it when discussing shrinking PNG's.
Ken also has his own program PNGOUTWin that gives a GUI for PNGOUT. It costs a little bit of money, but for someone who compresses hundreds of image files it is very helpful.
I think we should stop saying "Major browsers don't support PNG alpha", because browsers is plural and the only browser not to support it is Internet Explorer (excluding of course 7).
Lachlan McDonald on March 8, 2007 1:19 AMSo now that your listed on the Google Portal Technology section, is every post from now on going to be about shaving bytes from bandwidth?
Here's another thought, use ASCII art. That's a huge bandwidth saving. ;)
Haacked on March 8, 2007 1:38 AMYou use Vista?!?!? WHY?
For a site with the name Coding Horror... maybe you deserve to use it ;) Just kidding..
Mike on March 8, 2007 1:48 AMThere's also PNGCRUSH (http://pmt.sourceforge.net/pngcrush/) and a fork of PNGCRUSH called OptiPNG (http://optipng.sourceforge.net/). Be interesting to see how these compare with PNGOUT.
MCM on March 8, 2007 2:13 AMThere's another annoying bug with PNG files within MSIE : colors are not correctly rendered. Example : body{background:#ddeffa} and body{background:url(bg.png)} (where bg.png is a plain one color image with color #ddeffa) are *not* the same with MSIE.
Typically, mixing PNG and JPG images with MSIE in a layout where you need background to blend correctly is a no-no.
Ozh on March 8, 2007 2:19 AMFor being such a graphics wiz I would think that Ken Silverman would have gotten out of the '90s style background. That is _hideous_!
Well, at least it is a 423 byte PNG file (utilback.png). He likes his PNG. :)
Wow. I never knew about PNG file size optimization. I'll be converting Penny Arcade's existing png's ASAP.
If someone has any brilliant ideas about image compression in webcomic strips I'd love to hear about it. Take the image http://www.penny-arcade.com/images/2007/20070307.jpg for example. When I run pngout on a strip the result is often several times larger.
16:30 erik@spekkio % ./pngout-darwin -c2 -f5 -s0 20070307.jpg
In: 104908 bytes 20070307.jpg /c2
Out: 386332 bytes 20070307.png /c2 /f5
Chg: +281424 bytes (368% of original)
Time spent in user mode (CPU seconds) : 12.472s
Time spent in kernel mode (CPU seconds) : 0.030s
Total time : 0:14.48s
CPU utilisation (percentage) : 86.3%
Times the process was swapped : 0
Times of major page faults : 0
Times of minor page faults : 0
Any ideas?
Erik Karulf on March 8, 2007 2:47 AMDon't forget JPEG's progressive rendering feature which does pretty much the same thing as PNG's "2D interlacing" but with less comparative overhead. I remember in the late 90s most JPEGs used to load like this.
Mark on March 8, 2007 3:26 AMHi Eric. My guess would be it's because your input file is a JPG. That means it will have JPEG artifacts, messing up the whole "large areas of the same colors and hard transitions between them" thing.
I suspect you'd need to work off uncompressed or lossless image formats to see an improvement.
Michael Knight on March 8, 2007 3:37 AMBegin pedantry:
Contra Eamon, and your implication, GIF is not Istrictly/i limited to 256 a href="http://phil.ipal.org/tc.html"colors/a.
In practice, of course, you'd never want to try and use true-color GIF, because of slow rendering times, and because GIF is a horrible dead-end.
End pedantry.
Sigivald on March 8, 2007 3:37 AMHi Erik. My guess would be it's because your input file is a JPG. That means it will have JPEG artifacts, messing up the whole "large areas of the same colors and hard transitions between them" thing.
I suspect you'd need to work off uncompressed or lossless image formats to see an improvement.
Michael Knight on March 8, 2007 3:38 AMI usually rely on PNGOptimizer ( http://psydk.org/PngOptimizer.php ).
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.
Masklinn on March 8, 2007 3:41 AMAlso, 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.
Masklinn on March 8, 2007 3:46 AMPNG Alpha opacity in IE 5.5+ :
http://www.twinhelix.com/css/iepngfix/
quote
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!
/unquote
"...between lossless GIF or lossless PNG..." I think you meant "lossy".
Josh on March 8, 2007 4:24 AMYow, 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 http://www.libpng.org/pub/png/png-gammatest.html for a basic gamma test and the top of http://www.libpng.org/pub/png/gamma-consistency-test.html 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.)
Greg Roelofs on March 8, 2007 4:33 AMOh 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.
Greg Roelofs on March 8, 2007 4:47 AMGIF 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.
GregMagarshak on March 8, 2007 5:03 AMI 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).
GrahamStw on March 8, 2007 5:18 AMActually, 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.
http://zenit.senecac.on.ca/wiki/index.php/APNG
Guy on March 8, 2007 5:45 AMJJ, 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.
GrahamStw on March 8, 2007 6:11 AMNote 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.
http://en.wikipedia.org/wiki/MNG
PNG rocks. However, if you think that progressive images have no benefit, you haven't been stuck on a 56k recently :(
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.
Mike on March 8, 2007 6:37 AMPNG 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.
emacsen on March 8, 2007 6:51 AMProgressive 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.
Phil on March 8, 2007 6:58 AMAs 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 (http://www.unisys.com/about__unisys/lzw), "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.
--
Dave
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.
http://www.libpng.org/pub/png/apps/pngquant.html
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 ComicSpace.com 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.
Jae on March 8, 2007 7:39 AMAnd 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.
engtech on March 8, 2007 8:21 AMThe number of people still using IE versions prior to 6 are not quite "statistical noise" yet.
According to the browser statistics shown at w3schools.com, 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.)
http://www.w3schools.com/browsers/browsers_stats.asp
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.
Josh wrote:
"'...between lossless GIF or lossless PNG...' I think you meant 'lossy'."
lossy ??? which one of the two do you think is lossy ???
it is not the first time i hear people thinking PNG is a lossy compression scheme. i really wonder why people thinks so.
Josh, if PNG was lossy, you would not be able to recover your files after zipping them: the same compression algorithm is used underneath the 2, png and zip.
rien on March 8, 2007 8:43 AMGreat tip! PNGOUT comes with the plugin package for the current IrfanView... I'm off to repack all my PNGs.
Chris Nahr on March 8, 2007 8:54 AMgood analysis.
arindam giri on March 8, 2007 9:11 AMI don't think GIF has a copyright. And its patent expired. It sucked while the patent existed, yes, but now the legal issue isn't an issue anymore.
GregMagarshak on March 8, 2007 9:26 AMThe Sad Story of PNG Gamma "Correction":
http://hsivonen.iki.fi/png-gamma/
More background here, with specific examples where Mac browsers behave differently in rendering Gamma attached to images:
http://blogs.smugmug.com/onethumb/2007/02/14/this-is-your-mac-on-drugs/
Jeff Atwood on March 8, 2007 9:49 AMOne advantage of PNG interlacing is that the browser can lay out the page correctly more quickly, after getting the first 'frame' or whatever of the interlaced image. Of course you should be using width and height tags on images, but not all forums/websites/cms's do that automatically.
Reed on March 8, 2007 9:59 AMIt's a little harsh to discount the lack of support for .png transparency so casually.
I've got some very large gif files because of this problem.
While an Idealistic comparison may say that "the formats both support transparency" the fact that very common browsers can't render it leaves the 'format support' for it pretty worthless.
It's too soon the leave this factor out of real world comparisons.
jake on March 8, 2007 10:08 AMOne factor in all of this is the deflate implementation used. OptiPNG uses the standard zlib library while PNGOUT uses Ken Silverman's proprietary but available-for-free deflate implementation. AdvPNG let's you recompress the file with 7-Zip's deflate implementation which is on par with Silverman's deflate, and it's open source. It's best to run AdvPNG after running it through a png optimizer like OptiPNG or PNGOUT.
There's also the possibility of lossly compressing pngs with PNGNQ (Linux/Mac) or PNGQuant (Cross platform). PNGNQ will give you the best file sizes out of all the utilities mentioned at the cost of a little bit of color information.
Anonymous Coward on March 8, 2007 10:12 AMThanks for the pointer to PNGOUT. At my site, we create 1920x1080 images of scientific data which we then put together in a movie. Thanks to PNGOUT, each PNG image reduces by ~18%. It takes about 2 minutes to run per image, but that is what parallel processing (and long weekends) are for.
PaulAdams on March 8, 2007 10:57 AMHmm very interesting ... I use a lot of PNG's in the help file for Paint.NET, and for all the icons in the application. So I went and PNGOUT'd all the PNG's that are distributed with Paint.NET and did a build of the latest v3.05 stuff I've been working on. These numbers are for the downloadable installers:
PaintDotNet_3_05.exe (before) -- 5,195 KB
PaintDotNet_3_05.exe (after) -- 4,897 KB
So 298 KB savings multiplied by probably 300,000 downloads a month ... congratulations, you just helped save 85 GB of bandwidth for me next month :) (after 3.05 is released that is)
Rick Brewster on March 8, 2007 11:37 AMImpressive!
Ivan Minic on March 8, 2007 11:45 AMJosh: Neither GIF nor PNG is lossy. GIF uses LZW compression, commonly used in Zip. PNG uses Deflate (RFC1951), commonly used in gzip.
Powerlord on March 8, 2007 12:39 PMWhat about tif? The state of Florida requires that documents must be imaged using the 1992 Aldus Tif standard.
Name on March 8, 2007 12:58 PMFor Ken Silverman fans, I did a few interviews with him back in the day:
In 2001 or so
http://www.thatstrife.com/interviews/kensilverman.asp
and a little more recently
http://www.strifestrips.com/Features/TributeToBuild/Interview_Ken.aspx
Ozh, if you strip the gamma info from the PNG, as PNGOUT apparently does, the color matching problem goes away.
Joshua Paine on March 9, 2007 1:41 AMThere's another annoying bug with PNG files within MSIE : colors are not correctly rendered. Example : body{background:#ddeffa} and body{background:url(bg.png)} (where bg.png is a plain one color image with color #ddeffa) are *not* the same with MSIE.
Strip out the Gamma Correction chunk (every PNG optimizer does it), this it what makes MSIE go Bonkers (that and other stuff, but...)
Typically, mixing PNG and JPG images with MSIE in a layout where you need background to blend correctly is a no-no.
It's actually a non-issue once you get to understand the issue in the first place
If someone has any brilliant ideas about image compression in webcomic strips I'd love to hear about it. Take the image http://www.penny-arcade.com/images/2007/20070307.jpg for example. When I run pngout on a strip the result is often several times larger.
JPEG artifacts (throw PNG's compression algorithm out of the window by creating minuscule chunks of varied colors) + the fact that it probably compresses to PNG/32, compressing to PNG/8 and playing with the number of colors yields around the same size as your JPEG wihout any visible difference in quality.
It'd probably fare much better using PNG/8 on the original image and playing with the number of colors (see Photoshop's Save for the Web dialog)
Ozh, if you strip the gamma info from the PNG, as PNGOUT apparently does, the color matching problem goes away.
Pretty much every PNG optimizing tool strips the gamma chunk, because it's mostly unused by clients and takes some room.
Masklinn on March 9, 2007 3:15 AMJeff, 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.
Will (Vertigo) on March 9, 2007 10:06 AMUsually, 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...
Masklinn on March 10, 2007 2:39 AMWorthy 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.
Dave Bricker on March 11, 2007 10:10 AMErik: 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.
Charles Roper on March 14, 2007 2:36 AMForgot 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. :)
Charles Roper on March 14, 2007 2:43 AMJeff:
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
SammyB on March 14, 2007 5:31 AMPaint is not the best at PNG compression (in fact probably the worst).
Lachlan McDonald on March 18, 2007 5:18 AMAfter reading this article, I made a GUI that others may find useful. I previously ran Dojo Shrinksafe (for JS) and CSSTidy (for CSS) on a copy of my web applications before uploading. Now when adding a another tool I decided to just make a GUI which would compress certain files using those tools (and now PNGOut) as well to an output directory.
It's available here: http://www.sachmanbhatti.com/software/sbWebOptimizer
I e-mailed Ken Silverman, but did not get permission to package pngout.exe so just place it in the "tools" subfolder.
Sachman Bhatti on April 3, 2007 8:15 AMSammyB:
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.
Wolff on April 8, 2007 6:51 AMThanks for the tips Jeff.
I've just successfully used PNGOUTWin (http://www.ardfry.com/pngoutwin/) to optimise my alpha PNGs and it's stopped the problem where IE was distorting the background colour of the image that needed to match my CSS background colour. It was easy to use and reduced my file sizes by about 50% - I'm very impressed!
Thanks again,
Cathy
PngOut still have alot of room for improvement.
ACDSee8 compressed 94MB pngout files to
82MB j2(Lossless mode!).
(ACDSee really suck. Recommend GQView though it lack j2)
I guess j2 using wavelets gives it an edge.
djvu is Free(?) lossy-wavelets.
But perhaps png developers may still learn about
lossless-wavelets and surpass j2-lossless...
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 Talsky on March 6, 2008 8:22 AMDaniel:
I thought the trend was rather to use CSS and positioning to apply rollover effects? It circumvents the issue of having to preload resources.
Konvertor has a GUI for pngout
Loopy on April 15, 2008 8:05 AM@Daniel Talsky
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
realityclause on May 1, 2008 5:12 AMThanks for the pointer to PNGOUT
restaurant marseille on June 4, 2008 6:20 AMCheck 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.
Ippi on June 12, 2008 6:46 AMKurt, 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!
Slimypants on May 15, 2009 2:58 AMWhilst 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 on August 3, 2009 9:19 AMWhilst 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 on August 3, 2009 9:31 AM@HEXtaC This is true, however these compression programs have options to do either lossy or lossless.
Pinger on August 12, 2009 1:17 PMIt'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.
Eamon Nerbonne on February 6, 2010 10:02 PMJeff,
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
Jason Judge on February 6, 2010 10:02 PMThis is only a preview. Your comment has not yet been posted.
As a final step before posting your comment, enter the letters and numbers you see in the image below. This prevents automated programs from posting comments.
Having trouble reading this image? View an alternate.
| Content (c) 2009 Jeff Atwood. Logo image used with permission of the author. (c) 1993 Steven C. McConnell. All Rights Reserved. |
Posted by: |