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.
>> 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).
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.
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)
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.
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.
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.
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'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.
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.
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.
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.
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?)
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.