A.4 Transfer Syntaxes For Encapsulation of Encoded Pixel Data
Prev | A Transfer Syntax Specifications (Normative) | Next

## A.4 Transfer Syntaxes For Encapsulation of Encoded Pixel Data

These Transfer Syntaxes apply to the encoding of the entire DICOM Data Set, even though the image Pixel Data (7FE0,0010) portion of the DICOM Data Set is the only portion that is encoded by an encapsulated format. This implies that when a DICOM Message is being encoded according to an encapsulation Transfer Syntax the following requirements shall be met:

1. The Data Elements contained in the Data Set structure shall be encoded with Explicit VR (with a VR Field) as specified in Section 7.1.2.

2. The encoding of the overall Data Set structure (Data Element Tags, Value Length, etc.) shall be in Little Endian as specified in Section 7.3.

3. The encoding of the Data Elements of the Data Set shall be as follows according to their Value Representations:

   - For all Value Representations defined in this part of the DICOM Standard, except for the Value Representations OB and OW, the encoding shall be in Little Endian as specified in Section 7.3.

   - For the Value Representations OB and OW, the encoding shall meet the following specification depending on the Data Element Tag:

     - Data Element (7FE0,0010) Pixel Data may be encapsulated or native.

       It shall be encapsulated if present in the top-level Data Set (i.e., not nested within a Sequence Data Element).

       ### Note

       The distinction between fixed value length (native) and undefined value length (encapsulated) is present so that the top level Data Set Pixel Data can be compressed (and hence encapsulated), but the Pixel Data within an Icon Image Sequence may or may not be compressed.

       If native, it shall have a defined Value Length, and be encoded as follows:

       - where Bits Allocated (0028,0100) has a value greater than 8 shall have Value Representation OW and shall be encoded in Little Endian;

       - where Bits Allocated (0028,0100) has a value less than or equal to 8 shall have the Value Representation OB or OW and shall be encoded in Little Endian.

       ### Note

       That is, as if the transfer syntax were Explicit VR Little Endian.

       If encapsulated, it has the Value Representation OB and is a sequence of bytes resulting from one of the encoding processes. It contains the encoded pixel data stream fragmented into one or more Item(s). This Pixel Data Stream may represent a Single or Multi-frame Image. See Table A.4-1 and Table A.4-2.

       - The Length of the Data Element (7FE0,0010) shall be set to the Value for Undefined Length (FFFFFFFFH).

       - Each Data Stream Fragment encoded according to the specific encoding process shall be encapsulated as a DICOM Item with a specific Data Element Tag of Value (FFFE,E000). The Item Tag is followed by a 4 byte Item Length field encoding the explicit number of bytes of the Item.

         ### Note

         Whether more than one fragment per frame is permitted or not is defined per Transfer Syntax.

       - All items containing an encoded fragment shall be made of an even number of bytes greater or equal to two. The last fragment of a frame may be padded, if necessary, to meet the sequence item format requirements of the DICOM Standard.

         ### Note

         1. Any necessary padding may be added in the JPEG or JPEG-LS compressed data stream as per ISO 10918-1 and ISO 14495-1 such that the End of Image (EOI) marker ends on an even byte boundary, or may be appended after the EOI marker, depending on the implementation.

         2. ISO 10918-1 and ISO 14495-1 define the ability to add any number of padding bytes FFH before any marker (all of which also begin with FFH). It is strongly recommended that FFH padding bytes not be added before the Start of Image (SOI) marker.

       - The first Item in the Sequence of Items before the encoded Pixel Data Stream shall be a Basic Offset Table item. The Basic Offset Table Item Value, however, is not required to be present:

         - When the Item Value is not present, the Item Length shall be zero (00000000H) (see Table A.4-1).

         - When the Item Value is present, the Basic Offset Table Item Value shall contain concatenated 32-bit unsigned integer values that are byte offsets to the first byte of the Item Tag of the first fragment for each frame in the Sequence of Items. These offsets are measured from the first byte of the first Item Tag following the Basic Offset Table item (see Table A.4-2).

           ### Note

           1. For a Multi-Frame Image containing only one frame or a Single Frame Image, the Basic Offset Table Item Value may be present or not. If present it will contain a single 00000000H value.

           2. Decoders of encapsulated pixel data, whether Single Frame or Multi-Frame, need to accept both an empty Basic Offset Table (zero length) and a Basic Offset Table filled with 32 bit offset values.

       - This Sequence of Items is terminated by a Sequence Delimiter Item with the Tag (FFFE,E0DD) and an Item Length Field of Value (00000000H) (i.e., no Value Field shall be present).

     - Data Element (60xx,3000) Overlay Data

       - shall have the Value Representation OB or OW and shall be encoded in Little Endian.

     - Data Element (5400,1010) Waveform Data has the Value Representation specified in its Explicit VR Field. The component points shall be encoded in Little Endian.

     - Data Elements (0028,1201), (0028,1202), (0028,1203), (0028,1204) Red, Green, Blue, Alpha Palette Lookup Table Data have the Value Representation OW and shall be encoded in Little Endian.

       ### Note

       Previous versions of the Standard either did not specify the encoding of Data Elements 0028,1201), (0028,1202), (0028,1203) in this Part, but specified a VR of US or SS in PS3.6-1993, or specified OW in this Part but a VR of US, SS or OW in PS3.6-1996. The actual encoding of the values and their byte order would be identical in each case, though the explicitly encoded VR field would be different. However, an explicit VR of US or SS cannot be used to encode a table of 216 elements, since the Value Length is restricted to 16 bits.

     - Data Elements (0028,1101), (0028,1102),(0028,1103) Red, Green, Blue Palette Lookup Table Descriptor have the Value Representation SS or US (depending on rules specified in the IOD in PS3.3), and shall be encoded in Little Endian. The first and third values are always interpreted as unsigned, regardless of the Value Representation.

     - Data Elements (0028,1221), (0028,1222), (0028,1223) Segmented Red, Green, Blue Palette Color Lookup Table Data have the Value Representation OW and shall be encoded in Little Endian.

     - Data Element (0028,3006) LUT Data has the Value Representation US or OW and shall be encoded in Little Endian.

       ### Note

       Previous versions of the Standard did not specify the encoding of these Data Elements in this Part, but specified a VR of US or SS in PS3.6-1998. However, an explicit VR of US or SS cannot be used to encode a table of 216 elements, since the Value Length is restricted to 16 bits. Hence a VR of OW has been added. Moreover this element is always unsigned, therefore the VR of SS has been removed. The actual encoding of the values and their byte order would be identical in each case, though the explicitly encoded VR field would be different.

     - Data Element (0028,3002) LUT Descriptor has the Value Representation SS or US (depending on rules specified in the IOD in PS3.3), and shall be encoded in Little Endian. The first and third values are always interpreted as unsigned, regardless of the Value Representation.

     - Data Element (0028,1408) Blending Lookup Table Data has the Value Representation OW and shall be encoded in Little Endian.

     - Data Elements (0066,0025) Vertex Point Index List, (0066,0024) Edge Point Index List, (0066,0023) Triangle Point Index List and (0066,0029) Primitive Point Index List have the Value Representation OW and shall be encoded in Little Endian and are always interpreted as unsigned.

