Annex A(Normative)Transfer Syntax Specifications

A.1 DICOM implicit VR little endian transfer syntax

This Transfer Syntax applies to the encoding of the entire DICOM Data Set. This implies that when a DICOM Data Set is being encoded with the DICOM Implicit VR Little Endian Transfer Syntax the following requirements shall be met:

a) The Data Elements contained in the Data Set structure shall be encoded with Implicit VR (without a VR Field) as specified in Section 7.1.3.

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

c) 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, 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 has the Value Representation OW and shall be encoded in Little Endian.

⎯ Data Element (60xx,3000) Overlay Data has the Value Representation OW and shall be encoded in Little Endian.

⎯ Data Element (5400,1010) Waveform Data shall have Value Representation OW and 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 PS 3.6 (1993), or specified OW in this Part but a VR of US, SS or OW in PS 3.6 (1996). The actual encoding of the values and their byte order would be identical in each case.

⎯ 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 PS 3.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 PS 3.6 (1998). A VR of OW has been added to support explicit VR transfer syntaxes. 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.

⎯ Data Element (0028,3002) LUT Descriptor has the Value Representation SS or US (depending on rules specified in the IOD in PS 3.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.

Note: Encoding of Curve Data and Audio Sample Data was previously defined but has been retired. See PS 3.5 2004.

This DICOM Implicit VR Little Endian Transfer Syntax shall be identified by a UID of Value "1.2.840.10008.1.2".

A.2 DICOM little endian transfer syntax (explicit VR)

This Transfer Syntax applies to the encoding of the entire DICOM Data Set. This implies that when a DICOM Data Set is being encoded with the DICOM Little Endian Transfer Syntax the following requirements shall be met:

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

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

c) 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, 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

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

⎯ Data Element (60xx,3000) Overlay Data

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

Note: Previous versions of the Standard specified that the choice of OB or OW VR was based on whether or not Overlay Bits Allocated (60xx,0100) was greater than, or less than or equal to, 8. However, since only one bit plane can be encoded in each Overlay Data Element (60xx,3000), no value of Overlay Bits Allocated other than 1 makes sense. Such a restriction is now present in PS 3.3.

⎯ 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 PS 3.6 (1993), or specified OW in this Part but a VR of US, SS or OW in PS 3.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 2 16 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 PS 3.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 PS 3.6 (1998). However, an explicit VR of US or SS cannot be used to encode a table of 2 16 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 PS 3.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.

Notes: 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 PS 3.5 2004.

This DICOM Explicit VR Little Endian Transfer Syntax shall be identified by a UID of Value "1.2.840.10008.1.2.1".

A.3 DICOM big endian transfer syntax (explicit VR)

This Transfer Syntax applies to the encoding of the entire DICOM Data Set. This implies that when a DICOM Data Set is being encoded with the DICOM Big Endian Transfer Syntax the following requirements shall be met:

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

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

c) 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, except for the Value Representations OB and OW, the encoding shall be in Big 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

⎯ where Bits Allocated (0028,0100) has a value greater than 8 shall have Value Representation OW and shall be encoded in Big 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 Big Endian.

⎯ Data Element (60xx,3000) Overlay Data

⎯ shall have the Value Representation OB or OW and shall be encoded in Big Endian.

Note: Previous versions of the Standard specified that the choice of OB or OW VR was based on whether or not Overlay Bits Allocated (60xx,0100) was greater than, or less than or equal to, 8. However, since only one bit plane can be encoded in each Overlay Data Element (60xx,3000), no value of Overlay Bits Allocated other than 1 makes sense. Such a restriction is now present in PS 3.3.

⎯ Data Element (5400,1010) Waveform Data has the Value Representation specified in its Explicit VR Field. The component points shall be encoded in Big 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 Big 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 PS 3.6 (1993), or specified OW in this Part but a VR of US, SS or OW in PS 3.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 2 16 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 PS 3.3), and shall be encoded in Big 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 Big Endian.

