The Pixel Data in Pixel Data (7FE0,0010), Float Pixel Data (7FE0,0008) or Double Float Pixel Data (7FE0,0009) is not handled in any special manner. The Pixel Data is first encoded as sequential uncompressed Frames without encapsulation, and then is handled as part of the byte stream fed to the Deflate compressor in the same manner as the Value Field of any other Data Element.

This Transfer Syntax is particularly useful for compression of objects without Pixel Data, such as structured reports. It is not particularly effective at image compression, since any benefit obtained from compressing the non-pixel data is offset by less effective compression of the much larger Pixel Data.

A freely available reference implementation of the Deflate compressor may be found in the zlib package, which may be downloaded from http://www.zlib.net/.

Although the encoded stream may be padded by a trailing NULL byte, the end of the deflated bit stream will be indicated by the delimiter that will occur before the padding.

This requirement to support the (uncompressed) Explicit VR Little Endian Transfer Syntax is in order to ensure full-fidelity exchange of VR information in the case that the Association Acceptor does not support the Deflated Explicit VR Little Endian Transfer Syntax. The requirement specified in Section 10.1 of this Part, that the Default Implicit VR Little Endian Transfer Syntax be supported by all implementations except those that only have access to lossy compressed Pixel Data, is not waived. In other words, an implementation must support all three Transfer Syntaxes.

There are no such "baseline" requirements on media, since such requirements are at the discretion of the Media Application Profile. Furthermore, sufficient object "management" information should be present in the DICOMDIR even if an individual application cannot decompress an instance encoded with the Deflated Explicit VR Little Endian Transfer Syntax.