### Note

1. For Data encoded with the Value Representation OB, the Data encoding is unaffected by Little Endian or Big Endian byte ordering.

2. Encoding of Curve Data and Audio Sample Data was previously defined but has been retired. See PS3.5-2004.

Table A.4-1. Example for Elements of an Encoded Single-Frame Image Defined as a Sequence of Three Fragments Without Basic Offset Table Item Value

Pixel Data Element Tag | Value Representation | Data Element Length | Data Element
--- | --- | --- | ---
(7FE0, 0010) with VR of OB | OB | 0000H Reserved | FFFF FFFFH undefined length | Basic Offset Table with NO Item Value | First Fragment (Single Frame) of Pixel Data
Item Tag | Item Length | Item Tag | Item Length | Item Value
(FFFE, E000) | 0000 0000H | (FFFE, E000) | 0000 04C6H | Compressed Fragment
4 bytes | 2 bytes | 2 bytes | 4 bytes | 4 bytes | 4 bytes | 4 bytes | 4 bytes | 04C6H bytes

Table A.4-1b. Example for Elements of an Encoded Single-Frame Image Defined as a Sequence of Three Fragments Without Basic Offset Table Item Value (continued)

Data Element Continued
Second Fragment (Single Frame) of Pixel Data | Third Fragment (Single Frame) of Pixel Data | Sequence Delimiter Item
--- | --- | ---
Item Tag | Item Length | Item Value | Item Tag | Item Length | Item Value | Sequence Delim. Tag | Item Length
(FFFE, E000) | 0000 024AH | Compressed Fragment | (FFFE, E000) | 0000 0628H | Compressed Fragment | (FFFE,E0DD) | 0000 000H
4 bytes | 4 bytes | 024AH bytes | 4 bytes | 4 bytes | 0628Hbytes | 4 bytes | 4 bytes

