Материал: part05

Внимание! Если размещение файла нарушает Ваши авторские права, то обязательно сообщите нам

DICOM PS3.5 2020a - Data Structures and Encoding​

Page 61​

e.​Whether or not Private Data Elements contain identifying information related to de-identification is defined by the Private Data​ Element Characteristics Sequence (0008,0300). See PS3.3 Section C.12.1.​

f.​ DataElementsnumbered(gggg,0000),whereggggisodd,wereGroupLengthElements,whichhavebeenretired,SeeSection7.2.​

Since each Item within a sequence is a self contained Data Set (see Section 7.5 on the nesting of Data Sets via Sequences of Items),​ any Item that contains Private Data Elements shall also have Private Creator Data Elements reserving blocks of Elements for those​ Private Data Elements. The scope of the reservation is just within the Item. Items do not inherit the Private Data Element reservations​ made by Private Creator Data Elements in the Data Set in which the Item is nested.​

Note​

1.​If a sequence is itself a Private Data Element and the Items within the sequence also have Private Data Elements, then​ there will be Private Creator Data Elements both outside the sequence and within the sequence Items.​

2.​Different Items may reserve the same block of Private Data Elements for different private creators. This is necessary​ to allow the nesting of Data Sets collected from multiple sources into folders.​

3.​The recommended convention for referencing a Private Data Element is (gggg,xxee,"pcde"), where gggg is the group​ number, xx is the string “xx”, ee is the element number within a reserved block, and pcde is the quoted value of the​ Private Creator Data Element that reserved the block, e.g., (0029,xx43,"Acme_CT_Parameters"). Alternatively, when​ a block of Private Data Elements is being described, one may factor out the description of the Private Creator Data​ Elementvalue,e.g.,PrivateCreatorDataElement(0029,00xx)="Acme_CT_Parameters",and(0029,xx43),(0029,xx44),​ etc.​

7.8.2 Encoding of Private Elements​

The Value Representations used for Private Data Elements shall be the same as those VRs specified for Standard Data Elements​ in Section 6.2. The encoding shall conform to the requirements for those VRs and shall be in accordance with the negotiated Transfer​ Syntax.APrivateDataElementwithSQVR(aPrivateDataSequence)mayincludeItemswithbothStandardandPrivateDataElements.​ Standard Data Elements used within a Private Data Sequence shall use the VRs as defined in PS3.6 for those data elements.​

The semantics of Standard Data Elements within a Private Data Sequence, and the definition of Attribute Values, are implementation​ dependent.​

For a Standard Extended SOP Class the Attributes Pixel Data (7FE0,0010), Float Pixel Data (7FE0,0008), Double Float Pixel Data​ (7FE0,0009), Waveform Data (5400,1010) and Overlay Data (60xx,3000) shall not be included within a Private Sequence Item, nor​ within a standard Sequence Item nested directly or indirectly within a Private Sequence Item.​

- Standard -​

Page 62​

DICOM PS3.5 2020a - Data Structures and Encoding​

- Standard -​

DICOM PS3.5 2020a - Data Structures and Encoding​

Page 63​

8 Encoding of Pixel, Overlay and Waveform​

Data​

8.1 Pixel and Overlay Data, and Related Data Elements​

Pixel Data (7FE0,0010), Float Pixel Data (7FE0,0008), Double Float Pixel Data (7FE0,0009) and Overlay Data (60xx,3000) shall be​ used for the exchange of encoded graphical image data. These elements along with additional Data Elements, specified as Attributes​ of the Image Information Entities defined in PS3.3, shall be used to describe the way in which the Pixel Data and Overlay Data are​ encoded and shall be interpreted. Finally, depending on the negotiated Transfer Syntax (see Section 10 and Annex A), Pixel Data​ may be compressed.​

Pixel Data (7FE0,0010) and Overlay Data (60xx,3000) have a VR of OW or OB, depending on the negotiated Transfer Syntax (see​ Annex A). The only difference between OW and OB being that OB, an octet-stream, shall be unaffected by Byte Ordering (see Sec-​ tion 7.3).​

Float Pixel Data (7FE0,0008) has a Value Representation of OF.​

Double Float Pixel Data (7FE0,0009) has a Value Representation of OD.​

For Pixel Data values encoded in OF and OD, any value that is permitted by the IEEE 754:1985 may be used, including NaN, +ve​ Infinity and -ve Infinity. See Table 6.2-1​

Note​

Float and double float pixel data values are not arbitrarily constrained to finite numbers, since it may be important for the​ application to signal that the result of a calculation that produced a pixel is an infinite value or not a number.​

