Clinical DICOM loading error, PixelData larger than remaining bytes in file, but images look OK

mikebind
Fri, 06 Feb 2026 17:55:03 +0000
Support

When I download an image series directly from our clinical PACS and import it into Slicer, I get the following error message repeated for each .dcm file:

“E: DcmElement: PixelData (7fe0,0010) larger (4294967295) than remaining bytes (0) in file, premature end of stream”

If I load the series into the scene from the database, it appears to load fine, and the image data seems correct, so I don’t think the problem is actually missing data. However, the error does break interactions in the DICOM database, like reviewing metadata in the “DICOM File Metadata” window. The search/filter on DICOM tags doesn’t do anything because of the encountered error, and reports:

“E: DcmElement: PixelData (7fe0,0010) larger (4294967295) than remaining bytes (0) in file, premature end of stream

E: can’t change to unencapsulated representation for pixel data

E: can’t determine ‘PhotometricInterpretation’ of decompressed image

E: mandatory attribute ‘PhotometricInterpretation’ is missing or can’t be determined

W: Rendering of DICOM image failed for thumbnail failed: Missing attribute”

I tried to investigate the possible issues with pydicom, and encountered this warning:

“UserWarning: The (0028,0101) ‘Bits Stored’ value (12-bit) doesn’t match the JPEG 2000 data (16-bit). It’s recommended that you change the ‘Bits Stored’ value”

My guess is that this is the root of the problem: only 12 bits of data represent stored clinical data, but the lossless compression is in 16-bit chunks. I think the intended procedure would be to uncompress to 16-bit chunks and then ignore 4 of the bits per pixel when reconstructing the image arrays, but something in the Slicer machinery doesn’t like that mismatch between 12 and 16. Somehow, the actual reconstruction of the image arrays seems to be working fine, so some piece of the import code is interpreting everything correctly. I’m not enough of a DICOM expert to tell whether the PACS is storing invalid DICOM, or whether Slicer’s DICOM import machinery is incorrectly complaining. Because it is clinical data, I can’t share the files themselves, but I am happy to run any investigative tests that might be helpful in sorting this out. I also can’t modify the images stored in our PACS, but If our scanners are actually spitting out invalid DICOM images, we can alert the scanner manufacturer if that’s where the problem lies.

4 posts - 2 participants