ISO/IEC 15444-1:2019 (E) compared with 'cio.h'

[szukw000]

The file 'cio.h' contains the following lines:

#if defined(OPJ_BIG_ENDIAN)

#define opj_write_bytes opj_write_bytes_BE
#define opj_read_bytes opj_read_bytes_BE

#else

#define opj_write_bytes opj_write_bytes_LE
#define opj_read_bytes opj_read_bytes_LE

#endif

That means:
on BE-machines numbers are written or read in BE.
on LE-machines numbers are written or read in LE.

ISO/IEC 15444-1:2019 (E) on page 13 explicitly states:

All parameter values in marker segments are big-endian.

Here are some examples.

On page 144:
LBox: Box length. 4-byte big-endian unsigned integer.
TBox: Box type. 4-byte big-endian unsigned integer.

On page 145:
XLBox: Box extended length. 8-byte big-endian unsigned integer.

On page 147:
MinV: Minor version. 4-byte big-endian unsigned integer.

On page 149 (for JP2 Header box):
HEIGHT: Image area height. 4-byte big-endian unsigned integer.
WIDTH: Image area width. 4-byte big-endian unsigned integer.
NC: Number of components. 2-byte big-endian unsigned integer.

Am I mistaken or does that mean: on LE-machines too that must be
big-endian unsigned integers?

This would (roughly) mean:
READ on LE: read BE, then swap.
READ on BE: read BE.

WRITE on LE: swap, then write BE.
WRITE on BE: write BE.

Although on page 154 of ISO/IEC 15444-1:2019 (E) there seems to be
a bug:
Bi: (...) 1-byte big-endian unsigned integer.

winfried

[rouault]

That means:
on BE-machines numbers are written or read in BE.
on LE-machines numbers are written or read in LE.

No, that means that depending on the endianness of the architecture, a different function is needed to correctly read/write correctly big endian integers. The naming is a bit odd, and having both functions compiled is a bit confusing. But the lib eventually does the right thing

[szukw000]

@rouault ,

No, that means that depending on the endianness of the architecture, a different function is >needed to correctly read/write correctly big endian integers. The naming is a bit odd, and >having both functions compiled is a bit confusing. But the lib eventually does the right thing

That confuses me.

• Which different function do you mean? Where shall it take place?

• Which naming is a bit odd?

• Which lib does the right thing? What is the right thing?

winfried

[rouault]

you raised the issue, I gave some hints, you should manage to figure it by yourself by digging more :-)

Closing this as unless otherwise proven, openjpeg behaves correctly regarding endianness handling and we have enough valid open issues.