8.1.1 Pixel Data Encoding of Related Data Elements​

Encoded Pixel Data of various bit depths shall be accommodated. The following three Data Elements shall define the Pixel structure:​

•​Bits Allocated (0028,0100)​

•​Bits Stored (0028,0101)​

•​High Bit (0028,0102)​

Each Pixel Cell shall contain a single Pixel Sample Value. The size of the Pixel Cell shall be specified by Bits Allocated (0028,0100).​ Bits Stored (0028,0101) defines the total number of these allocated bits that will be used to represent a Pixel Sample Value. Bits​ Stored (0028,0101) shall never be larger than Bits Allocated (0028,0100). High Bit (0028,0102) specifies where the high order bit of​ the Bits Stored (0028,0101) is to be placed with respect to the Bits Allocated (0028,0100) specification. Bits Allocated (0028,0100)​ shall either be 1, or a multiple of 8. High Bit (0028,0102) shall be one less than Bits Stored (0028,0101).​

Note​

1.​For example, in Pixel Data with 16 bits (2 bytes) allocated, 12 bits stored, and bit 11 specified as the high bit, one pixel​ sample is encoded in each 16-bit word, with the 4 most significant bits of each word not containing Pixel Data. See​ Annex D for other examples of the basic encoding schemes.​

2.​Formerly, bits not used for Pixel Sample Values were described as being usable for overlay planes, but this usage has​ been retired. See PS3.5-2004.​

3.​Formerly, High Bit (0028,0102) was not restricted to be one less than Bits Stored (0028,0101) in this Part, or in the​ general case, though almost all Information Object Definitions in PS3.3 imposed such a restriction. See PS3.5 2014c.​

4.​Receiving applications may not assume anything about the contents of unused bits, and in particular may not assume​ that they are zero, or that they contain sign extension bits.​

- Standard -​

Page 64​

DICOM PS3.5 2020a - Data Structures and Encoding​

Additional restrictions that are placed on acceptable Values for Bits Allocated (0028,0100), Bits Stored (0028,0101), and High Bit​ (0028,0102) for Pixel Data (7FE0,0010) are specified in the Information Object Definitions in PS3.3.​

Restrictions are placed on acceptable Values for Bits Allocated (0028,0100) for Float Pixel Data (7FE0,0008) and Double Float Pixel​ Data(7FE0,0009),suchthatonlyasinglePixelCellentirelyoccupiestheallocatedbitsspecifiedbyBitsAllocated(0028,0100),hence​ Bits Stored (0028,0101) and High Bit (0028,0102) are not sent.​

Also, the Value Field containing Pixel Data, like all other Value Fields in DICOM, shall be an even number of bytes in length. This​ means that the Value Field may need to be padded with data that is not part of the image and shall not be considered significant. If​ needed, the padding bits shall be appended to the end of the Value Field, and shall be used only to extend the data to the next even​ byte increment of length.​

Note​

The32-bitValueLengthFieldlimitsthemaximumsizeoflargedatavaluessuchasPixelDatasentinaNativeFormat(encoded​ in Transfer Syntaxes that use only the unencapsulated form).​

In a multi-frame object that is transmitted in Native Format, the individual frames are not padded. The individual frames shall be​ concatenated and padding bits (if necessary) apply to the complete Value Field. At least one frame shall be present.​

Note​

Receiving applications should be aware that some older applications may send Pixel Data with excess padding, which was​ notexplicitlyprohibitedinearlierversionsoftheStandard.ApplicationsshouldbepreparedtoacceptsuchPixelDataelements,​ but may delete the excess padding. In no case should a sending application place private data in the padding data.​

The field of bits representing the value of a Pixel Sample shall be a binary 2's complement integer or an unsigned integer, as specified​ by the Data Element Pixel Representation (0028,0103). The sign bit shall be the High Bit in a Pixel Sample Value that is a 2's com-​ plement integer. The minimum actual Pixel Sample Value encountered in the Pixel Data is specified by Smallest Image Pixel Value​ (0028,0106) while the maximum value is specified by Largest Image Pixel Value (0028,0107).​

8.1.2 Overlay Data Encoding of Related Data Elements​

Encoded Overlay Planes always have a bit depth of 1, and are encoded separately from the Pixel Data in Overlay Data (60xx,3000).​ The following two Data Elements shall define the Overlay Plane structure:​

•​Overlay Bits Allocated (60xx,0100)​

•​Overlay Bit Position (60xx,0102)​

Note​

1.​There is no Data Element analogous to Bits Stored (0028,0101) since Overlay Planes always have a bit depth of 1.​

