OpenJPEG 2.5 Released With High Throughput JPEG 2000 Decoding (HTJ2K)

[c117152]

The initial part of JPEG2000 (ISO/IEC 15444-1) - published in the year 2000, as the name implies - should be clear of patent issues.

40k results suggest otherwise: https://patents.google.com/?q=JPEG2000&oq=JPEG2000

Many of them are owned by Canon and Xerox so I assume they're specific to printers... Intel shows up so there's probably some fancy compute tricks you can't use without Intel hardware... Comparatively, when it comes to JPEG XL, there's only a handful of patents and most are owned by Google: https://patents.google.com/?q=%22JPE...=%22JPEG+XL%22

There's still less exact, general patents like the one Microsoft has... But overall, unless Google or Microsoft bakes such codecs in their FOSS browsers along with a patent disclaimer, no one is going to bother.

[coder]

It's a shame that JPEG 2000 didn't do better. From my shallow understanding of how it works, it sounds good. And it had some extra features that are nice to have. But to beat a solidly intrenched format like 'classic' JPEG you need to be much better than it, and JPEG 2000 just wasn't. In fact, I gather its compression was often slightly worse.

Maybe it wasn't an order of magnitude better than JPEG, but I think it wasn't worse.

I thought the patent claims against it basically kept it from ever gaining much adoption. Recall that it came onto the scene right around the time some litigious company acquired the rights to patents GIF infringed. So, people were definitely sensitized to the issue.

Plus it did nothing to solve the problem of all of the existing JPEG files out there in the world.

That's true, but I think it's a non-issue. Software has supported multiple image formats even back when JPEG came onto the scene. libjpeg is small and comparatively simple. You can easily have both a JPEG decoder in addition to one for whatever newer formats come along.

That's not to say JPEG-XL's reversible transcoding from JPEG isn't a useful feature, but its absence certainly wasn't a deal-breaker for JPEG 2000.

[coder]

40k results suggest otherwise: https://patents.google.com/?q=JPEG2000&oq=JPEG2000

I think that's not how it works.

The patents of concern would be those which the underlying JPEG 2000 compression infringed, which weren't part of the official patent pool at the time of its drafting. These would've been filed prior to JPEG 2000's first draft & initial implementations, and therefore probably don't even reference it!

Anything that explicitly references "JPEG2000" should've come after the fact, and would concern various systems and methods that either incorporate JPEG2000 or build on its technology, in some way.

Comparatively, when it comes to JPEG XL, there's only a handful of patents

Because it's new. Give it 20 years and then you'll probably find similar results.

[coder]

An interesting thing about JPEG 2000 I learned a couple of years ago is that it's what you see when you watch a movie in the theatres these days.

The movies are not distributed as a video file, instead the theatre get a encrypted harddrive which contains the video as single jpegs, with the audio tracks separate.

It's called 'Digital Cinema Package', and the server you connect the harddrive to runs Linux.

I've heard about moves towards networked distribution of movies to theaters, for quite a while. I think the distribution methods and probably even their adoption of newer codec technology have evolved, in recent years. There's also the matter of screening live streamed events, which some theaters have been doing for a while.

Also, there seems to be a shift towards features that might not be supported by JPEG 2000, such as those incorporated by Dolby Vision.

Related:

https://dcdcdistribution.com/services/

[microcode]

May those who use jpeg2000 on existing softwares.

But this isn't jpeg2000, it's incompatible.

[hoohoo]

Coding efficiency is a sort of measure of how optimal the computed Huffman coeffs chosen are?