Материал: part05

•​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​ fragmentofaframemaybepadded,ifnecessary,tomeetthesequenceitemformatrequirementsoftheDICOMStandard.​

Note​

1.​AnynecessarypaddingmaybeaddedintheJPEGorJPEG-LScompresseddatastreamasperISO10918-​ 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.​Decodersofencapsulatedpixeldata,whetherSingleFrameorMulti-Frame,needtoacceptbothanempty​ 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 Ex-​ tended 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.​

- Standard -​

•​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,sincetheValueLengthisrestrictedto16bits.HenceaVRofOWhasbeenadded.Moreoverthiselement​ 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​ PrimitivePointIndexList(0066,0029)werepreviouslydefinedwithavaluerepresentationofOWandalwaysinterpreted​ 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​

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​

SecondFragment(SingleFrame)ofPixelData​Third Fragment (Single Frame) of Pixel Data​Sequence Delimiter Item​

- Standard -​

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​

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

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​ anInternationalStandard,ISO10918-2(JPEGPart2),knownastheJPEGStandard,fordigitalcompressionandcodingofcontinuous-​ 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​

Note​

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

- Standard -​

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 re-​ quired. 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).​

IfimageswithPhotometricInterpretation(0028,0004)YBR_FULL_422orYBR_PARTIAL_422,areencodedwithJPEGcodingProcess​ 1(nonhierarchicalwithHuffmancoding),identifiedbyDICOMTransferSyntaxUID"1.2.840.10008.1.2.4.50"theminimumcompressible​ 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 cor-​ responding CB and CR blocks.​

A.4.2 RLE Image Compression​

AnnexGdefinesaRLEImageCompressionTransferSyntax.ThistransferSyntaxisidentifiedbytheUIDvalue"1.2.840.10008.1.2.5".​ Iftheobjectallowsmulti-frameimagesinthepixeldatafield,theneachframeshallbeencodedseparately.Eachframeshallbeencoded​ in one and only one Fragment (see Section 8.2).​

A.4.3 JPEG-LS Image Compression​

TheInternational Standards Organization ISO/IECJTC1 has developed anInternational Standard, [ISO/IEC 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.​

- Standard -​

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

Forallimages,includingallframesofamulti-frameimage,theJPEG-LSInterchangeFormatshallbeused(allparameterspecifications​ shall be included).​

A.4.4 JPEG 2000 Image Compression​

The International Standards Organization ISO/IEC JTC1 has developed an International Standard, [ISO/IEC 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 transform-​ ation, 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:​

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

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

Onlythefeatures definedin JPEG2000Part 1([ISO/IEC15444-1])arepermitted for thesetwoTransfer Syntaxes.Additional features​ and extensions that may be defined in other parts of JPEG 2000 shall not be included in the compressed bit stream 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.​Thatis,theprocessesdefinedin[ISO/IEC15444-1]shallbeappliedonaper-framebasis.Theproposalforencapsulation​ 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 bit stream 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 2000 Standard. Annex J of JPEG 2000 Part 2 describes​

- Standard -​