[ken]

Counterpoint on progressive JPEG [1]:

> Some people like interlaced or "progressive" images, which load gradually. The theory behind these formats is that the user can at least look at a fuzzy full-size proxy for the image while all the bits are loading. In practice, the user is forced to look at a fuzzy full-size proxy for the image while all the bits are loading. Is it done? Well, it looks kind of fuzzy. Oh wait, the top of the image seems to be getting a little more detail. Maybe it is done now. It is still kind of fuzzy, though. Maybe the photographer wasn't using a tripod. Oh wait, it seems to be clearing up now ...

[1]: http://philip.greenspun.com/panda/images

[ck2]

On web sized progressive, the loading is over quickly and the benefit is an immediate placeholder on even slower connections instead of whitespace.

But the real reason is it also produces smaller file sizes.

[oofabz]

Progressive JPEGs are not smaller. They contain the same data, just rearranged. You can losslessly transform a progressive JPEG into a baseline JPEG and vice versa, without recompressing it. The jpegtran tool, included with the standard JPEG library, can do this.

[revertts]

Larger images saved as pjpegs tend to be slightly smaller than a standard jpeg.

http://www.yuiblog.com/blog/2008/12/05/imageopt-4/

[ars]

If you actually try it using the tool you yourself mentioned you'll see that progressive JPEG's are in fact smaller.

[FrankBooth]

Stream compression benefits from locality of data, so the ability to merely rearrange data can be quite beneficial.

[mgcross]

Not a fan of progressive myself, but it should be noted that iOS (at least iOS5), will downsample jpgs larger than 2MP; saving as progressive apparently circumvents this 'feature.'

[lloeki]

I suppose this feature is there so that the thing takes less RAM and is less taxing on the GPU. So strike a balance and choose wisely, as you don't want four or so images killing all unfocused Safari tabs.