PNG vs JPG: 6 simple lessons you can learn from our mistakes | Hacker News Reader

PNG vs JPG: 6 simple lessons you can learn from our mistakes

turnkeylinux.org

81 pointsliraz40 comments

I think there's a much more important distinction to be aware of. Namely, that PNG is good at representing graphics while JPG is good at representing photos. A screenshot of my browser while typing this comment is 388 KB in JPG, only 80 KB in PNG. If your image consists of few colors and large areas of solid color, you should always use PNG. The image will probably actually be smaller. If your image is a photo or something photo-like, you should use JPG.

Either way, your master images should be the format you first obtained or created the image in. If the image came from a camera, the master should be the raw camera image. If the image was created in photoshop, the master should be a photoshop file.

For screenshots and other linear graphics, choosy moms choose GIF.

Not unless you have only 256 colors on your desktop.

Edit: Even if you're OK with indexed color, the indexed PNG will still be smaller.

It usually doesn't matter. If you have photo-like data in your screenshot, you're better off going with the JPEG.

EDIT: You're probably right about the indexed PNG.

I don't have a .jpg optimizer, but a PNG screenshot run through pngcrush has been consistently smaller than a .jpg compressed to the wrong side of tolerable for me.

A screenshot of Opera displaying this website gave me a 90 Kilobyte GIF or a 60 Kilobyte PNG, both with 256 colours.

For still images, why would you ever go with GIF over PNG?

>> If your image is a photo or something photo-like, you should use JPG.

Keep in mind that many, many things produced by computers these days are photo-like, as the OP demonstrated with the icons, so this might not be the best rule of thumb. No argument that simple images should be PNG, but toss in a couple of gradients (which your HN screenshot does not have) and your PNG can start to blow up.

PNG is extremely good at compressing certain kinds of gradients.

Linear gradients get compressed nearly as well as large areas of flat color. More complicated images, of course, are more difficult to optimize.

