Check on Rsiz may be too strict

[bitsgalore]

Currently Jpylyzer tests Rsiz validity as:

# rsiz must be either 0, 1 or 2
self.testFor("rsizIsValid", rsiz in [0, 1, 2])

However, this is based on an old (2002) draft of the standard (Table A.10 – Capability Rsiz parameter).

More recent versions of the standard allow many additional values, which are associated with profiles (Table A.10 + section A.10 Codestream restrictions conforming to this Recommendation).

Note that each of these profiles imply certain restrictions. I think checking for these is should remain out of Jpylyzer's scope.

[bitsgalore]

Done so far:

• Updated rSizMap with 5 profiles
• For JP2, removed validation of rSiz altogether

TODO: this doesn't cover all profiles, as there are some additional profiles that are defined by only the most significant 8 or 12 bits of Rsiz, which doesn't really work with the rSizMap approach. Also interpretation of CPF marker (HTJ2K) is linked to Rsiz capabilities (number of Pcpf_i values in CPF marker equals number of defined capabilities in Rsiz)

[bitsgalore]

Possible solution:

• Instead of reading Rsiz directly, extract separate "profile", "mainLevel" and "subLevel" values (as per Table A.10, lower entries)
• Then combine these 3 values into a string
• Use this string as lookup value in enumerationsMap

BUT with 10 possible SubLevel and 10 MainLevel values this means not practical to deal with all these combinations in emums map.

[bitsgalore]

Update, it seems the "profile", "mainLevel" and "subLevel" scheme has been changed since 2015 as well, see:

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

So apparently the 2 MSBs are now used to indicated extended capabilities.

[bitsgalore]

Done, including update to 2019 version:

https://github.com/openpreserve/jpylyzer/commit/89682b9f063294b4c120761fae7fd913a0792e76