Support for high throughput (HTJ2K) encoder

[gunterze]

Is there any plan by anyone to add support for high throughput (HTJ2K) encoder in the foreseeable future?

The Medical Viewer Weasis and Medical Image Archive DCM4CHEE Archive rely on OpenJPEG - integrated via OpenCV Java API - for J2K compression and decompression of images. Recently the Digital Imaging and Communications in Medicine (DICOM) Standard specified in DICOM Supplement 235:HTJ2K Transfer Syntax the use of HTJ2K compression for medical images. So as developers of Weasis and DCM4CHEE Archive the questions arise, if we shall start working on to integrate OpenJPH - or any other existing OSS implementation - or we can wait for support of HTJ2K by OpenJPEG also for encoding/compressing?

(We are aware and highly appreciated the added support for high throughput (HTJ2K) decoding by @aous72 in #1374 .)

[aous72]

Hi Gunter,

I think it is easiest for you guys if OpenJPEG had HTJ2K encoding support.

Let me describe the current status of HTJ2K in OpenJPH.
OpenJPH encodes quantized coefficient (for lossy) or transformed coefficients (lossless) using one cleanup pass that encodes all the bitplanes in these coefficients.
Rate-control is currently driven by the quantization step size; finer quantization step sizes produce larger files with better quality.

A proper rate-control, in which you specify the desired rate, is missing. To do this properly, I need two more passes, the significance propagation pass (SPP) and the magnitude refinement pass (MRP), together with error estimation, and some post-compression rate-distortion method. These are missing from OpenJPH.
Of course, an alternative is to use the Qfactor method, as described in an ISO document, which is also missing from OpenJPH.

It is easiest to add what exists in OpenJPH to OpenJPEG. It is also possible to hack some sub-optimal rate-control into the existing OpenJPEG rate control mechanism. It is sub-optimal because it lacks SPP and MRP.

I just need to find the time to do it. I would be happy if someone else did it.

Cheers,
Aous.

[gunterze]

Thanks for the status update!

[jaime-olivares]

At fo-dicom.Codecs we are expecting OpenJPEG to implement HTJ2K encoding as we use it also for other encoders. So, it makes more sense to use the same library rather than picking another one.

In the mean time, we would probably use OpenJPH while waiting for the release of OpenJPEG with HTJ2K full codec.