Even Rouault

openjpeg is insufficiently maintained (by me in particular :-)), so adding more stuff that could rot easily (as I won't use it personnally) is not super compelling. You might want...

There's no evidence the issue comes from openjpeg. Perhaps the way you create the PDF file itself.

> the OK-file ist correctly constructed, both ERR-files are not. I don't agree with that analysis. Having several PLT boxes is authorized by the standard as far as I remember,...

@szukw000 "A.7.3 Packet length, tile-part header (PLT)" mentions "There may be multiple PLT marker segments per tile". And openjpeg just parses them without doing any further processing with what they...

> That last comment suggests to me that the problem was in GDAL's VSI module No, the problem in this ticket is openjpeg specific. Can be reproduced with opj_decompress only...

hum, so this breaks the NR-DEC-issue411-ycc420.jp2-115-decode-md5 test case of the test suite. Either my suggestion is wrong, either this test case needs refreshing

> How can this work if we only increment one component of the pixel? are there cases where `sycc420_to_rgb` will just convert luma without bllue and red (it seems odd...

upon reflection, my suggestion to remove ++cb and ++cr completely seems wrong to me. The current code of master should be fine. I'm not sure why the overflow comes from,...

@Young-X Please verify if that occurs still with latest master. If so, please attach the reproducer to the ticket

Floating point data is only supported in JPEG2000 Part 10, an extension to the baseline standard, that is very rarely implemented in general, and is not implemented by libopenjp2. The...