Материал: part05

The number of bits of each Pixel Cell is defined by the Bits Allocated (0028,0100) Data Element Value. When a Pixel Cell crosses a​ word boundary in the OW case, or a byte boundary in the OB case, it shall continue to be encoded, least significant bit to most signi-​ ficant bit, in the next word, or byte, respectively (see Annex D). For Pixel Data (7FE0,0010) encoded with the Value Representation​ OW, the byte ordering of the resulting 2-byte words is defined by the Little Endian Transfer Syntaxes negotiated at the Association​ Establishment (see Annex A).​

Note​

1.​ForPixelData(7FE0,0010)encodedwiththeValueRepresentationOB,thePixelData(7FE0,0010)encodingisunaffected​ by byte ordering.​

2.​If encoding Pixel Data (7FE0,0010) with a Value for Bits Allocated (0028,0100) not equal to 16 be sure to read and un-​ derstand Annex D.​

IfsentinanEncapsulatedFormat(i.e.,otherthantheNativeFormat)theValueRepresentationOBisused.ThePixelCellsareencoded​ according to the encoding process defined by one of the negotiated Transfer Syntaxes (see Annex A). The encapsulated pixel stream​ of encoded pixel data is segmented into one or more Fragments, each of which conveys its own explicit length. The sequence of​ Fragments of the encapsulated pixel stream is terminated by a delimiter, thus allowing the support of encoding processes where the​ resulting length of the entire pixel stream is not known until it is entirely encoded. This Encapsulated Format supports both Single-​ Frame and Multi-Frame images (as defined in PS3.3). At least one frame shall be present, and hence at least one fragment will be​ present.​

Note​

DependingontheTransferSyntax,aframemaybeentirelycontainedwithinasinglefragment,ormayspanmultiplefragments​ to support buffering during compression or to avoid exceeding the maximum size of a fixed length fragment. A recipient can​ detect fragmentation of frames by comparing the number of fragments (the number of Items minus one for the Basic Offset​ Table) with the number of frames. Some performance optimizations may be available to a recipient in the absence of frag-​ mentation of frames, but an implementation that fails to support such fragmentation does not conform to the Standard.​

8.2.1 JPEG Image Compression​

DICOM provides a mechanism for supporting the use of JPEG Image Compression through the Encapsulated Format (see PS3.3).​ Annex A defines a number of Transfer Syntaxes that reference the JPEG Standard and provide a number of lossless (bit preserving)​ and lossy compression schemes.​

Note​

The context where the usage of lossy compression of medical images is clinically acceptable is beyond the scope of the​ DICOMStandard.Thepoliciesassociatedwiththeselectionofappropriatecompressionparameters(e.g.,compressionratio)​ for JPEG lossy compression is also beyond the scope of this Standard.​

In order to facilitate interoperability of implementations conforming to the DICOM Standard that elect to use one or more of the​ Transfer Syntaxes for JPEG Image Compression, the following policy is specified:​

