7

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?

Anders Gustafsson
  • 15,837
  • 8
  • 56
  • 114
martinez314
  • 12,162
  • 5
  • 36
  • 63

3 Answers3

7

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.

rkh
  • 1,761
  • 1
  • 20
  • 30
3

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.

Mark Adler
  • 101,978
  • 13
  • 118
  • 158
  • Do you know of something that will inflate this data? I figured out the offsets, but didn't know about the trailer (so that helped). I've tried to inflate them using several zlib-based tools/implementations, but everything fails. Osirix can read them, so I know the data must be valid. Is the deflate header valid? – martinez314 Jul 23 '15 at 21:26
  • Yes, zlib will. That's what I used. The deflate data is valid. You need to do a raw inflate. See the `inflateInit2()` documentation. – Mark Adler Jul 23 '15 at 21:37
2

You could download some test DICOM images encoded in 1.2.840.10008.1.2.1.99 transfer syntax from here:

http://www.dclunie.com/images/compressed/

When you unpack archive, images with Deflated transfer syntax are named: name_dfl

That transfer syntax is only one that compress whole of the DICOM data but when I opened it in Hex Editor XVI32 it looks like metadata of dicom file is uncompressed so you could read transfer syntax, but I could not find other images coded in that transfer syntax so I'm not sure.

Springfield762
  • 221
  • 1
  • 11