Closed bitsgalore closed 1 year ago
Thanks @bitsgalore for your findings. You are absolutely right.
The following lines are problematic.
https://github.com/osamu620/OpenHTJ2K/blob/3abbdb035d82401bc936047ffdee1a45115fc740/source/core/jph/jph.cpp#L74-L80
val
shall be hdr.SIZ->get_bitdepth(0) - 1
or hdr.SIZ->get_bitdepth(c) - 1
and
The signed case shall also be considered per I.5.3.1.
I will fix this as soon as possible. It won't take long :)
Thanks @osamu620 for looking into this. I just ran the fixed version, and I can confirm it now works (and the JPHs pass Jpylyzer validation)!
It seems that for JPH output, OpenHTJ2K writes an erroneous Bits per component value to the image header box. I'll illustrate this using one of OpenHTJ2K's conformance data images as a starting point.
Here's the command I used to create the JPH file:
Validation with jpylyzer results in this error:
This error means that the Bits per component value in the JPH image header is not consistent with the information in the code stream.
The Jpylyzer output for the image header box shows a bPCDepth of 9:
However, the ssizDepth values in the SIZ marker segment indicate a bit depth of 8 bits for all components:
I double checked with ExifTool, which confirms the odd bits per component values in the JPH image header box:
Possible underlying cause: ISO 15444-1 defines the BPC parameter as follows (section I.5.3.1):
So my best guess is that OpenHTJ2K directly writes the bits per component values to the image header box, without first subtracting 1.