Table A.4-2. Examples of Elements for an Encoded Two-Frame Image Defined as a Sequence of Three Fragments with Basic Table Item Values

Pixel Data Element Tag | Value Representation | Data Element Length | Data Element
--- | --- | --- | ---
(7FE0, 0010) with VR of OB | OB | 0000H Reserved | FFFF FFFFH undefined length | Basic Offset Table with Item Value | First Fragment (Frame 1) of Pixel Data
Item Tag | Item Length | Item Value | Item Tag | Item Length | Item Value
(FFFE, E000) | 0000 0008H | 0000 0000H 0000 0646H | (FFFE, E000) | 0000 02C8H | Compressed Fragment
4 bytes | 2 bytes | 2 bytes | 4 bytes | 4 bytes | 4 bytes | 0008H bytes | 4 bytes | 4 bytes | 02C8H bytes

Table A.4-2b. Examples of Elements for an Encoded Two-Frame Image Defined as a Sequence of Three Fragments with Basic Table Item Values (continued)

Data Element Continued
Second Fragment (Frame 1) of Pixel Data | Third Fragment (Frame 2) of Pixel Data | Sequence Delimiter Item
--- | --- | ---
Item Tag | Item Length | Item Value | Item Tag | Item Length | Item Value | Sequence Delimiter Tag | Item Length
(FFFE, E000) | 0000 036EH | Compressed Fragment | (FFFE, E000) | 0000 0BC8H | Compressed Fragment | (FFFE, E0DD) | 0000 0000H
4 bytes | 4 bytes | 036EH bytes | 4 bytes | 4 bytes | 0BC8H bytes | 4 bytes | 4 bytes

### A.4.1 JPEG Image Compression

The International Standards Organization ISO/IEC JTC1 has developed an International Standard, ISO/IS-10918-1 (JPEG Part 1) and an International Draft Standard, ISO/IS-10918-2 (JPEG Part 2), known as the JPEG Standard, for digital compression and coding of continuous-tone still images (see Annex F for further details).

A DICOM Transfer Syntax for JPEG Image Compression shall be identified by a UID value, appropriate to its JPEG coding process, chosen from Table A.4-3.

Table A.4-3. DICOM Transfer Syntax UIDs for JPEG

DICOM Transfer Syntax UID | JPEG coding process | JPEG description
--- | --- | ---
1.2.840.10008.1.2.4.50 | 1 | baseline
1.2.840.10008.1.2.4.51 | 2(8-bit),4(12-bit) | extended
1.2.840.10008.1.2.4.57 | 14 | lossless, non-hierarchical
1.2.840.10008.1.2.4.70 | 14 (Selection Value 1) | lossless, non-hierarchical, first-order prediction

### Note

DICOM identifies, to increase the likelihood of successful association, three Transfer Syntaxes for Default JPEG Compression Image processes (see Section 8.2.1 and Section 10).

If the object allows multi-frame images in the pixel data field, then each frame shall be encoded separately. Each fragment shall contain encoded data from a single-frame image.

