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.
Great tip! PNGOUT comes with the plugin package for the current IrfanView… I’m off to repack all my PNGs.
I 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.
The 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/
One 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.
It’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.
One 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.
Thanks 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.
Hmm 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)
Impressive!
Josh: Neither GIF nor PNG is lossy. GIF uses LZW compression, commonly used in Zip. PNG uses Deflate (RFC1951), commonly used in gzip.
What about tif? The state of Florida requires that documents must be imaged using the 1992 Aldus Tif standard.
For 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.
There’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.
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.
