Comment by userbinator | Hacker News Reader

Comment by userbinator | Hacker News Reader

For those interested in writing their own JPEG decoder (a highly recommended exercise --- it doesn't take all that long, actually) I suggest these two detailed articles:

https://www.impulseadventure.com/photo/jpeg-decoder.html

https://www.impulseadventure.com/photo/jpeg-huffman-coding.h...

Of course, there are also plenty of other "write a JPEG decoder/encoder tutorial" articles out there, of varying quality --- which if anything proves that it's not actually so hard. The standard contains a surprisingly simple and elegant flowchart description of the Huffman encoder/decoder.

The more modern JPEG 2000 encoding based on wavelets can be pushed much farther before visible artifacts appear, and includes a surprisingly efficient lossless mode. Of course, all this improvement is rather moot until common applications actually support it.

That was 12 years ago, and J2K is still pretty much unknown outside of niche applications. I'm not sure what they mean by "surprisingly efficient lossless mode", but decoding J2K is slower than regular JPEG by at least an order of magnitude if not more. The lack of articles about how to write decoders/encoders, or even just how it works in detail, is another sign of its relative obscurity. I've been studying the standard on and off for a few months, intending to write an article or even a decoder, but haven't gotten around to it yet. It is certainly an order of magnitude more complex.

> That was 12 years ago, and J2K is still pretty much unknown outside of niche applications.

It’s big in digitized documents and medical space where the superior compression has real benefits. One under-appreciated benefit is that the combination of progressive decoding and tiling is perfect for deep zoom services since you don’t want to precompute thousands of tiles per image when your library size is millions of images.

The big problem with JPEG 2000 as I see it was a lack of openness: for a long time, a copy of the spec cost non-trivial money and there was no standard test suite so compatibility was a constant problem. This meant that there was no good open source library and thus that most users had a bad experience relative to other formats. This changed over the last few years and OpenJPEG has become competitive on quality and speed but I’m afraid the damage may have been fatal.

One of the things which makes me sad about that is that it’d be great for progressive images on the web with an extension to srcset to specify the byte ranges for each size, avoiding the need to cache duplicate variants. Unfortunately the lack of high quality libraries and adoption probably means that window has passed, although it would be interesting to see how well a Web Assembly version performs.

Surprisingly efficient as for the size of the resulting binary compared to the original, not efficient as in time or cycle efficiency.

> decoding J2K is slower than regular JPEG by at least an order of magnitude if not more

True, but I'm sure it doesn't even hold a candle to the challenge of real-time decoding of modern video codecs.

Is it just a chicken-and-egg problem with hardware support, that prevents formats like FLIFF [0] from seeing adoption?

[0] http://flif.info/

I believe digital cinema packages use invidually-compressed jpeg2000 frames, so thats a fairly widespread usage.

PDF uses jpeg2k, but I don't know of anything else that does. (Archive.org is using both jpeg2k and jbig in their pdfs.)

Yes, the PDFs on archive.org are the first thing to come to mind (and my first exposure to J2K) --- not all of them use it, but you can identify them by the surprisingly long time it takes to render each page.

Reply on news.ycombinator.com