search

osamu620 / OpenHTJ2K

An open source implementation of ITU-T Rec.814 | ISO 15444-15 (a.k.a. HTJ2K).
BSD 3-Clause "New" or "Revised" License
36 stars 10 forks source link

Rsiz value is not consistent with ISO/IEC 15444-15 #148

Closed bitsgalore closed 1 year ago

bitsgalore commented 1 year ago

If I use OpenHTJ2K to create either a JPH file or a codestream, opening these files in a Hex editor shows that they have the following Rsiz value:

40 00

However, Annex A (HTJ2K codestream syntax) of ISO/IEC 15444-15:2019 (E) says that the 14th bit of Rsiz shall be 1 for HTJ2K codestreams:

A.2 SIZ marker segment

Bit 14 of Rsiz shall be equal to 1.

Since the actual value is 0 OpenHTJ2K-produced files, it looks like the software isn't quite following the standard here.

osamu620 commented 1 year ago

Hi @bitsgalore, Thanks for raising this issue. Let me explain how Rsiz works with JPEG 2000 Part 15.

To use JPEG 2000 Part 15, a.k.a. HTJ2K, the CAP marker shall be signaled to tell decoders the capability HTJ2K features is required to decode this codestream.

The definition of Rsiz is in the spec of ISO/IEC 15444-1: 2019. Table A.10 in the spec, you can see the note at the bottom;

NOTE 1 – The two MSBs of Rsiz are used as follows:

Actually, ISO/IEC 15444-1:2019 does not specify the permitted values of the Rsiz parameter when the two MSBs are set to 0b01. This is a defect of the spec. So JPEG committee will replace the second bullet of Table A.10, Note 1 with a statement that:

Rsiz is 16-bit wide bit-field. According to the revised NOTE 1, the Rsiz value should be 

MSB(15) 14 13 12 11 10  9  8  7  6  5  4  3  2  1  0
0b    0  1  0  0  0  0  0  0  0  0  0  0  0  0  0  0 = 0x40 00

The revised explanation in the spec will be available in the ISO/IEC 15444-1 5th edition which is now under development.

bitsgalore commented 1 year ago

Hi @osamu620, thank you for the detailed explanation, this is really helpful!

So I think the main reason for my confusion here is that, based on your example, apparently ISO/IEC 15444-15:2019 assumes a bit numbering convention where (for a 2 byte variable) the most significant bit is assigned an index value of 15, and the least significant bit 0 (I was assuming the numbering was the other way around, i.e. like this).

Is this numbering scheme declared anywhere in the standard, because I can't remember having seen this before (and I've actually written a whole validator for JP2 based on the specs; I'm currently working on adding support for JPH and HTJ2K codestreams, which is how I came across this)?

This also makes me wonder about the internal consistency of the various parts of the JPEG 2000 standard. For example, Table A.36 of ISO/IEC 15444-1: 2015 refers to the 7 bits on the right side of a 1 byte parameter as the "last" bits. This is a bit confusing, as it seems to assume a numbering scheme where the bit indices increase from left to right (which is exactly the opposite of what ISO/IEC 15444-15:2019 is doing).

(BTW your explanation also made me realize that the ISO/IEC 15444-1:2015 version of the standard (which AFAIK the most recent one that isn't behind a paywall) is partially outdated, as it doesn't include the note at the bottom of Table A.10 that you're referring to.)

aous72 commented 1 year ago

Perhaps, I can chip in. JPEG2000 employs big-endian everywhere -- not sure if other standards do that.
That is why the bytes have this order.

Cheers, Aous.

Edit: You can join our discord server -- link valid for a week. https://discord.gg/frneBkKf

bitsgalore commented 1 year ago

Hi @aous72 ,

Thanks. I'm aware of JPEG 2000 using Big-Endian, but Endianness only defines the order in which the bytes are interpreted (in this case: the 2 bytes that make up Csiz). It doesn't necessarily say anything about the numbering of individual bits within one or more bytes. There's a good explanation in this Stack Overflow thread:

https://stackoverflow.com/questions/16803397/can-endianness-refer-to-bits-order-in-a-byte

However, this answer mentions (under "Bit labels or bit numbering") that the most common approach for numbering bits is "to label the bits according to their significance, with bit 0 referring to the least significant bit". I wasn't aware of this convention before, but it does correspond to how ISO/IEC 15444-15 does things. Still, it would be helpful if the standard was explicit about the convention used.

EDIT: thanks for the Discord link, I just joined!