Материал: part05

8.2.13 Constraints For SMPTE ST 2110-20 Uncompressed Active Video For DICOM-RTV​

This section describes the constraints applying to pixel data carried in the DICOM-RTV Flow (separated from DICOM-RTV Metadata​ Flow) and fully described in [SMPTE ST 2110-20] .​

The following table describes constraints on the [SMPTE ST 2110-20] Video Flow in terms of the valid values for the corresponding​ DICOM Attributes in the DICOM-RTV Metadata Flow:​

•​Samples per pixel​

•​Bits Allocated​

•​Bits Stored​

•​High Bit​

Table 8.2.13-1. Constraints Applicable to Attributes describing Pixel Data​

DICOM Photometric Interpretation is based on CCIR 601 (aka ITU-R BT.601), therefore some restrictions apply to the possible​ combination of Sampling System and Colorimetry parameters as stated by [SMPTE ST 2110-20] .​

Table 8.2.13-2. List of supported SMPTE ST 2110-20 Parameter Combinations​

Some other [SMPTE ST 2110-20] parameter combinations do not correspond to existing DICOM photometric interpretations, so their​ use is currently not permitted. Table 8.2.13-3 lists the unsupported combinations.​

Table 8.2.13-3. List of unsupported SMPTE ST 2110-20 Parameter Combinations​

- Standard -​

8.3 Waveform Data and Related Data Elements​

The DICOM protocol provides for the exchange of encoded time-based signals, or waveforms, encoded in the Waveform Data​ 5400,1010).​

Note​

Per Section 7.6, an IOD supporting multiple sets of Waveform Data will encapsulate Waveform Data (5400,1010) within a​ Sequence.​

Encoded Waveform Data of various bit depths is accommodated through the Waveform Bits Allocated (5400,1004) Data Element.​ This element defines the size of each waveform data sample within the Waveform Data (5400,1010). Allowed values are 8, 16, 32​ and 64 bits.​

TheValueRepresentationoftheWaveformData(5400,1010)shallbeOW;OBshallbeusedincaseswhereWaveformBitsAllocated​ has a value of 8, but only with Transfer Syntaxes where the Value Representation is explicitly conveyed.​

Note​

1.​Under the Default Transfer Syntax, OB and OW VRs have the identical byte transfer order.​

2.​ConversionofaSOPInstancefromtheDefaultTransferSyntaxtoanExplicitVRTransferSyntax(uncompressed)requires​ theinterpretationoftheWaveformBitsAllocated(5400,1004)DataElement,todeterminetheproperVRoftheWaveform​ Data.​

The following data elements related to Waveform Data shall be encoded with the same VR as Waveform Data: Channel Minimum​ Value (5400,0110), Channel Maximum Value (5400,0112) and Waveform Padding Value (5400,100A).​

8.4 Pixel Data Provider Service​

Specific Transfer Syntaxes allow for the pixel data of the message to be replaced with a reference to a pixel data provider service.​ The pixel data provider service that is referenced supplies the pixel data using a network protocol that is defined outside DICOM.​

Note​

The Pixel Data Provider Service is not applicable to Pixel Data encoded as Float Pixel Data (7FE0,0008) or Double Float​ Pixel Data (7FE0,0009).​

8.4.1 JPIP Referenced Pixel Data​

DICOM provides a mechanism for supporting the use of JPEG 2000 Interactive Protocol through the inclusion of a URL reference to​ a pixel data provider service. Annex A defines two Transfer Syntaxes that utilize URL references to a JPIP pixel data provider service.​

The use of the these Transfer Syntaxes requires that the Pixel Data Provider URL specify a URL that will represent the JPIP request​ includingthespecifictargetinformation.AdditionalparametersrequiredbytheapplicationmaybeappendedtotheURLwhenaccessing​ the pixel data provider.​

Note​

For example, a JPIP request for a 200 by 200 pixel rendition of the entire image can be constructed from the Pixel Data​ Provider URL as follows:​

Pixel Data Provider URL (0028,7FE0) = http://server.xxx/jpipserver.cgi?target=imgxyz.jp2​

URL Generated by the application = http://server.xxx/jpipserver.cgi?target=imgxyz.jp2&fsiz=200,200​

The JPIP client shall only request a JPEG 2000 bit stream.​

The JPIP server shall return a Content-type of image/jp2, image/jpp-stream or image/jpt-stream, all of which shall be supported by​ the JPIP client.​

- Standard -​

The Number of Frames (0028,0008) attribute, if present in the Data Set, identifies the number of frames available for this image. Each​ frame is accessible as a separate JPIP code stream. Code streams referenced in the URL Target shall be sequentially numbered​ starting with stream 1.​

Note​

For example, a JPIP request for a 200 by 200 pixel rendition of frame 17 of a multi-frame image can be constructed from​ Pixel Data Provider URL as follows:​

Pixel Data Provider URL (0028,7FE0) = http://server.xxx/multiframeimage.jp2​

URL Generated by the application = http://server.xxx/multiframeimage.jp2?fsiz=200,200&stream=17​

A valid stream query parameter value is always less than or equal to the value in the Number of Frames (0028,0008).​

The syntax of the Pixel Data Provider URL (0028,7FE0) is defined in [ISO/IEC 15444-9] Annex C (Client Request). That standard​ respects the URI recommendations [RFC3986]. The transport protocol shall be HTTP or HTTPS.​

Note​

1.​According to [ISO/IEC 15444-9], "Each JPIP request is directed to a specific representation of a specific original named​ resource or a specific portion of that resource. That resource may be a physically stored file or object, or may be​ something that is created virtually by the server upon request."​

