DICOM PS3.5 2020c - Data Structures and Encoding

A.4 Transfer Syntaxes For Encapsulation of Encoded Pixel Data (Current)
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. These Transfer Syntaxes shall only be used when Pixel Data (7FE0,0010) is present in the top level Data Set, and hence shall not be used when Float Pixel Data (7FE0,0008) or Double Float Pixel Data (7FE0,0009) are present. 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, OL, OV and OW, the encoding shall meet the following specification depending on the Data Element Tag:

     - Pixel Data (7FE0,0010) 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

       1. The OL and OV Value Representations are not used for Pixel Data, even if it has a Bits Allocated (0028,0100) of 32 or 64, since OL and OV were added to the Standard after the encoding of Pixel Data had been established

       2. That is, as if the Transfer Syntax were Explicit VR Little Endian.

       If encapsulated, it has the Value Representation OB and is an octet-stream 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.

           3. A Basic Offset Table Item Value is not permitted (i.e., the Item Length of the first Item will be zero) if Extended Offset Table (7FE0,0001) is present.

       - 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).

     - Overlay Data (60xx,3000)

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

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

     - Red Palette Color Lookup Table Data (0028,1201), Green Palette Color Lookup Table Data (0028,1202), Blue Color Palette Lookup Table Data (0028,1203) and Alpha Palette Color Lookup Table Data (0028,1204) 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.

     - Red Palette Color Lookup Table Descriptor (0028,1101), Green Palette Color Lookup Table Descriptor (0028,1102) and Blue Palette Color Lookup Table Descriptor (0028,1103) 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.

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

     - LUT Data (0028,3006) 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.

     - LUT Descriptor (0028,3002) 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.

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

     - Track Point Index List (0066,0129) has the Value Representation OL and shall be encoded in Little Endian and is always interpreted as unsigned.

### Note

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

2. Encoding of Curve Data (5000,3000) and Audio Sample Data (5000,200C) was previously defined but has been retired. See PS3.5-2004.

3. Vertex Point Index List (0066,0025), Edge Point Index List (0066,0024), Triangle Point Index List (0066,0023) and Primitive Point Index List (0066,0029) were previously defined with a value representation of OW and always interpreted as unsigned, but have been retired. These have been replaced by corresponding OL data elements, which allow values larger than 65535 to index the full range of points that can be encoded in Point Coordinates Data (0066,0016). See PS3.5-2015c.

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 0000H
4 bytes | 4 bytes | 024AH bytes | 4 bytes | 4 bytes | 0628H bytes | 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 10918-1 (JPEG Part 1) and an International Standard, ISO 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

1. 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).

2. Different JPEG processes may use different SOF marker segments. E.g., the baseline JPEG process 1 used with the 1.2.840.10008.1.2.4.50 Transfer Syntax uses the SOF0 marker, whereas the extended process 2 used with the 1.2.840.10008.1.2.4.51 Transfer Syntax uses the SOF1 marker. Accordingly, even though both bit streams encode 8 bit images using DCT and Huffman coding, the bit streams are not identical. Further, the extended process 2 may (but is not required to) use more AC and DC tables (up to 4 of each, rather than 2, per ISO 10918-1 Section F.1.3).

   It is not compliant to send bit streams with the SOF0 marker using the 1.2.840.10008.1.2.4.51 Transfer Syntax, but it is recommended that receivers of the 1.2.840.10008.1.2.4.51 Transfer Syntax be able to decode bit streams with the SOF0 marker (this asymmetry is consistent with ISO 10918-2 requirements; see A.4.1).

3. It is recommended that lossy compressed 8 bit images be encoded with the 1.2.840.10008.1.2.4.50 Transfer Syntax rather than the 1.2.840.10008.1.2.4.51 Transfer Syntax, unless the additional features of the extended process are required. Support of the 1.2.840.10008.1.2.4.50 Transfer Syntax is required for 8 bit images anyway (as described in 8.2.1) and to avoid confusion with the use of 12 bit images encoded with Process 4 in the 1.2.840.10008.1.2.4.51 Transfer Syntax (defined as a DICOM Default Transfer Syntax for 12 bit images in 10.3).

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/IEC 10918-1] "interchange format", not the [ISO/IEC 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.

Prev | Up | Next
A.3 DICOM Big Endian Transfer Syntax (Explicit VR) | Home | A.4.2 RLE Image Compression

DICOM PS3.5 2020c - Data Structures and Encoding