⎯ Data Element (0028,3006) LUT Data has the Value Representation US or OW and shall be encoded in Big 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 PS 3.6 (1998). However, an explicit VR of US or SS cannot be used to encode a table of 2 16 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 PS 3.3), and shall be encoded in Big 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 Big Endian.

Notes: 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 PS 3.5 2004.

This DICOM Explicit VR Big Endian Transfer Syntax shall be identified by a UID of Value "1.2.840.10008.1.2.2".

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:

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

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

c) 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 Tables A.4-1 and 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.

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

Notes: 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 PS 3.6 (1993), or specified OW in this Part but a VR of US, SS or OW in PS 3.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 2 16 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 PS 3.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 PS 3.6 (1998). However, an explicit VR of US or SS cannot be used to encode a table of 2 16 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 PS 3.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.

Notes: 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 PS 3.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
Basic Offset Table with NO Item Value First Fragment (Single Frame) of Pixel Data
Item Tag Item Length Item Tag Item Length Item Value
(7FE0, 0010) with VR of OB OB 0000H Reserved FFFF FFFFH undefined length (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

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 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
Basic Offset Table with Item Value First Fragment (Frame 1) of Pixel Data
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 Sections 8.2.1 and 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).

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

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

  2. 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 codestream truncation), or

  3. 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 codestream 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.

Notes: 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 which 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 codestream truncation).

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

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

  3. 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 codestream 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.

Notes: 1. The 3 rd 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 3 rd 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 codestream 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:

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:

A.5 DICOM DEFLATED LITTLE ENDIAN TRANSFER SYNTAX (EXPLICIT VR)

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 DICOM Little Endian Transfer Syntax (Explicit VR).

The entire byte stream is then compressed using the “Deflate” algorithm defined in Internet RFC 1951.

If the deflate algorithm produces an odd number of bytes then a single trailing NULL byte shall be added after the last byte of the deflated bit stream.

Notes: 1. The Pixel Data (7FE0,0010) 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 of any other attribute.

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

3. 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/.

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

In order to facilitate interoperability of implementations conforming to the DICOM Standard which elect to use this Transfer Syntax, the following policy is specified:

⎯ Any implementation which has elected to support the Deflated Explicit VR Little Endian Transfer Syntax for any Abstract Syntax, shall also support the Explicit VR Little Endian Transfer for that Abstract Syntax

Notes: 1.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 otherwords, an implementation must support all three transfer syntaxes.

2. 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 transfer syntax.

This DICOM Deflated Explicit VR Little Endian Transfer Syntax shall be identified by a UID of Value "1.2.840.10008.1.2.1.99".

A.6 DICOM JPIP ReFERENCED transfer syntax (explicit VR)

This Transfer Syntax applies to the encoding of the entire DICOM Data Set. This implies that when a DICOM Data Set is being encoded with the DICOM Little Endian Transfer Syntax the following requirements shall be met:

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

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

c) 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, 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 shall not be present, but rather pixel data shall be referenced via Data Element (0028,7FE0) Pixel Data Provider URL

⎯ Overlay data, if present, shall only be encoded in the Overlay Data attribute (60xx,3000), which shall have the Value Representation OB or OW and shall be encoded in Little Endian.

⎯ Data Element (0028,0004) Photometric Interpretation shall be limited to the values: MONOCHROME1, MONOCHROME2, YBR_ICT and YBR_RCT.

This DICOM JPIP REFERENCED Transfer Syntax shall be identified by a UID of Value "1.2.840.10008.1.2.4.94 ".

A.7 DICOM JPIP ReferenCeD Deflate Transfer Syntax (explicit VR)

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.6 DICOM JPIP Referenced Transfer Syntax (Explicit VR).

The entire byte stream is then compressed using the “Deflate” algorithm defined in Internet RFC 1951.

This DICOM JPIP Referenced DeflateTransfer Syntax shall be identified by a UID of Value "1.2.840.10008.1.2.4.95".