DICOM Deflated Explicit VR Little Endian (1.2.840.10008.1.2.1.99)

Question

How is the data in this transfer syntax organized? A description from the standard:

This Transfer Syntax applies to the encoding of the entire DICOM Data Set. The entire Data Set is first encoded according to the rules specified in Section A.2. The entire byte stream is then compressed using the "Deflate" algorithm defined in Internet RFC 1951.

Initially I took this to mean the entire DICOM file itself was gzipped. But if the entire file is gzipped, including the header which contains the identifying transfer syntax, how would a parser/viewer be able to read the transfer syntax to know it is gzipped?

From the perspective of a viewer which is given a file of this type, how can it know it is of this transfer syntax? Look for a GZIP header?

Are there any publicly available sample images which use this transfer syntax?

Answer 1

If I recall correctly, DICOM divides most streams into two Datasets, the first is the DICOM file meta information, which is always encoded as Explicit VR Little Endian Transfer Syntax, the second Dataset is encoded as indicated in the file meta information.

From:

http://medical.nema.org/dicom/2013/output/chtml/part10/chapter_7.html

The "Transfer Syntax UID" tag description is:

Uniquely identifies the Transfer Syntax used to encode the following Data Set. This Transfer Syntax does not apply to the File Meta Information.

Answer 2

For the examples pointed to by @Springfield762, each of the _dfl files had a valid deflate stream from 300-some-odd bytes to eight bytes from end. They each decompressed to something about the length of the corresponding file in the archive without the _dfl suffix, but the data was not the same. There is additional decoding needed to get from the decompressed data to the original.

image_dfl has a deflate stream that starts at offset 334, report_dfl at 348, and wave_dfl at 314. They decompress to 262682, 6178, and 62408 bytes respectively.

The last eight bytes after each deflate stream are the same as a gzip trailer, i.e. the CRC-32 of the decompressed data (four bytes) followed by the uncompressed length in little endian order. Those both match with the data that results from decompressing the deflate stream.

The bytes that precede the deflate data are not a gzip header.