nvjpeg2k error 3 (Bad jpeg) on valid JPEG 2000 aerial photos that OpenJPEG and ffmpeg decode identically

Version

nvImageCodec 0.9.0.20 with nvjpeg2k 0.11.0.51, and 0.10.0.9 with nvjpeg2k 0.12.0.58

Describe the bug.

The GPU decoder (BackendKind.GPU_ONLY) refuses about 3 of 4 public aerial photos from North Rhine-Westphalia (NRW, Germany) with nvjpeg2k error #3 (Bad jpeg) in nvjpeg2kDecodeImage. In a pull of 2,390 files, 606 were decoded and 1,784 were refused.

Why I think the files are valid

• jpylyzer reports them as valid JP2.
• OpenJPEG 2.5 decodes them in strict mode with no warnings.
• ffmpeg's own JPEG 2000 decoder gives pixel-identical output to OpenJPEG on 20 of 20 files (10 accepted, 10 refused by nvjpeg2k).
• A packet-header walk agrees with every PLT packet length (33,524 packets per file). Header values (code-block size, passes, zero bit planes, Lblock, segment lengths) overlap fully between accepted and refused files.
• The metadata of 100 accepted and 100 refused files is byte-identical apart from location fields. That covers every JP2 box (ftyp, ihdr, colr, cdef, asoc, uuid) and every main and tile-part header marker (SIZ, COD, QCD, COM, SOT, PLT). The encoder comment is ECW JPEG 2000 SDK v3.3.0.161 in all 200.
• Refusal is per file and repeatable. It happens when the file is decoded alone in a fresh process, first or later in a batch, and for every sub-region (2x2, 4x4, 8x8 split).

Not the usual causes

• The documentation says error 3 means the stream cannot be parsed, likely corrupted, while error 4 is for valid but unsupported streams. These files are valid by two independent decoders, so error 3 looks wrong in itself. Error 4, with the unsupported feature named, would already help.
• The documentation asks for a stream or device synchronise between two decodes that reuse a decode state. That doesn't apply here, because the refused files also fail as the only decode in a fresh process.

A second problem in 0.10.0.9 with nvjpeg2k 0.12.0.58
After a successful decode of the accepted file, cleanup fails with an illegal memory access and no new decoder can be created afterwards (log below). 0.9.0.20 with 0.11.0.51 does not show this.

A small third point
The whole .jp2 file (boxes jP ftyp jp2h asoc uuid jp2c) fails at parsing with "Failed to get image info". The bare codestream parses fine.

Files (public, licence dl-de/zero-2.0, folder www.opengeodata.nrw.de/produkte/geobasis/lusat/akt/dop/dop_jp2_f10/)

• refused dop10rgbi_32_361_5666_1_nw_2025.jp2
• refused dop10rgbi_32_453_5741_1_nw_2026.jp2
• accepted dop10rgbi_32_327_5675_1_nw_2025.jp2

Each file is one tile of 10,000 x 10,000 pixels, 4 components at 8 bit, reversible 5/3, 8 levels, RPCL, 1 layer, EPH, PLT, written by ECW SDK 3.3. The folder holds the current flights, so a file may be replaced later.

Minimum reproducible example

from nvidia import nvimgcodec as nv
name = "dop10rgbi_32_361_5666_1_nw_2025"
data = open(name + ".jp2", "rb").read().split(b"jp2c", 1)[1]   # the bare codestream after the jp2c box header
dec = nv.Decoder(device_id=0, backends=[nv.Backend(nv.BackendKind.GPU_ONLY)])
img = dec.decode(nv.CodeStream(data), params=nv.DecodeParams(color_spec=nv.ColorSpec.UNCHANGED))
print(img)  # None for the refused files, an image for the accepted one

Environment details

Google Colab, Tesla T4, driver 580.82.07, Python 3.13
pip wheels nvidia-nvimgcodec-cu12 and nvidia-nvjpeg2k-cu12

Relevant log output

[nvjpeg2k_decoder] Could not decode jpeg2k code stream - nvjpeg2k error #3 (Bad jpeg) when running nvjpeg2kDecodeImage(...)

Second problem, 0.10.0.9 with nvjpeg2k 0.12.0.58, after a successful decode
nvjpeg2k error #5 (allocator failure) when running nvjpeg2kDecodeStateDestroy
CUDA Runtime failure '#700' an illegal memory access was encountered
RuntimeError Internal error - Could not create decoder. Code 6

Other/Misc.

I have the three bare codestreams (about 80 MB, with SHA-256 checksums) and can share them if the files on the NRW server change.

Check for duplicates

• I have searched the open bugs/issues and have found no duplicates for this bug report