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

[phoronix]

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

Released on Friday was OpenJPEG 2.5 as the newest update to this open-source JPEG 2000 image library. Notable with this new release for this BSD 2-clause library is now supporting high-throughput "HTJ2K" decoding...

https://www.phoronix.com/scan.php?page=news_item&px=OpenJPEG-2.5-Brings-HTJ2K

[post-factum]

Why would one consider choosing JPEG 2000 over JPEG XL?

[arun54321]

May those who use jpeg2000 on existing softwares.

[c117152]

Why would one consider choosing JPEG 2000 over JPEG XL?

1. PDF embedding.
2. The patent situation with either isn't 100% certain but JPEG2000 been around for longer so it's less likely you're going to get screwed over using it.

[coder]

2. The patent situation with either isn't 100% certain but JPEG2000 been around for longer so it's less likely you're going to get screwed over using it.

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

"High-throughput JPEG 2000 Part 15 (ISO/IEC 15444-1) was only firmed up in 2019."*

That part makes me apprehensive, regarding the IP situation. Furthermore, it sounds like this new mode won't be supported by most decoders currently in the wild, thereby giving it no particular advantage, in terms of installed-base, over other recent image codecs (AVIF, HEIC, JPEG-XL, to name a few).

* The article incorrectly cites "ISO/IEC 15444-1", when part 15 should be "ISO/IEC 15444-15".

[brucethemoose]

Why would one consider choosing JPEG 2000 over JPEG XL?

IIRC some medical file formats use JPEG2000. Those stacks of really high res images must be decoded quickly when, for instance, scrolling through CT slices, and they probably take advantages of features (high bit depth? colorspace? lossless encoding?) not available in jpeg.


JXL would be better, albeit a bit slower to decode. In fact, they should *really* use a video codec with no b frames and a cache for that... but we aren't there yet.

[uid313]

JPEG 2000 is an old format, there is JPEG XL which is designed to supersede it. Also WebP, AVIF and HEIF are newer.

[coder]

they probably take advantages of features (high bit depth? colorspace? lossless encoding?) not available in jpeg.

Fun fact: original JPEG supported up to 12-bit color. With libjpeg, it was a compile-time option - which made it uncommon, in practice.

JPEG 2000 is an old format, there is JPEG XL which is designed to supersede it.

JPEG 2000 is a very different format than the original JPEG. It's wavelet-based, rather than using DCT, as JPEG was.

The way I look at it, both JPEG 2000 and JPEG-XL are/were trying to be successors to the original JPEG.

[Imroy]

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. Plus it did nothing to solve the problem of all of the existing JPEG files out there in the world. JPEG XL does both. I hope it takes off and largely replaces classic JPEG.

[Grinch]

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.