### Note

Though a fragment may not contain encoded data from more than one frame, the encoded data from one frame may span multiple fragments. See note in Section 8.2.

For all images, including all frames of a multi-frame image, the JPEG Interchange Format shall be used (the table specification shall be included).

### Note

This refers to the ISO 10918-1 "interchange format", not the DIS 10918-5 JPEG File Interchange Format (JFIF).

If images with Photometric Interpretation (0028,0004) YBR_FULL_422 or YBR_PARTIAL_422, are encoded with JPEG coding Process 1 (non hierarchical with Huffman coding), identified by DICOM Transfer Syntax UID "1.2.840.10008.1.2.4.50"the minimum compressible unit is YYCBCR, where Y, CB, and CR are 8 by 8 blocks of pixel values. The data stream encodes two Y blocks followed by the corresponding CB and CR blocks.

### A.4.2 RLE Compression

Annex G defines a RLE Compression Transfer Syntax. This transfer Syntax is identified by the UID value "1.2.840.10008.1.2.5". If the object allows multi-frame images in the pixel data field, then each frame shall be encoded separately. Each frame shall be encoded in one and only one Fragment (see Section 8.2).

### A.4.3 JPEG-LS Image Compression

The International Standards Organization ISO/IEC JTC1 has developed an International Standard, ISO/IS-14495-1 (JPEG-LS Part 1), for digital compression and coding of continuous-tone still images (see Annex F for further details).

A DICOM Transfer Syntax for JPEG-LS Image Compression shall be identified by a UID value, appropriate to its JPEG-LS coding process.

Two Transfer Syntaxes are specified for JPEG-LS:

1. A Transfer Syntax with a UID of "1.2.840.10008.1.2.4.80 ", which specifies the use of the lossless mode of JPEG-LS. In this mode the absolute error between the source and reconstructed images will be zero.

2. A Transfer Syntax with a UID of "1.2.840.10008.1.2.4.81 ", which specifies the use of the near-lossless mode of JPEG-LS. In this mode, the absolute error between the source and reconstructed images will be constrained to a finite value that is conveyed in the compressed bit stream. Note that this process can, at the discretion of the encoder, be used to compress images with an error constrained to a value of zero, resulting in no loss of information.

If the object allows multi-frame images in the pixel data field, then each frame shall be encoded separately. Each fragment shall contain encoded data from a single-frame image.

### Note

Though a fragment may not contain encoded data from more than one frame, the encoded data from one frame may span multiple fragments. See note in Section 8.2.

For all images, including all frames of a multi-frame image, the JPEG-LS Interchange Format shall be used (all parameter specifications shall be included).

### A.4.4 JPEG 2000 Image Compression

The International Standards Organization ISO/IEC JTC1 has developed an International Standard, ISO/IS 15444-1 (JPEG 2000 Part 1), for digital compression and coding of continuous-tone still images (see Annex F for further details).

A DICOM Transfer Syntax for JPEG 2000 Image Compression shall be identified by a UID value, appropriate to the choice of JPEG 2000 coding process.

Two Transfer Syntaxes are specified for JPEG 2000 Part 1:

1. A Transfer Syntax with a UID of "1.2.840.10008.1.2.4.90 ", which specifies the use of the lossless (reversible) mode of JPEG 2000 Part 1 (ISO/IEC 15444-1) (i.e., the use of a reversible wavelet transformation and a reversible color component transformation, if applicable, and no quantization).

2. A Transfer Syntax with a UID of "1.2.840.10008.1.2.4.91", which specifies the use of either:

   1. the lossless (reversible) mode of JPEG 2000 Part 1 (ISO/IEC 15444-1) (i.e., the use of a reversible wavelet transformation and a reversible color component transformation, if applicable, and no quantization or code stream truncation), or

   2. the lossy (irreversible) mode of JPEG 2000 Part 1 (ISO/IEC 15444-1) (i.e., the use of an irreversible wavelet transformation and an irreversible color component transformation, if applicable, and optionally quantization, or the use of a reversible wavelet transformation and a reversible color component transformation, if applicable, followed by code stream truncation).

   The choice reversible versus irreversible is at the discretion of the sender (SCU or FSC/FSU).

   ### Note

   When using the irreversible wavelet transformation and an irreversible color component transformation, if applicable, even if no quantization is performed, some loss will always occur due to the finite precision of the calculation of the wavelet and multi-component transformations.

