JPEG Extended 12-bit decode emits an error-level diagnostic before successful fallback

[kgrizz-git]

Summary

python-gdcm 3.2.6 successfully decodes a valid DICOM JPEG Extended image (transfer syntax 1.2.840.10008.1.2.4.51) with Bits Allocated = 16 and Bits Stored = 12, but writes the following to native stderr:

Unsupported JPEG data precision 12

The returned uint16 pixels are correct. DCMTK and dcm4che produce the same SHA-256 (8cb01fc3dac525da7d1868dfb1b8aaf8524f75dbf226712c579eb0f226a1b6dc) for a wholly synthetic 64x48 MONOCHROME2 fixture.

Environment

• python-gdcm 3.2.6
• pydicom 2.4.5
• CPython 3.11.15 and 3.12.10
• macOS arm64

Minimal reproduction

import pydicom

ds = pydicom.dcmread("synthetic_monochrome_jpeg_extended_12_bit.dcm")
pixels = ds.pixel_array
print(pixels.shape, pixels.dtype, pixels.max())

The decode succeeds and yields (48, 64) uint16 4091, while native stderr contains the message above.

Investigation

JPEGCodec::SetPixelFormat() selects the initial fixed-precision JPEG decoder from Bits Allocated (16). It then encounters the 12-bit JPEG SOF, reports JERR_BAD_PRECISION, and the outer codec retries the 12-bit decoder successfully under GDCM_SUPPORT_BROKEN_IMPLEMENTATION.

The initial selection cannot simply be changed to Bits Stored: GDCM source comments note valid cases that store 12 bits in a 16-bit JPEG codestream.

Requested behavior

Could a successful fallback avoid emitting this error-level diagnostic? One possible direction is to make the probe diagnostic non-user-visible or use a precision-flexible backend.

For comparison, a local GDCM 3.2.7 build with GDCM_USE_JPEGTURBO=ON and libjpeg-turbo 3.2.0 decoded the complete synthetic matrix without stderr and produced the same pixel hashes. This is only an observation, not a request to make a particular dependency mandatory.

I can provide the small wholly synthetic DICOM fixture if useful.