•​AnyimplementationthatconformstotheDICOMStandardandhaselectedtosupportanyoneoftheTransferSyntaxesforlossless​ JPEGImageCompression,shallsupportthefollowinglosslesscompression:Thesubset(first-orderhorizontalprediction[Selection​ Value 1) of JPEG Process 14 (DPCM, non-hierarchical with Huffman coding) (see Annex F).​

•​Any implementation that conforms to the DICOM Standard and has elected to support any one of the Transfer Syntaxes for 8-bit​ lossy JPEG Image Compression, shall support the JPEG Baseline Compression (coding Process 1).​

•​Any implementation that conforms to the DICOM Standard and has elected to support any one of the Transfer Syntaxes for 12-bit​ lossy JPEG Image Compression, shall support the JPEG Compression Process 4.​

Note​

The DICOM conformance statement shall differentiate whether or not the implementation is capable of simply receiving or​ receiving and processing JPEG encoded images (see PS3.2).​

TheuseoftheDICOMEncapsulatedFormattosupportJPEGCompressedPixelDatarequiresthattheDataElementsthatarerelated​ tothe Pixel Dataencoding (e.g., PhotometricInterpretation,Samples per Pixel, PlanarConfiguration, Bits Allocated,BitsStored, High​

- Standard -​

Bit, Pixel Representation, Rows, Columns, etc.) shall contain values that are consistent with the characteristics of the compressed​ data stream.​

The requirements when using a Standard Photometric Interpretation (i.e., a Defined Term from Section C.7.6.3.1.2 in PS3.3) are​ specified in Table 8.2.1-1 and Table 8.2.1-2. No other Standard Photometric Interpretation values shall be used.​

Table 8.2.1-1. Valid Values of Pixel Data Related Attributes for JPEG Lossy Transfer Syntaxes using​ Standard Photometric Interpretations​

Table 8.2.1-2. Valid Values of Pixel Data Related Attributes for JPEG Lossless Transfer Syntaxes using​ Standard Photometric Interpretations​

The Pixel Data characteristics included in the JPEG Interchange Format shall be used to decode the compressed data stream.​

IfAPP2markersegmentswithanidentifierof"ICC_PROFILE"(asdefinedinAnnexBof[ISO15076-1])arepresentinthecompressed​ datastream,theirconcatenatedvalueshallbeidenticaltothevalueofICCProfile(0028,2000)Attribute,ifpresent,excludingpadding.​

Note​

1.​These requirements were formerly specified in terms of the "uncompressed pixel data from which the compressed data​ stream was derived". However, since the form of the "original" uncompressed data stream could vary between different​ implementations, this requirement is now specified in terms of consistency with what is encapsulated.​

- Standard -​

When decompressing, should the characteristics explicitly specified in the compressed data stream (e.g., spatial sub-​ sampling or number of components or planar configuration) be inconsistent with those specified in the DICOM Data​ Elements, those explicitly specified in the compressed data stream should be used to control the decompression. The​ DICOM data elements, if inconsistent, can be regarded as suggestions as to the form in which an uncompressed Data​ Set might be encoded, subject to the general and IOD-specific rules for uncompressed Photometric Interpretation and​ Planar Configuration, which may require that decompressed data be converted to one of the permitted forms.​

2.​Those characteristics not explicitly specified in the compressed data stream (e.g., the color space of the compressed​ components, which is not specified in the JPEG Interchange Format), or implied by the definition of the compression​ scheme (e.g., always unsigned in JPEG), can therefore be determined from the DICOM Data Element in the enclosing​ DataSet.ForexampleaPhotometricInterpretationof"YBR_FULL_422"woulddescribethecolorspacethatiscommonly​ used to lossy compress images using JPEG. It is unusual to use an RGB color space for lossy compression, since no​ advantageistakenofcorrelationbetweenthered,greenandbluecomponents(e.g.,ofluminance),andpoorcompression​ is achieved; however, for some applications this is permitted, e.g., Whole Slide Microscopy Images, to allow conversion​ to DICOM from proprietary formats without loss due to color space transformation.​

3.​The JPEG Interchange Format is distinct from the JPEG File Interchange Format (JFIF). The JPEG Interchange Format​ is defined in [ISO/IEC 10918-1] section 4.9.1, and refers to the inclusion of decoding tables, as distinct from the "abbre-​ viated format" in which these tables are not sent (and the decoder is assumed to already have them). The JPEG Inter-​ change Format does NOT specify the color space. The JPEG File Interchange Format, not part of the original JPEG​ standard, but defined in [ECMA TR-098] and [ISO/IEC 10918-5], is often used to store JPEG bit streams in consumer​ format files, and does include the ability to specify the color space of the components. The JFIF APP0 marker segment​ is NOT required to be present in DICOM encapsulated JPEG bit streams, and should not be relied upon to recognize​ the color space. Its presence is not forbidden (unlike the JP2 information for JPEG 2000 Transfer Syntaxes), but it is​ recommended that it be absent.​

4.​Should the compression process be incapable of encoding a particular form of pixel data representation (e.g., JPEG​ cannot encode signed integers, only unsigned integers), then ideally only the appropriate form should be "fed" into the​ compressionprocess.However,forcertaincharacteristicsdescribedinDICOMDataElementsbutnotexplicitlydescribed​ in the compressed data stream (such as Pixel Representation), then the DICOM Data Element should be considered​ to describe what has been compressed (e.g., the pixel data really is to be interpreted as signed if Pixel Representation​ so specifies).​

5.​DICOM Data Elements should not describe characteristics that are beyond the capability of the compression scheme​ used. For example, JPEG lossy processes are limited to 12 bits, hence the value of Bits Stored should be 12 or less.​ Bits Allocated is irrelevant, and is likely to be constrained by the Information Object Definition in PS3.3 to values of 8 or​ 16. Also, JPEG compressed data streams are always color-by-pixel and should be specified as such (a decoder can​ essentially ignore this element however as the value for JPEG compressed data is already known).​

6.​IfJPEGCompressedPixelDataisdecompressedandre-encodedinNative(uncompressed)form,thentheDataElements​ that are related to the Pixel Data encoding are updated accordingly. If color components are converted from​ YBR_FULL_422 to RGB during decompression and Native re-encoding, the Photometric Interpretation will be changed​ to RGB in the Data Set with the Native encoding.​

8.2.2 Run Length Encoding Image Compression​

DICOM provides a mechanism for supporting the use of Run Length Encoding (RLE) Image Compression, which is a byte oriented​ losslesscompressionschemethroughtheencapsulatedFormat(seePS3.3ofthisStandard).AnnexGdefinesRLEImageCompression​ and its Transfer Syntax.​

Note​

The RLE Image Compression algorithm described in Annex G is the compression used in the TIFF 6.0 specification known​ as the "PackBits" scheme.​

The use of the DICOM Encapsulated Format to support RLE Compressed Pixel Data requires that the Data Elements that are related​ tothe Pixel Dataencoding (e.g., PhotometricInterpretation,Samples per Pixel, PlanarConfiguration, Bits Allocated,BitsStored, High​ Bit, Pixel Representation, Rows, Columns, etc.) shall contain values that are consistent with the compressed data.​

The requirements when using a Standard Photometric Interpretation (i.e., a Defined Term from PS.3. C.7.6.3.1.2) are specified in​ Table 8.2.2-1. No other Standard Photometric Interpretation values shall be used.​

- Standard -​

Table 8.2.2-1. Valid Values of Pixel Data Related Attributes for RLE Compression using Standard​ Photometric Interpretations​

Note​

1.​These requirements were formerly specified in terms of the "uncompressed pixel data from which the compressed data​ was derived". However, since the form of the "original" uncompressed data stream could vary between different imple-​ mentations, this requirement is now specified in terms of consistency with what is encapsulated.​

2.​Those characteristics not implied by the definition of the compression scheme (e.g., always color-by-plane in RLE), can​ therefore be determined from the DICOM Data Element in the enclosing Data Set. For example a Photometric Interpret-​ ation of "YBR_FULL" would describe the color space that is commonly used to losslessly compress images using RLE.​ It is unusual to use an RGB color space for RLE compression, since no advantage is taken of correlation between the​ red,greenandbluecomponents(e.g.,ofluminance),andpoorcompressionisachieved(notehoweverthattheconversion​ from RGB to YBR_FULL is itself lossy. A new photometric interpretation may be proposed in the future that allows​ lossless conversion from RGB and also results in better RLE compression ratios).​

3.​DICOM Data Elements should not describe characteristics that are beyond the capability of the compression scheme​ used. For example, RLE compressed data streams (using the algorithm mandated in the DICOM Standard) are always​ color-by-plane.​

4.​IfRLECompressedPixelDataisdecompressedandre-encodedinNative(uncompressed)form,thentheDataElements​ that are related to the Pixel Data encoding are updated accordingly. If color components are converted from YBR_FULL​ to RGB during decompression and Native re-encoding, the Photometric Interpretation will be changed to RGB in the​ Data Set with the Native encoding. It is permitted, however, to leave the YBR_FULL color components unconverted but​ decompressedintheNativeformat,inwhichcasethePhotometricInterpretationintheDataSetwiththeNativeencoding​ would be YBR_FULL.​

8.2.3 JPEG-LS Image Compression​

DICOMprovidesamechanismforsupportingtheuseofJPEG-LSImageCompressionthroughtheEncapsulatedFormat(seePS3.3).​ AnnexAdefinesanumberofTransferSyntaxesthatreferencetheJPEG-LSStandardandprovideanumberoflossless(bitpreserving)​ and lossy (near-lossless) compression schemes.​

Note​

The context where the usage of lossy (near-lossless) compression of medical images is clinically acceptable is beyond the​ scope of the DICOM Standard. The policies associated with the selection of appropriate compression parameters (e.g.,​ compression ratio) for JPEG-LS lossy (near-lossless) compression is also beyond the scope of this Standard.​

The use of the DICOM Encapsulated Format to support JPEG-LS Compressed Pixel Data requires that the Data Elements that are​ related to the Pixel Data encoding (e.g., Photometric Interpretation, Samples per Pixel, Planar Configuration, Bits Allocated, Bits​ Stored, High Bit, Pixel Representation, Rows, Columns, etc.) shall contain values that are consistent with the characteristics of the​ compressed data stream. The Pixel Data characteristics included in the JPEG-LS Interchange Format shall be used to decode the​ compressed data stream.​

The requirements when using a Standard Photometric Interpretation (i.e., a Defined Term from PS.3. C.7.6.3.1.2) are specified in​ Table 8.2.3-1. No other Standard Photometric Interpretation values shall be used.​

- Standard -​

Table 8.2.3-1. Valid Values of Pixel Data Related Attributes for JPEG-LS Compression using Standard​ Photometric Interpretations​

Note​

1.​See also the notes in Section 8.2.1.​

2.​No color transformation Photometric Interpretation specific for JPEG-LS is currently defined in DICOM. Annex F of ISO​ 14495-2describesa"Sampletransformationforinversecolourtransform"andamarkersegmenttoencodeitsparameters,​ but this is not known to have been implemented. Common practice is to compress the RGB components unconverted,​ which sacrifices compression performance, and send the Photometric Interpretation as RGB. Though the YBR_RCT​ PhotometricInterpretationandcomponentconversioncouldtheoreticallybeused,intheabsenceofDCshiftingitresults​ in signed values to be encoded, which are not supported by JPEG-LS.​

3.​If JPEG-LS Compressed Pixel Data is decompressed and re-encoded in Native (uncompressed) form, then the Data​ Elements that are related to the Pixel Data encoding are updated accordingly. If color components are converted from​ any other Photometric Interpretation to RGB during decompression and Native re-encoding, the Photometric Interpret-​ ation will be changed to RGB in the Data Set with the Native encoding.​

4.​The lower limit of 2 on Bits Stored (0028,0101) reflects the minimum JPEG-LS sample precision of 2.​

The value of Planar Configuration (0028,0006) is irrelevant since the manner of encoding components is specified in the JPEG-LS​ bit stream as component, line or sample interleaved, hence it shall be set to 0.​

8.2.4 JPEG 2000 Image Compression​

DICOM provides a mechanism for supporting the use of JPEG 2000 Image Compression through the Encapsulated Format (see​ PS3.3). Annex A defines a number of Transfer Syntaxes that reference the JPEG 2000 Standard and provide lossless (bit preserving)​ and lossy compression schemes.​

Note​

The context where the usage of lossy compression of medical images is clinically acceptable is beyond the scope of the​ DICOMStandard.Thepoliciesassociatedwiththeselectionofappropriatecompressionparameters(e.g.,compressionratio)​ for JPEG 2000 lossy compression are also beyond the scope of this Standard.​

The use of the DICOM Encapsulated Format to support JPEG 2000 Compressed Pixel Data requires that the Data Elements that are​ related to the Pixel Data encoding (e.g., Photometric Interpretation, Samples per Pixel, Planar Configuration, Bits Allocated, Bits​ Stored, High Bit, Pixel Representation, Rows, Columns, etc.) shall contain values that are consistent with the characteristics of the​

- Standard -​