Only the features defined in JPEG 2000 Part 1 (ISO/IEC 15444-1) are permitted for these two Transfer Syntaxes. Additional features and extensions that may be defined in other parts of JPEG 2000 shall not be included in the compressed bitstream unless they can be decoded or ignored without loss of fidelity by all Part 1 compliant implementations.

If the object allows multi-frame images in the pixel data field, then for these JPEG 2000 Part 1 Transfer Syntaxes, each frame shall be encoded separately. Each fragment shall contain encoded data from a single frame.

### Note

1. That is, the processes defined in ISO/IEC 15444-1 shall be applied on a per-frame basis. The proposal for encapsulation of multiple frames in a non-DICOM manner in so-called "Motion-JPEG" or "M-JPEG" defined in 15444-3 is not used.

2. Though a fragment may not contain encoded data from more than one frame, the encoded data from one frame may span multiple fragments. See note in Section 8.2.

For all images, including all frames of a multi-frame image, the JPEG 2000 bitstream specified in ISO/IEC 15444-1 shall be used. The optional JP2 file format header shall NOT be included.

### Note

The role of the JP2 file format header is fulfilled by the non-pixel data attributes in the DICOM Data Set.

The International Standards Organization ISO/IEC JTC1 has also developed JPEG 2000 Part 2 (ISO/IEC 15444-2), which includes Extensions to the compression techniques described in Part 1 of the JPEG 200 Standard. Annex J of JPEG 2000 Part 2 describes extensions to the ICT and RCT multiple component transformations allowed in Part 1. Two types of multiple component transformations are defined in Annex J of Part 2 of JPEG 2000:

1. Array based multiple component transforms that form linear combinations of components to reduce the correlation between components. Array based transforms include prediction based transformations such as DPCM as well as more complicated transformations such as the KLT. These array based transformations can be implemented reversibly or irreversibly.

2. Wavelet based multiple component transformations using the same two wavelet filters as used in Part 1 of JPEG 2000 (5-3 reversible wavelet and 9-7 irreversible wavelet).

Annex J of JPEG 2000 Part 2 also describes a flexible mechanism to allow these techniques to be applied in sequence. Furthermore, it provides mechanisms that allow components to be re-ordered and grouped into component collections. Different multiple component transformation can then be applied to each component collection.

Two additional Transfer Syntaxes are specified for Part 2 JPEG 2000:

1. A Transfer Syntax with a UID of 1.2.840.10008.1.2.4.92, which specifies the use of the lossless (reversible) mode of JPEG 2000 Part 2 (ISO/IEC 15444-2) multiple component transformation extensions, as defined in Annex J of JPEG 2000 Part 2 (i.e., the use of a reversible wavelet transformation and a reversible multiple component transformation, and no quantization or code stream truncation).

2. A Transfer Syntax with a UID of 1.2.840.10008.1.2.4.93, which specifies the use of either:

   1. the lossless (reversible) mode of JPEG 2000 Part 2 (ISO/IEC 15444-2) multiple component transformation extensions, as defined in Annex J of JPEG 2000 Part 2 (i.e., the use of a reversible wavelet transformation and a reversible multiple component transformation, and no quantization), or

   2. the lossy (irreversible) mode of JPEG 2000 Part 2 (ISO/IEC 15444-2) multiple component transformation extensions, as defined in Annex J of JPEG 2000 Part 2 (i.e., the use of an irreversible wavelet transformation and an irreversible multiple component transformation, and optionally quantization, or the use of an reversible wavelet transformation and a reversible multiple component transformation, followed by code stream truncation).