2.​RestrictionsontheallowedvaluesfortheseDataElementsaredefinedinPS3.3.Formerlyoverlaydatastoredinunused​ bitsofPixelData(7FE0,0010)wasdescribed,andtheseattributeshadmeaningfulvaluesbutthisusagehasbeenretired.​ See PS3.5-2004. For overlays encoded in Overlay Data (60xx,3000), Overlay Bits Allocated (60xx,0100) is always 1​ and Overlay Bit Position (60xx,0102) is always 0.​

For Overlay Data (60xx,3000), the Value Representation OW is most often required. The Value Representation OB may also be used​ for Overlay Data in cases where the Value Representation is explicitly conveyed (see Annex A).​

Note​

TheDICOMdefaultTransferSyntax(ImplicitVRLittleEndian)doesnotexplicitlyconveyValueRepresentationandtherefore​ the VR of OB may not be used for Pixel Data when using the default Transfer Syntax.​

Overlay Data is encoded as the direct concatenation of the bits of a single Overlay Plane, where the first bit of an Overlay Plane is​ encoded in the least significant bit, immediately followed by the next bit of the Overlay Plane in the next most significant bit. When​ the Overlay Data 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 significant bit, in the next word, or byte, respectively (see Annex D). For Overlay Data encoded with the Value​

- Standard -​

DICOM PS3.5 2020a - Data Structures and Encoding​

Page 65​

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​

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

8.2 Native or Encapsulated Format Encoding​

Pixel data conveyed in the Pixel Data (7FE0,0010) may be sent either in a Native (uncompressed) Format or in an Encapsulated​ Format (e.g., compressed) defined outside the DICOM Standard.​

If Pixel Data (7FE0,0010) is sent in a Native Format, then the Photometric Interpretation (0028,0004) shall be other than:​

•​YBR_RCT​

•​YBR_ICT​

•​YBR_PARTIAL_420​

Note​

These values are not permitted because they are not encodable in an uncompressed form.​

Pixel Data conveyed in the Float Pixel Data (7FE0,0008) or Double Float Pixel Data (7FE0,0009) shall be in a Native (uncompressed)​ Format if encoded in a Standard Transfer Syntax.​

Note​

1.​In future, if Standard Transfer Syntaxes are defined for compression of Float Pixel Data (7FE0,0008) or Double Float​ Pixel Data (7FE0,0009), this constraint may be relaxed and Encapsulated Format permitted.​

2.​This constraint does not apply to Private Transfer Syntaxes.​

If Pixel Data (7FE0,0010) is sent in a Native Format, the Value Representation OW is most often required. The Value Representation​ OB may also be used for Pixel Data (7FE0,0010) in cases where Bits Allocated has a value less than or equal to 8, but only with​ Transfer Syntaxes where the Value Representation is explicitly conveyed (see Annex A).​

Note​

1.​The DICOM default Transfer Syntax (Implicit VR Little Endian) does not explicitly convey Value Representation and​ therefore the VR of OB may not be used for Pixel Data (7FE0,0010) when using the default Transfer Syntax.​

2.​The 32-bit Value Length Field limits the maximum size of large data values such as Pixel Data sent in a Native Format.​

Float Pixel Data (7FE0,0008) is sent in Native Format; the Value Representation shall be OF, Bits Allocated (0028,0100) shall be 32,​ Bits Stored (0028,0101), High Bit (0028,0102) and Pixel Representation (0028,0103) shall not be present.​

Double Float Pixel Data (7FE0,0009) is sent in Native Format; the Value Representation shall be OD, Bits Allocated (0028,0100)​ shall be 64, Bits Stored (0028,0101) and High Bit (0028,0102) and Pixel Representation (0028,0103) shall not be present.​

ItisnotpermittedtohavemorethanoneofPixelDataProviderURL(0028,7FE0),PixelData(7FE0,0010),FloatPixelData(7FE0,0008)​ or Double Float Pixel Data (7FE0,0009) in the top level Data Set.​

Note​

PixelDataencodedinFloatPixelData(7FE0,0008)orDoubleFloatPixelData(7FE0,0009)canbeconsideredasconsisting​ of Pixel Cells that entirely occupy the allocated bits, and therefore do not cross word boundaries.​

Native format Pixel Cells are encoded as the direct concatenation of the bits of each Pixel Cell, the least significant bit of each Pixel​ Cell is encoded in the least significant bit of the encoded word or byte, immediately followed by the next most significant bit of each​ Pixel Cell in the next most significant bit of the encoded word or byte, successively until all bits of the Pixel Cell have been encoded,​ then immediately followed by the least significant bit of the next Pixel Cell in the next most significant bit of the encoded word or byte.​

- Standard -​