opj_set_decoded_resolution_factor(): bad interaction with opj_set_decode_area() and/or opj_decode()

[rouault]

There's a bad interaction when calling opj_set_decoded_resolution_factor() and then opj_set_decode_area() followed by opj_decode(), or just opj_decode()

If calling directly opj_decode(), that one will consider that the output image is at full resolution, instead of the resolution set in opj_set_decoded_resolution_factor(), unless manually modifying the image->comps[].factor values.

If calling opj_set_decoded_resolution_factor(), followed by opj_set_decode_area() and opj_decode(), and not manually setting image->comps[].factor values, currently (ie up to OpenJPEG 2.2.0 included) this somehow works on single-tiled images, provided that the coordinates passed to opj_set_decode_area() are expressed in the resolution coordinate space (ie divided by 2^res_level), instead of being passed relative to the reference grid (ie at full resolution). If doing this misuse of the API on a tiled image, not all tiles that intersect the area of interest will be selected (in practice onl the ones at the top level).
If doing this misuse of the API on a single tiled image with current master, the resulting image is corrupted due to only a subset of needed codeblocks being decoded.

The proper use of the API should be that opj_set_decode_area() is always called with coordinates expressed in the reference grid and the user isn't required to manually set the image->comps[].factor values.

Note: a potential way of having a code compatible of current versions and future versions is to do something like https://trac.osgeo.org/gdal/changeset/39925

[rouault]

@detonin rouault@8f92fc9 merged into master