Bug #427
closed
JPEG Decoder does not report an error with malformed pixel data
100%
Description
see: http://forum.dcmtk.org/viewtopic.php?f=1&t=3475
Extract from the dump:
(0002,0010) UI =JPEGLossless:Non-hierarchical-1stOrderPrediction # 22, 1 TransferSyntaxUID ... (7fe0,0010) OW fffe\e000\0000\0000\fffe\e000\b39a\0003\d8ff\c3ff\0b00\0210\0200... # 242610, 1 PixelData
Pixel data on the main dataset level is not encapsulated as Pixel Items. You won't get any warnings or errors from using dcmdjpeg on such a file, but the pixel data is not decompressed, since the decoder assumes that it is already decompressed (for instance in Icon Image Sequence).
The same problem will probably show up in other supported compression types in DCMTK.
Updated by Andrew Chiw over 12 years ago
- Subject changed from JPEG-Decoder meldet keinen Fehler bei fehlerhafter Kodierung der Pixel-Daten to JPEG Decoder does not report an error with malformed pixel data
Updated by Jörg Riesmeier almost 12 years ago
Also see this posting: http://forum.dcmtk.org/viewtopic.php?f=1&t=3842&p=15299#p15299
Updated by OFFIS DICOM Team about 11 years ago
- Assignee set to Michael Onken
If the transfer syntax is "encapsulated" and pixel data on main dataset level is "uncompressed" (e.g. length other than undefined), then the decoder should bail out with an error.
Note that uncompressed pixel data within a compressed dataset is permitted in the Icon Image Sequence, so this error should only be triggered on the main dataset level.
Updated by Michael Onken over 8 years ago
The forum posting denoted under bullet 2 (http://forum.dcmtk.org/viewtopic.php?f=1&t=3842&p=15299#p15299) refers to a different problem, which was handled in Bug #571.
Updated by Michael Onken over 8 years ago
- Status changed from New to Closed
- % Done changed from 0 to 100
Closed with commit 1677f2.
Test files are found in OFFIS' (private) image collection under the related issue number.