"The Target request field specifies the original named resource to which the request is directed. It is specified using a​ PATH, which could be a simple string or a URI. If the Target field is not specified and the request is carried over HTTP,​ then the JPIP request shall be directed to the resource specified through the path component of the JPIP request URL."​

2.​Transport over UDP or other protocols is not supported.​

8.5 Security Considerations for Encoding of Pixel, Overlay, and Waveform Data (Informative)​

The encapsulated formats conform to other standards, e.g., JPEG. Many of these formats have had their own security issues, both​ with the format itself and with common implementations for processing the format.​

Implementations that support encapsulated format encoding may need to:​

•​Perform input validation and sanitation to detect and perhaps remove invalid or malicious content.​

•​Perform output validation to ensure safe compliance with format specification.​

•​Monitor library implementations for vulnerability reports, updates, and have a process for managing these updates.​

Tracking, notification, and remediation of these security problems will normally be in the context of the encapsulated format and not​ in the context of DICOM. This means those implementing and deploying the encapsulated format must consider security issues from​ those other contexts.​

- Standard -​

9 Unique Identifiers (UIDs)​

UniqueIdentifiers(UIDs)providethecapabilitytouniquelyidentifyawidevarietyofitems.Theyguaranteeuniquenessacrossmultiple​ countries,sites,vendorsandequipment.Differentclassesofobjects,instanceofobjectsandinformationentitiescanbedistinguished​ from one another across the DICOM universe of discourse irrespective of any semantic context.​

Note​

ForexamplethesameUIDvaluecannotbeusedtoidentifybothastudyinstance(StudyInstanceUID)andaseriesinstance​ (Series Instance UID) within that study or a different study. Implementers also need to be cautioned against building new​ UID values by derivation (for example by adding a suffix) from a UID assigned by another implementation.​

The UID identification scheme is based on the OSI Object Identification (numeric form) as defined by the [ISO/IEC 8824] standard.​ All Unique Identifiers, used within the context of the DICOM Standard, are registered values as defined by [ISO/IEC 9834-1] to ensure​ global uniqueness. The uses of such UIDs are defined in the various Parts of the DICOM Standard.​

Each UID is composed of two parts, an <org root> and a <suffix>:​

UID = <org root>.<suffix>​

The <org root> portion of the UID uniquely identifies an organization, (i.e., manufacturer, research organization, NEMA, etc.), and is​ composed of a number of numeric components as defined by [ISO/IEC 8824]. The <suffix> portion of the UID is also composed of a​ number of numeric components, and shall be unique within the scope of the <org root>. This implies that the organization identified​ inthe<orgroot>isresponsibleforguaranteeing<suffix>uniquenessbyprovidingregistrationpolicies.Thesepoliciesshallguarantee​ <suffix>uniquenessforallUIDscreatedbythatorganization.Unlikethe<orgroot>,whichmaybecommonforUIDsinanorganization,​ the <suffix> shall take different unique values between different UIDs that identify different objects.​

The <org root> "1.2.840.10008" is reserved for DICOM defined items (such as DICOM Transfer Syntaxes) and shall not be used for​ privately defined items (such as an Image Instance).​

Although a specific implementation may choose some particular structure for its generated UIDs, it should never assume that a UID​ carries any semantics. Thus, a UID shall not be "parsed" to find a particular value or component. Component definition (for the suffix)​ is implementation specific and may change as long as uniqueness is maintained. Parsing UIDs may jeopardize the ability to inter-​ operate as implementations evolve.​

Example of UID structure is given in Annex C.​

9.1 UID Encoding Rules​

The DICOM UID encoding rules are defined as follows:​

•​Each component of a UID is a number and shall consist of one or more digits. The first digit of each component shall not be zero​ unless the component is a single digit.​

Note​

Registrationauthoritiesmaydistributecomponentswithnon-significantleadingzeroes.Theleadingzeroesshouldbeignored​ when being encoded (i.e.,"00029" would be encoded "29").​

•​Eachcomponentnumericvalueshallbeencodedusingthecharacters0-9oftheBasicG0SetoftheInternationalReferenceVersion​ of ISO 646:1990 (the DICOM Default Character Repertoire).​

•​Components shall be separated by the character "." (2EH).​

•​If ending on an odd byte boundary, except when used for network negotiation (see PS3.8), one trailing NULL (00H), as a padding​ character, shall follow the last component in order to align the UID on an even byte boundary.​

•​UIDs, shall not exceed 64 total characters, including the digits of each component, separators between components, and the NULL​ (00H) padding character if needed.​

- Standard -​

9.2 Unique Identifier Registration​

Each UID used in DICOM shall be defined and registered in one of the following two ways:​

•​DICOM defined and registered UIDs​

•​Privately defined and registered UIDs​

Both UIDs use the same encoding rules as defined in Section 9.1. See Annex C for a more detailed description of the UID registration​ process.​

9.2.1 DICOM Defined and Registered Unique Identifiers​

A limited number of registered DICOM Defined UIDs are used within the DICOM Standard. The organization responsible for the​ definition and registration of such DICOM UIDs is NEMA.​

The registration process will rely on the publication of the DICOM Registered UIDs in PS3.6.​

9.2.2 Privately Defined Unique Identifiers​

Privately Defined UIDs are commonly used within DICOM. However, such UIDs will not be registered by NEMA. Organizations that​ define private UIDs are responsible for properly registering their UIDs (at least obtain a registered <Org Root>) as defined for OSI​ ObjectIdentifiers[ISO/IEC9834-1].TheprivateorganizationdefiningtheUIDshallaccepttheresponsibilityofensuringitsuniqueness.​

- Standard -​