Материал: part05

extensionstotheICTandRCTmultiplecomponenttransformationsallowedinPart1.Twotypesofmultiplecomponenttransformations​ 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 re-​ versible 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,​ itprovidesmechanismsthatallowcomponentstobere-orderedandgroupedintocomponentcollections.Differentmultiplecomponent​ 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:​

a.​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 com-​ ponent transformation, and no quantization), or​

b.​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 bit stream.​

Note​

the arbitrary wavelet transformations, as defined in Annex H of JPEG 2000 Part 2 ([ISO/IEC 15444-2]) are not allowed for​ thesetwoTransferSyntaxes.Theonlywavelettransformationsthatareallowedtobeusedasmultiplecomponenttransform-​ ations 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 com-​ plexityandtoimproveaccesstospecificframesonthedecoder.Ifcomponentcollectionsareused,eachfragmentshallcontainencoded​ 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 gen-​ eric 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.​

- Standard -​

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,seehttp://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 Video 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 Video Compression shall be identified by a UID value of either:​

•​1.2.840.10008.1.2.4.100 corresponding to MPEG2 Main Profile / Main Level option of the ISO/IEC MPEG2 Video standard​

•​1.2.840.10008.1.2.4.101 corresponding to the MPEG2 Main Profile / High Level option of the ISO/IEC MPEG2 Video standard.​

A.4.6 MPEG-4 AVC/H.264 High Profile / Level 4.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 Video 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.103correspondingtotheMPEG-4AVC/H.264BD-compatibleHighProfile/Level4.1oftheITU-TH.264Video​ standard with the temporal and spatial resolution restrictions defined in Table 8-4.​

A.4.7 MPEG-4 AVC/H.264 High Profile / Level 4.2 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 MPEG-4 AVC/H.264 High Profile / Level 4.2 for 2D Video Compression shall be identified by a UID value​ of:​

•​1.2.840.10008.1.2.4.104 corresponding to the MPEG-4 AVC/H.264 High Profile / Level 4.2 of the ITU-T H.264 Video standard with​ the restriction that frame packing for stereoscopic 3D content shall not be used as defined in Table 8-8.​

A DICOM Transfer Syntax MPEG-4 AVC/H.264 High Profile / Level 4.2 for 3D Video Compression shall be identified by a UID value​ of:​

•​1.2.840.10008.1.2.4.105 corresponding to the MPEG-4 AVC/H.264 High Profile / Level 4.2 of the ITU-T H.264 Video standard. It​ should be used for transmitting stereoscopic 3D content with frame packing formats as defined in Table 8-8.​

A.4.8 MPEG-4 AVC/H.264 Stereo High Profile / Level 4.2 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 Stereo High Profile / Level 4.2 Video Compression shall be identified by a UID​ value of:​

- Standard -​

•​1.2.840.10008.1.2.4.106 corresponding to the MPEG-4 AVC/H.264 Stereo High Profile / Level 4.2 of the ITU-T H.264 Video​ standard.​

A.4.9 HEVC/H.265 Main Profile / Level 5.1 Video Compression​

The International Standards Organization ISO/IEC MPEG has developed an International Standard, [ISO/IEC 23008-2] (HEVC), 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 [ISO/IEC 23008-2] HEVC standard.​

A DICOM Transfer Syntax for HEVC/H.265 Main Profile / Level 5.1 Video Compression shall be identified by a UID value of:​

•​1.2.840.10008.1.2.4.107correspondingtotheHEVC/H.265MainProfile/Level5.1ofthe[ISO/IEC23008-2]HEVCVideostandard.​

A.4.10 HEVC/H.265 Main 10 Profile / Level 5.1 Video Compression​

The International Standards Organization ISO/IEC MPEG has developed an International Standard, [ISO/IEC 23008-2] (HEVC), 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 [ISO/IEC 23008-2] HEVC standard.​

A DICOM Transfer Syntax for HEVC/H.265 Main 10 Profile / Level 5.1 Video Compression shall be identified by a UID value of:​

•​1.2.840.10008.1.2.4.108 corresponding to the HEVC/H.265 Main 10 Profile / Level 5.1 of the [ISO/IEC 23008-2] HEVC Video​ standard.​

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

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

Note​

1.​The Pixel Data in Pixel Data (7FE0,0010), Float Pixel Data (7FE0,0008) or Double Float Pixel Data (7FE0,0009) is not​ handledinanyspecialmanner.Thepixeldataisfirstencodedassequentialuncompressedframeswithoutencapsulation,​ 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 that elect to use this Transfer Syntax, the​ following policy is specified:​

•​Any implementation that 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.​

Note​

1.​Thisrequirementtosupportthe(uncompressed)ExplicitVRLittleEndianTransferSyntaxisinordertoensurefull-fidelity​ exchange of VR information in the case that the Association Acceptor does not support the Deflated Explicit VR Little​

- Standard -​

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

2.​There are no such "baseline" requirements on media, since such requirements are at the discretion of the Media Applic-​ ation 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 Transfer Syntax 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 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 Sec-​ tion 7.1.2.​

b.​TheencodingoftheoverallDataSetstructure(DataElementTags,ValueLength,andValue)shallbeinLittleEndianasspecified​ 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.​

•​FortheValueRepresentationsOBandOW,theencodingshallmeetthefollowingspecificationdependingontheDataElement​ Tag:​

•​Pixel Data (7FE0,0010) 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 (60xx,3000) Element, which shall have the Value Rep-​ resentation 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.​

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

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

A.8SMPTEST2110-20UncompressedProgressiveActiveVideoTransferSyntax​

This Transfer Syntax is used in a DICOM-RTV Metadata Flow in order to describe the accompanying [SMPTE ST 2110-20] Video​ Flow.​

DICOM Attributes​

•​Samples per Pixel (0028,0002)​

•​Photometric Interpretation (0028,0004)​

- Standard -​

•​Bits Allocated (0028,0100)​

•​Bits Stored (0028,0101)​

•​High Bit (0028,0102)​

are still applicable with some accommodations below.​

As DICOM Photometric Interpretation (0028,0004) values YBR_FULL, YBR_FULL_422, YBR_PARTIAL_420 are based on CCIR 601​ (aka BT.601), DICOM-RTV supports only the following:​

•​[SMPTE ST 2110-20] YCbCr-4:4:4 sampling system​

•​[SMPTE ST 2110-20] RGB sampling system​

•​[SMPTE ST 2110-20] YCbCr-4:2:2 sampling system​

•​[SMPTE ST 2110-20] YCbCr-4:2:0 sampling system​

Table A.8-1 describes the different color resolution.​

Table A.8-1. DICOM Attributes for different color resolution​

The way of encoding pixels shall respect SMPTE ST2110-20.​

Note​

This encoding is different than the encoding of Pixel Data (7FE0,0010). Example, for YBR_FULL_422 10 bits:​

- SMPTE ST 2110-20 Video Flow YCbCr 4:2:2 10 bits​

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | Y'00 (10 bits) |0|0|0|0|0|0| Y'01 (10 bits) |0|0|0|0|0|0| C'B00 (10 bits) |0|0|0|0|0|0| C'R00 (10 bits) |0|0|0|0|0|0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

A DICOM Transfer Syntax for SMPTE ST 2110-20 Uncompressed Progressive Active Video shall be identified by a UID value of​

•​1.2.840.10008.1.2.7.1 corresponding to [SMPTE ST 2110-20] for the progressive video.​

- Standard -​