Support for High Throughput JPEG 2000 (JPH format)

[bitsgalore]

Standard:

https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-T.814-201906-I!!PDF-E&type=items

This is largely identical to JP2, with some relatively minor deviations. Codestream syntax is also mostly the same as a standard JP2K codestream, but with added CAP and CPF markers (and some extensions/constraints to existing markers).

Whitepaper:

https://www.htj2k.com/wp-content/uploads/white-paper.pdf

Software support (status September 2023)

HTJ2K reference software

https://gitlab.com/wg1/htj2k-rs

Doesn't seem to be able to read or write JPH either? Encode / decode to/from codestreams works. Clumsy command line interface; no commit activity over last 2 years.

Grok

https://github.com/GrokImageCompression

Doesn't support JPH, but wraps HTJ2K features into regular JP2. Developer is interested in adding JPH support.

OpenJPH

https://github.com/aous72/OpenJPH

Currently only writes HTJ2K codestreams, not the JPH format!

OpenJPEG

Latest version supports HTJ2K decoding with some limitations. Code is based on OpenJPH, details here.

OpenHTJ2K

https://github.com/osamu620/OpenHTJ2K

This one does support JPH as an output format! E.g.:

~/OpenHTJ2K/build/bin/open_htj2k_enc -i a2_colr.ppm -o a2_colr.jph

From author of HTJ2K reference software (but unlike HTJ2K-rs, OpenHTJ2K seems to be actively developed).

Kakadu

Apparently full support (but proprietary):

https://kakadusoftware.com/wp-content/uploads/Overview.txt

More HTJ2K resources:

https://github.com/chafey/HTJ2KResources

[bitsgalore]

Some small test files here:

https://github.com/uclouvain/openjpeg-data/tree/master/input/nonregression/htj2k

[bitsgalore]

Did a few first tests with Grok. Some observations (all based on v10.0.8):

Grok doesn't accept the .jph file extension, even though this is the default as per the standard:

grk_compress -i aware.tif -o aware-ht.jph -M 64

Throws:

[2023-09-11 15:44:16.364] [error] Unknown output format image aware-ht.jph [only *.j2k, *.j2c or *.jp2] 

Below command does work:

grk_compress -i aware.tif -o aware-ht.jp2 -M 64

This writes a file in JP2 format (checked with Jpylyzer), but it does not conform to JP2:

    <isValid format="jp2">False</isValid>
    <tests>
        <contiguousCodestreamBox>
            <siz>
                <rsizIsValid>False</rsizIsValid>
            </siz>
        </contiguousCodestreamBox>
    </tests>

A look at the HTJ2K)standard:

A.2 SIZ marker segment Bit 14 of Rsiz shall be equal to 1.

So if I understand this correctly Grok simply writes HTJ2K features directly to JP2, without using the appropriate format.

Submitted this Grok issue

[bitsgalore]

Note on CAP marker segment: can't find this in my version of ITU-T T.800 (08/2002), but I did find this:

https://www.itu.int/rec/dologin_pub.asp?lang=f&id=T-REC-T.809-201105-I!!PDF-E&type=items

Symbol	Code	Main header	Tile-part header	Rec. ITU-T T.80x ISO/IEC 15444-x Heritage/Extended
Extended capabilities	CAP	0xFF50	required	not allowed	Rec. ITU-T T.801 (2002)/Amd.2 (2005) / ISO/IEC 15444-2:2004/Amd.2:2006

Details in section A.2.8.

[bitsgalore]

DONE:

• JPH file format validation (Annex D)
• Codestream: SIZ, CAP, COD, COC, RGN markers.
• Codestream: finish CPF marke + rework rSiz parsing
• Codestream: consistency checks CAP properties

TODO:

• Update XSD
• Find/make test images
• Including images that use parameterized colourspaces (code now remains untested).
• Add JPH unit tests

[bitsgalore]

From standard:

A.2 SIZ marker segment

Bit 14 of Rsiz shall be equal to 1.

Both JPH + JHC file from OpenJPEG-data and JPHs created by OpenHTJ2K fail this requirement! Instead, the 2 rsiz bytes are:

40 00

UPDATE - turns out standard uses bit numbering scheme that is exactly the opposite of what I thought:

https://github.com/osamu620/OpenHTJ2K/issues/148#issuecomment-1724720654

With this in mind implementation of Rsiz in both files is actually as expected.

[bitsgalore]

Closing issue as remaining tasks are all covered by other individual issues.