DCMTK

When DCMTK encounters an element of OB or UN value representation and undefined length (len=0xFFFFFFFF) while reading/parsing a DICOM dataset, currently these attributes are interpreted as sequences. However, we have received a sample image generated by a GE Vingmed Vivid E9 ultrasound device containing a private tag with OB value representation and undefined length, where the content of the items is not a DICOM sequence, but compressed pixel data (compressed with an algorithm that is not even "compatible" to the current transfer syntax). Such files cannot be read or processed with DCMTK currently, because the dcmdata parser tries to interpret the pixel data fragments as DICOM sequence items, and of course fails.

Graceful handling of such files would require the introduction of a new VR class that works similar to DcmPixelData, but never attempts to decompress anything, i.e. ignores the compression/decompression codec stuff. Depending on a global setting, the parser in DcmItem could then choose to either interpet incoming elements of these types as SQ (as currently), or to read them as "opaque compressed pixel-data like stuff", which would be written exactly as read and never decompressed or converted between little and big endian.

Command line options should then be added to the various command line tools reading DICOM files, to either keep the current behaviour (default) or switch to handling such elements as opaque pixel data.

A sample file (confidential) is available in /share/dicom/contrib/20150114_undefined_length_ob_private_data/