All IMF Profile Selections Result in PART1

[anderson1077]

When selecting the IMF profile, the evaluation of the RSIZ always results in 0x0000. This skips using any of the IMF constraints or settings, and creates a generic PART1 container.

The issue is in obj_compress.c at line 1212 (multiplication by 0):
parameters->rsiz = (OPJ_UINT16)(profile | (sublevel << 4) | mainlevel);

[rouault]

I don't understand what you mean by multiplication by zero. And I can't confirm the bug. Using opj_compress -IMF 2K generates a file with rsiz=1024

[anderson1077]

In looking at the code it was creating a J2C with 0x0000 at byte offset 0x06, which is where the profile is stored. I checked the file with a hex editor and also with kdu_shows from Kakadu. jid-writer also rejects the resulting J2C as non-IMF profile. Here's the command I ran if you want to try to recreate, source is 3840x2160x16bpc:

opj_compress -i 0000000.tif -o 0000000.j2c -IMF 4K_R,mainlevel=7,sublevel=0,framerate=24

[anderson1077]

When using the default build, the resulting J2C doesn't present as an IMF Sprofile, but rather a PART1 Sprofile. Here is a screenshot from kdu_shows showing the Sprofile.

[rouault]

When using the default build, the resulting J2C doesn't present as an IMF Sprofile, but rather a PART1 Sprofile.

Might be an issue with kdu_show. What I can tell is that my dump utility at shows
2055
with your 'opj_compress -i 0000000.tif -o 0000000.j2c -IMF 4K_R,mainlevel=7,sublevel=0,framerate=24' command line. Things seem to be all good for me.