Basically, you cannot typically create PNG-optimized graphics automatically (yet). There are a lot of things you can do pre-save to help the compression techniques (and when they won't work, use another format and stitch the two together - at the cost of another HTTP request).

http://www.smashingmagazine.com/2009/07/15/clever-png-optimi... is a pretty good outline of it.

It's rare when this is good advice.

Most of the time you want PNG for drawn images. JPEG is only for photos taken with a camera.

You just happened to have images with lots of gradients, but most of the time PNG does a better job.

Also when you downsampled the images, whatever program you used was not very good. When I tried it the images were always one row better than what you showed. i.e. when I changed it to 128, it looked like your 256, and my 64 looked like you 128, etc.

>Most of the time you want PNG for drawn images. JPEG is only for photos taken with a camera.

You clarified this in your next line, however the above summary, particularly the comment on JPEGs, is wrong.

PNGs are appropriate for areas with common colors, and where clarity is critical - most logos, charts, web comics, etc.

JP(e)G is appropriate for photorealistic images, where there are significant varations, such as, of course, photos, rendered images, photorealistic images, and so on.

I am kind of shocked that anyone is having this discussion right now. This is like circa 1995 that these sorts of discussions were cutting edge (though it was GIF versus JPEG)

> This is like circa 1995 that these sorts of discussions were cutting edge

Of course, people born in 1995 are now 15 years old, a good age to begin figuring out the nuances of image formats.

"Also when you downsampled the images, whatever program you used was not very good"

Given that it's turnkeylinux, I think it's a safe bet that they were using Gimp.

Which completely explains the low quality of the output.

Photoshop's save for web option makes quick work of these decisions, if you have access to a copy. In the '4-up' view you can visually compare your original file to three different formats with information on file size and precise control over color indexing, etc.

The save for web option will also strip out any extraneous info, such as exif data, that can add to the image size.

Agreed, Photoshop is the right tool for the job here, not a command-line tool. Some images will need more colors than others, some will need more dithering than others; and the tool used here doesn't look like it picks palettes very well.

Don't judge optimized pngs from this example. Those pngs look terrible.

Here's what a 64 color png looks like created in Photoshop: http://i.imgur.com/4p2SW.png

It's smaller and better looking than the jpeg that they actually use on their home page: http://www.turnkeylinux.org/files/images/icons/twiki.jpg?125...

The photoshop version would look even better and be even smaller if it were created from the uncompressed source instead of a jpg.

You're right, these guys just don't know how to create indexed PNGs properly. I ran their originals through Photoshop, with 100% dither at 96 colors, then used pngout (the best* png compressor), and came out with better looking, smaller files.

* http://advsys.net/ken/utils.htm

Are there seriously still enough people out there who don't know the differences between PNG, GIF, and JPEG that this article makes it to the front page of HN?

Look at the "Try Turnkey on Amazon..." banner at the top of the turnkeylinux.org home page and tell me the artifacts don't look like hammered ass. I'll stick to lossless for anything with textual elements, thanks.

I also don't get the use of these icons where the text is really fuzzy. Can you make out the word "Linux" at the bottom?

http://www.turnkeylinux.org/files/images/icons/drupal.jpg?12...

No, but I can't make that out in the png version either. http://www.turnkeylinux.org/files/images/blog/jpg-vs-png/dru...

Looks like an issue with the original file - it was probably created at a higher res and then down-sampled.

Thanks, that's a good point. I actually stopped noticing that bit of silliness. I just sent Alon, who did an otherwise commendable job slapping together those icons in the GIMP, an email asking about that...

I sure hope anyone who calls themselves a web designer knows this stuff inside out already...

I'm not a web developer, but could html5/javascript replace the need for some static images? For example, simple text logos. While a text banner could take several dozen KB's, some form of drawing javascript code could take only a fraction of that. Unless I'm misinterpreting how html5 works. :)

And lay out your "images" via CSS and try to make it work on all browsers? On top of that, for a complex image, you'll end up encoding your image data in JS or HTML or some other text format, which would take up much more space than a format like JPG/PNG/GIF. Those formats are designed to handle images and that's all they do.

Plus, with JS you wouldn't necessarily get immediate rendering of the image, so you would be making the UX worse, not better.

That is not what I meant, actually. I meant rendering a logo via some paint methods, where all the information the methods have is some text, color and style attributes, etc. Then the logo gets drawn on-the-fly by the user's browser. It could work for simple logo's, I believe.

Yes, but everything you describe can be done with CSS as well: loading custom fonts, background colors, even gradients.

This is worth a try for a lot of reasons. If not for logos, then for buttons on your site. When I switched to painted buttons vs images in my downloadable desktop software, I (1) saved a lot of space on downloads, and (2) saved a TON of time whenever I wanted to add a new button or change the color scheme, or gradient, or shadow, etc. Re-creating each button (even just creating a new one) was a total pain in the ass compared to simply instantiating a new button or playing with the paint method.

I haven't tried it in html5 yet, but if I use buttons on the page I will definitely give this a shot.

Logos should be easier to copy and paste because people do that a lot. Think of a journalist writing an article about some site, if he needs a image he might use your logo. Also, Facebook uses images on the page when you post a link to identify that link.

There are so many reasons for a logo to be an image.

Or you could just use svg

JPG for photos; PNG for logos, graphics, ui elements, sprites or anything else that has a vector (adobe illustrator) master.

I'll probably get some downvotes for this, but IMO hacker founders shouldn't get their panties in too much of a bunch over this (with the possible exception of mobile stuff). Work on your startup and solving a problem–then– when your traffic warrants it–you can start obsessing over a few kilobytes of savings. Swapping out graphics in your page templates or CSS is trivial.

When I see a good-looking site, I don't need to go digging into their source to see if they used JPGs or PNGs before it catches my eye.

Follow the above rule, keep your master PSD/AI files, and you'll be fine.

On Windows, here's a neat free little program: http://luci.criosweb.ro/riot/

This way you can instantly try out different jpg/gif/png formats and see their visual and quality impact.

Also, something to beware is pre-packaged icons. We were an icon pack, and on examination, found some of the PNG icons were vastly larger than they should possibly be. A 16x16 pixel PNG was 5K instead of a few bytes.

I wonder if they have considered serving images through a separate domain/CDN and whether that would have had a bigger impact. Also, using CSS sprites might help.

"Premature optimization is the root of all evil". We used SimpleCDN for a while, but the increase in performance didn't justify the increase in complexity.

Oh, I agree. I was just wondering whether you thought about it and I guess you have. BTW Google Page Speed's biggest complaint for your home page was that images were not served from cookieless domains and downloading them was not paralellized.

Simple trick to make smaller PNG files: Posterize your image to 64 before compressing

I don't think that's good advice. Posterize just throws away data and causes banding; and if your image contains mostly one hue, or a limited number of hues, then you're removing more colors than you need to.

Use a tool that will create a perceptual or selective palette like Photoshop's "save for web" tool. You can choose png-8 with 64 colors, but it will pick the right 64 colors for the job.

Since most users use 6bit dithered LCD displays, the quality loss usually isn't noticeable--for images that have more than 256 colors, it can be a big win.

edit: also those that require alpha transparency; adding alpha values uses up a lot of palette entries, and most tools don't support it (Fireworks?)

This reads more of a guide on why it is good to avoid gradients.

mogrify is the right tool for batch image processing, not a kludgy convert loop.

Reply on news.ycombinator.com