Only the multiple component transformation extensions defined in Annex J of JPEG 2000 Part 2 (ISO/IEC 15444-2) are permitted for these two Transfer Syntaxes. Additional features and extensions that may be defined in other Annexes of JPEG 2000 Part 2 shall not be included in the compressed bitstream.

### Note

the arbitrary wavelet transformations, as defined in Annex H of JPEG 2000 Part 2 (ISO/IEC 15444-2) are not allowed for these two Transfer Syntaxes. The only wavelet transformations that are allowed to be used as multiple component transformations are the reversible 5-3 wavelet transformation and the irreversible 9-7 wavelet transformation, as defined in Annex F of JPEG 2000 Part 1 (ISO/IEC 15444-1).

If the object allows multi-frame images in the pixel data field, then, for these JPEG 2000 Part 2 Transfer Syntaxes, the frames in the object are first processed using the multi-component transformation. After the multiple component transformation has been applied, the transformed frames are encoded using the process described in JPEG 2000 Part 1.

Optionally, the frames can be grouped into one or more component collections. The multiple component transformations are then applied to each component collection independently. The use of component collections can be used to reduce computational complexity and to improve access to specific frames on the decoder. If component collections are used, each fragment shall contain encoded data from a single component collection.

### Note

1. The 3rd dimension transformations that are described in this Supplement are treated in Part 2 of JPEG 2000 as direct extensions to the color component transformations (RGB to YUV) that are described in Part 1 of JPEG 2000. For this reason, each image or frame in the sequence is called a "component". Although the term component is used as a generic term to identify an element of the 3rd dimension, no restriction is made or implied that the transformations in this Supplement apply only to multi-component (or multiple color channel) data. To compress a volumetric data set using this transfer syntax, each frame of the DICOM image is treated as a component of a multi-component image.

2. The progressive nature of the JPEG 2000 code stream allows for the decompression of the image before the complete image has been transferred. If a Storage SCP truncates the code stream by aborting the association, the instance has not been completely transferred and hence should not persist unless different UIDs are assigned (even though it may have been transiently used for display purposes).

3. It has been shown that the use of component collections does not significantly affect the compression efficiency (for details, see http://medical.nema.org/Dicom/minutes/WG-04/2004/2004-02-18/3D_compression_RSNA_2003_ver2.pdf).

4. Though a fragment may not contain encoded data from more than one component collection, the encoded data from one component collection may span multiple fragments.

### A.4.5 MPEG2 Image Compression

The International Standards Organization ISO/IEC MPEG2 has developed an International Standard, ISO/IEC 13818-2 'Information Technology - Generic coding of moving pictures and associated audio information: video -- part 2', referred to as "MPEG-2".

A DICOM Transfer Syntax for MPEG2 Image Compression shall be identified by a UID value of either:

- 1.2.840.10008.1.2.4.100corresponding to MPEG2 MP@ML option of the ISO/IEC MPEG2 Video standard

- 1.2.840.10008.1.2.4.101 corresponding to the MPEG2 MP@HL option of the ISO/IEC MPEG2 Video standard.

### A.4.6 MPEG-4 AVC/H.264 HIP@Level4.1 Video Compression

The International Standards Organization ISO/IEC MPEG4 has developed an International Standard, ISO/IEC 14496-10 (MPEG-4 Part 10), for the video compression of generic coding of moving pictures and associated audio information. This standard is jointly maintained and has identical technical content as the ITU-T H.264 standard.

A DICOM Transfer Syntax for MPEG-4 AVC/H.264 Image Compression shall be identified by a UID value of either:

- 1.2.840.10008.1.2.4.102 corresponding to the MPEG-4 AVC/H.264 High Profile / Level 4.1 of the ITU-T H.264 Video standard

- 1.2.840.10008.1.2.4.103 corresponding to the MPEG-4 AVC/H.264 BD-compatible High Profile / Level 4.1 of the ITU-T H.264 Video standard with the temporal and spatial resolution restrictions defined in Table 8-4.

Prev | Up | Next
A.3 DICOM Big Endian Transfer Syntax (Explicit VR) | Home | A.5 DICOM Deflated Little Endian Transfer Syntax (Explicit VR)