obj_compress issue with low quality and same colour image

[Capital-Z]

Expected behaviour and actual behaviour.

Possible encoder (obj_compress) glitch when low output quality is requested and the whole image uses same colour, or most of it is the same colour.
Normally output picture would be similar to input.
Instead the output is darker and divided in 2 differently coloured regions.

Steps to reproduce the problem.

Compress the attached r.bmp (it is inside r.zip) with:

opj_compress -i r.bmp -o r.jp2 -n 3 -q 30

Also attached is the output when I run it (r_q30_n3.jp2.zip, both as zip due to upload file extension limitations).
The glitch persists with different values for quality and number of resolutions, but with higher quality it gets harder to notice. Using compression ratio (-r) or lossless compression works fine - output looks as expected. It is also fine with same (low) quality values with other JPEG 2000 tools.

Operating system

Windows. OpenJPEG compiled with multi-threaded support.

openjpeg version

2.5.0

r.zip
r_q30_n3.jp2.zip

[Capital-Z]

Workaround:
Append
-I
to the program arguments. Possibly the issue is with the default LGT 5/3 wavelet transform implementation, the CDF 9/7 transform looks to be working fine.
BTW. I was able to reproduce the problem with other images as well, no need to be greyscale or small size. As long as there is huge same colour area, issue is visible even with higher values for quality.

[Capital-Z]

Unfortunately the workaround is not always good.
R4_sc.zip
The attached image compressed with:
opj_compress -i R4_sc.bmp -o R4_sc.jp2 -q 40 -I
also corrupts the output (output in the attachment).
Not using the -I option in this case actually works. Seems like the bug is not related to wavelet transform, at least not directly. If somebody knows a way to predict when to use which transform can be very useful.