JPEG2000: Choices and Tradeoffs for Encoders (2004) [pdf]
cs.sfu.ca
cs.sfu.ca
One of the best things about using the Wavelet Transform over the Discrete Cosine Transform is it allows you to structure the file or stream from low to high frequency. This lets you get an image of any size out of a single file just by taking a subset of it. No more resizing thumbnails. It's kind of like a super version of progressive JPEG.
Sadly it never took off as storage / bandwidth are cheap and JPEG is so entrenched (especially in hardware). It still has some niche applications in constrained environments though.
Edit:
I dug out the paper if anyone wants to read it: https://unop.uk/misc/university-final-year-project-cbir
It's funny looking back at something you wrote over 8 years ago any seeing how you've improved. In other words, please don't use this to judge me!
Abstract
This project investigated the effects of scaling images
with JPEG2000 emulation software on a CBIR system based
on MPEG-7. A CBIR system was built that consisted of
indexing and retrieval. The performance of the system was
evaluated with standard metrics.
So it's the same reason noone uses theoretically superior arithmetic coding option in baseline JPEGs.
Image files don't take up that much space anyway so that is less compelling than for video compression.
What they needed to do is add more features, like WebP has now:
* Single format for photos and diagrams * Transparency * Lossy and lossless in the same format * HDR * Tiling of large pictures
Hopefully those features (especially lossy transparency) will help WebP do better than JPEG2000, though I'm not holding my breath. If IE and Firefox ever add support for it then I think web developers will start using it a lot.
Well it was more than that: it offered unlimited color depth for example, a big progress from 8 bit per channel. It was technically superior format in nearly every respect.
I did a lot of working with it and had quite a lot of problems with performance of the sample software.
Basically I think you are correct as to why JPEG2000 did not take off.
Edit: Also, I didn't know that. Maybe it was more a marketing problem then - they focused too much on the minor compression improvements, and not enough on the major new features.
Basically: they nailed the really hard stuff – much better compression, tons of advanced features – but flubbed the implementation. Unclear patents, hard to get spec, no public test suite, etc. meant that people only implemented it if they had to and those people usually found incompatibilities between the different commercial offerings, particularly if they actually used any of the more exotic features.
If I were implementing anything as complex as an image format now, my top priority would be having a decent open source implementation with a comprehensive test suite. If it's not well supported in *Magick and doesn't have browser support, I don't see it going anywhere no matter how attractive the other details are.
I think WebP stands a pretty good chance of supplanting JPEG on the web but it will still be used in lots of places.
This is exactly the bit I was referring to (the arithmetic coding method). The rest of CCITT/ITU baseline spec was unencumbered, that's what everyone ended up using.
Source: me, who implemented a baseline JPEG codec in late '90s.
I was under the impression that the free implementations (like libjpeg) did not use and of the patented techniques (such as arithmetic coding which patent recently expired) ?
>I think WebP stands a pretty good chance of supplanting JPEG on the web but it will still be used in lots of places.
I don't think anything will supplant JPEG as the de facto image format on the 'web', it's simply 'good enough' and of course free and supported everywhere.
Also as for lossy compression I'm not sure WebP is a real improvement over JPEG, I'd love to see it used instead of PNG for lossless compression though, as here it is clearly superior.
I always think of this during responsive image discussions – if JPEG-2000 had caught on, we could have solved that entire problem simply by adding an attribute to <img> telling the client which HTTP byte ranges it needs to request for various sizes. Single-file, cache-friendly, degrades well, and … will never happen.
> Sadly it never took off as storage / bandwidth are cheap and JPEG is so entrenched (especially in hardware)
JPEG proving to be impressively durable certainly was a key factor but I also think a lot of it comes down to naive moves by the community. In addition to the patent situation, there were just basic things like having a huge spec which for a long time was neither freely available nor accompanied by a public test suite.
I work with librarians who have large scanned digital collections and it was definitely interesting to compare the reactions: the users disliked JPEG 2000 because they'd been conditioned to expect it to be quite noticeably slower, unsupported by some of their tools, and knew that they couldn't rely on any two programs actually working with a given set of files until they tested it (http://jpylyzer.openpreservation.org/ has helped catch that earlier).
Meanwhile, the JPEG-2000 standards people & other boosters just tended to assume inevitability, where everyone would drop other formats once they saw how inferior they were. Things like Photoshop removing JPEG-2000 support (first discussed publicly in 2007, dropped in Elements in 2011) had this odd effect where some people expressed considerable concern (http://wiki.opf-labs.org/display/TR/JPEG+2000+support+discon...) but others just assumed it was some sort of unrepresentative quirk.
I cannot help but think that the situation would be considerably different if something like OpenJPEG.org had gotten significant support much earlier. Jasper, JJ2000, etc. were the most popular way to add support at all and they're slow, buggy and generally stagnant so many people had a bad first experience which encouraged avoiding the format.
You would never have a range start anywhere but the top of the file, as the whole point is that the later octaves are refinements of earlier ones. What makes JPEG2000 so amazing for this use case is precisely that you don't need to care about "ranges" (if you needed ranges, we might as well just have multiple files..). Instead, browsers just keep downloading the file until they either achieve the level of quality they need to render at the scale they currently care about (being able to continue later, if required) or run out of file. At worst, only as a "hint", I could see a benefit to having a table of sizes, but I feel like the cool solution for at would be to have an encoded version of the octave offsets, sort of like a zindex but for JPEG.
Correct, but also arguing against a claim I never made. 1-10 and 1-1000 are both range requests.
> What makes JPEG2000 so amazing for this use case is precisely that you don't need to care about "ranges" (if you needed ranges, we might as well just have multiple files..).
The difference is simply performance: separate files lower cache hit ratios. Smart HTTP caches, including some CDNs, cache a given resource only once so e.g. a laptop user can get an edge hit for the first n bytes which an iPhone user just read and the image can start displaying immediately while the finer detail streams in.
Similarly, streaming the download and canceling after you've read enough for your target output resolution means that you're likely to wasting time transferring more bytes than you actually needed. That's particularly nice on a high-latency wireless network where a significant amount of data can be in-flight and those unneeded bytes will consume battery power to transfer and will likely delay transferring other resources which are actually needed.
A poorly encoded block only makes a limited area of the image look bad. In wavelets errors in lower frequencies have ripple (wink) effects. It's mathematically easier to reason about DCT, so encoders can be really good.
DCT can easily create noise and sharp edges (even if they're fake, they still can create realistic texture), but any sort of noise and sharpness is expensive with wavelets. In practice it turned out it's easier to do DCT and then blur unwanted edges than to express edges to wavelets.
JPEG works mostly on 8x8 blocks of pixels, and in high resolution pictures each block is almost a single color. JPEG does a poor job taking advantage of similarity between the blocks.
JPEG2000 does at least see some use in archival formats.
Which isn't a very convincing argument when they are quite happy to implement dozens of other things that vastly increase the attack surface of browsers but have far lower practical impact on the average web page.
Imagine how much bandwidth has been wasted over the last 10 years because the web didn't have a lossy image format that supported transparency.
I believe codecs should actually be part of the OS. There should be one good, well-tested implementation per OS that browsers and other apps just link to. It might actually be possible to sandbox the codec components for increased security. Ideally, a web browser would just be a HTML+stuff parser, a layout engine, and a bit of gui, and shell out to the OS for everything else. Unfortunately, it seems the monolithic kitchen sink model has won.
That's the short version ;).
"Some of the HEVC algorithms may be protected by patents in some countries (read the FFmpeg Patent Mini-FAQ for more information). Most devices already include or will include hardware HEVC support, so we suggest to use it if patents are an issue."