Comment by jsingleton | Hacker News Reader

Comment by jsingleton | Hacker News Reader

I did my final University project on an algorithm based on JPEG2000. It's a pretty interesting way of compressing images.

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.

Both JPEG2000 and MPEG-7 never really took off. Most people moved on to more advanced algorithms.

My understanding is patent encumbering was what killed JPEG2000. There was an effort later to waive the patents, but not sure how comprehensive and perhaps a little too late.

So it's the same reason noone uses theoretically superior arithmetic coding option in baseline JPEGs.

To some extent, yes. However, JPEG was also patented and that did pretty well. Someone made a lot of money on licensing.

I think WebP stands a pretty good chance of supplanting JPEG on the web but it will still be used in lots of places.

https://en.wikipedia.org/wiki/WebP

I don't think anyone really used the bit of JPEG that was flagged up initially as not being royalty-free (I think IBM owned that part?) and later on I think it was only patent trolls that tried (unsuccesfully) to licence JPEG. Which licencing on JPEG are you referring to?

I don't think it applied to the version used on the web. However, this is just from memory based on conversations I had with MPEG and JPEG board members a long time ago. I can't find any sources so I could be mistaken.

>However, JPEG was also patented and that did pretty well.

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.

> However, JPEG was also patented and that did pretty well.

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.

Did you mean GIF? Patents and compuserve/unisys attempt to make money off them basically pushed the development of PNG to replace it.

https://en.wikipedia.org/wiki/GIF

It was more that it didn't offer enough benefits. It was "the files are a bit smaller".

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.

> It was more that it didn't offer enough benefits. It was "the files are a bit smaller".

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.

Anecdotes are not data but... It's taken over 10 years before I can safely send people png images rather than tiffs in my line of work. I'm not switching again until the benefits are blindingly huge and obvious.

Basically I think you are correct as to why JPEG2000 did not take off.

Performance was also a big problem, they had a lot of issues in the beginning justifying the amount of time it took to encode and especially decode the images. IIRC it was of the 100x the time of JPEG and that meant that at speeds of the time the bandwidth saved was overshadowed by the decode time.

I did a lot of working with it and had quite a lot of problems with performance of the sample software.

Did you feel that this was an intrinsic property of the format, or just that less/not enough time had been spent on developing efficient implementations?

Every single one of your “like WebP has now” is already in JPEG-2000: https://en.wikipedia.org/wiki/JPEG_2000

Even good compression of non-photographic images?

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.

I just wrote a longer version here: https://news.ycombinator.com/item?id=9941741

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.

> 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.

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.

> 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

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.

> 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.

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.

Reply on news.ycombinator.com