Hacker News Reader

Comment by SloopJon | Hacker News Reader

The Github README says, "Guetzli generates only sequential (nonprogressive) JPEGs due to faster decompression speeds they offer." What's the current thinking on progressive JPEGs? Although I haven't noticed them recently, I don't know whether they're still widely used.

View on HN

As a user, I dislike progressive images because of the ambiguity regarding when they've finished loading.

As a user, I love progressive images because I can see the whole image very fast. (I don't have to wait for it)

I use progressive JPEGs if they have a smaller filesize, which is true most of the time.

mozjpeg also generates progressive JPEGs by default, for the same reason.

I don't really understand why they would be slower to decode. It's really just the same data ordered differently in the file.

I can see that if you try to render an incomplete file you might end up "wasting" effort blitting it to the screen and stuff before the rest of the data is decoded. But if thats a concern, one can simply rearrange the data back to scanline order and decode as normal?

They are slower to decode mostly due to decreased cache locality. In sequential JPEGs you read one block worth of data, make pixels out of it, and write the pixels out. In progressive encoding, you need to write the pieces of coefficients back to memory at every scan -- the whole image won't fit into cache -- so there's one more memory roundtrip for every pixel. Also, there's just more symbols to decode in total.

Reply on news.ycombinator.com