Материал: part05

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

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

Page 111​

A.9 SMPTE ST 2110-20 Uncompressed Interlaced Active Video Transfer Syntax​

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

The parameters are similar to the ones described in the [SMPTE ST 2110-20] Uncompressed Progressive Active Video ( label), but​ the frames are interlaced, one frame containing only odd lines and the next one containing only even lines.​

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

•​1.2.840.10008.1.2.7.2 corresponding to [SMPTE ST 2110-20] for the interlaced video.​

A.10 : SMPTE ST 2110-30 PCM Audio Transfer Syntax​

This Transfer Syntax is used in a DICOM-RTV Metadata Flow in order to describe the accompanying SMPTE ST21110-30 Audio​ Flow.​

DICOM Attributes​

•​Number of Waveform Channels (003A,0005) is limited to 15​

•​Number of Waveform Samples (003A,0010) is limited to 96 (1ms at 96 kHz)​

•​Sampling Frequency (003A,001A) shall either be 44100, 48000 or 96000​

•​Waveform Bits Stored (003A,021A) shall either be 16 or 24​

•​Waveform Bits Allocated (5400,1004) shall either be 16 or 24​

•​Waveform Sample Interpretation (5400,1006) shall either be US, SS or OB​

Table A.10-1. ST 2110-30 and DICOM sampling frequency​

 

ST 2110-30 Sampling Frequency​

Sampling frequency(0003,001A)​

 

44.1 kHz​

 

 

 

44100​

 

 

48 kHz*​

 

 

 

48000​

 

 

96 kHz​

 

 

 

96000​

 

Note​

 

 

 

 

 

 

* 48 kHz is recommended by SMPTE​

 

 

 

 

 

Table A.10-2. Waveform Sample Interpretation​

 

Bit Depth​

Waveform Bits Stored​

Waveform Bits​

Waveform Sample​

Wave Sample Interpretation​

 

(003A,021A)​

Allocated (5400,1006)​Interpretation(5400,1006)​

meaning​

16​

16​

 

16​

SS​

signed 16-bit linear​

16​

16​

 

16​

US​

unsigned 16-bit linear​

24​

24​

 

24​

OB​

24 bit linear​

Table A.10-3. Example of Number of Waveform Samples for 48kHz for basic Audio (Mono or Stereo)​

Bit Depth​

Waveform Bits Stored​

Numbers of Waveform​

Number of Waveform​ Resulting packet Length​

 

(003A,021A)​

Channels (003A,0005)​

Sample (003A,0010)​

(1ms)​

16​

16​

1​

48​

96​

24​

24​

1​

48​

144​

16​

16​

2​

48​

192​

- Standard -​

Page 112​

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

 

Bit Depth​

Waveform Bits Stored​

Numbers of Waveform​

Number of Waveform​ Resulting packet Length​

 

(003A,021A)​

Channels (003A,0005)​

Sample (003A,0010)​

(1ms)​

24​

24​

2​

48​

288​

[SMPTE ST 2110-30] restricts the audio Flow:​

•​Sampling frequency is either 44.1 kHz, 48 kHz or 96 kHz, 48 kHz being the recommended value​ •​Coding scheme is either L16 (16-bit linear) or L24 (24-bit linear)​

•​Packet time should be 1ms (but could get down to 125 µs)​ •​Number of Waveform Channels is limited to 15​

A DICOM Transfer Syntax for SMPTE ST 2110-30 PCM Digital Audio shall be identified by a UID value of:​ •​1.2.840.10008.1.2.7.3 corresponding to the SMPTE ST 2110-30 Professional Media over IP Networks: PCM Digital Audio.​

- Standard -​

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

Page 113​

B Creating a Privately Defined Unique​

Identifier (Informative)​

Privately defined Unique Identifiers (UIDs) are used in DICOM to uniquely identify items such as Specialized or Private SOP Classes,​ Image SOP Instances, Study SOP Instances, etc.​

B.1 Organizationally Derived UID​

A UID may be formed using a registered root (see Annex C) and an organization specific suffix. The manner in which the suffix of​ such an organizationally derived UID is defined is not constrained by the DICOM Standard. Only the guarantee of its uniqueness by​ the defining organization is required by DICOM.​

The following example presents a particular choice made by a specific organization in defining its suffix to guarantee uniqueness of​ a SOP Instance UID.​

"1.2.840.xxxxx.3.152.235.2.12.187636473" \___________/ \______________________/

root . suffix

In this example, the root is:​

•​1 Identifies ISO​

•​2 Identifies ANSI Member Body​

•​840 Country code of a specific Member Body (U.S. for ANSI)​

•​xxxxx Identifies a specific Organization.(assigned by ANSI)​

In this example the first two components of the suffix relate to the identification of the device:​

•​3 Manufacturer defined device type​

•​152 Manufacturer defined serial number​

The remaining four components of the suffix relate to the identification of the image:​

•​235 Study number​

•​2 Series number​

•​12 Image number​

•​187636473 Encoded date and time stamp of image acquisition​

Inthisexample,theorganizationhaschosenthesecomponentstoguaranteeuniqueness.Otherorganizationsmaychooseanentirely​ different series of components to uniquely identify its images. For example it may have been perfectly valid to omit the Study Number,​ Series Number and Image Number if the time stamp had a sufficient precision to ensure that no two images might have the same​ date and time stamp.​

BecauseoftheflexibilityallowedbytheDICOMStandardincreatingorganizationallyderivedUIDs,implementationsshouldnotdepend​ on any assumed structure of UIDs and should not attempt to parse UIDs to extract the semantics of some of its components.​

B.2 UUID Derived UID​

[ISO/IEC 9834-8] / [ITU-T X.667] defines a method by which a UID may be constructed from the root "2.25." followed by a decimal​ representation of a Universally Unique Identifier (UUID). That decimal representation treats the 128 bit UUID as an integer, and may​ thus be up to 39 digits long (leading zeros must be suppressed).​

- Standard -​

Page 114​

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

A UUID derived UID may be appropriate for dynamically created UIDs, such as SOP Instance UIDs, but is usually not appropriate​ forUIDsdeterminedduringapplicationsoftwaredesign,suchasprivateSOPClassorTransferSyntaxUIDs,orImplementationClass​ UIDs.​

- Standard -​

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

Page 115​

C DICOM Unique Identifier Registration​

Process (Informative)​

This registration process applies to a number of unique identifiers that share the same properties, structure and registration process.​ It applies to the following identifiers:​

•​The Values assigned to DICOM Data Elements of Value Representation VR = UID (see Table 6.2-1). Such Data Elements are​ defined in PS3.3, PS3.4, PS3.6, and PS3.7.​

•​The DICOM Abstract Syntaxes Names. Abstract Syntax Names are defined in PS3.4.​

•​The DICOM Transfer Syntax Names. Transfer Syntax Names are defined in Annex A.​

•​The DICOM Application Context Names. Application Context Names are defined in PS3.7​

UID structure is based on the numeric form of the OSI Object Identifier as defined by [ISO/IEC 8824]. Values shall be registered as​ defined by [ISO/IEC 9834-1] to ensure global uniqueness.​

The DICOM Standard assigns Values to a number of such unique identifiers. The organization responsible for their registration is​ NEMA, which guarantees uniqueness.​

Forprivatelyregisteredidentifiers,NEMAwillnotactasregistrationauthority.Relatedorganizationsshallobtaintheirproperregistration​ asdefinedforOSIObjectIdentifiersby[ISO/IEC9834-1]toensureglobaluniqueness.NationalStandardsOrganizationsrepresenting​ a number of countries (e.g., UK, France, Japan, USA, etc.) for the International Standards Organization act as a registration authority​ by delegation from ISO, as defined by [ISO/IEC 9834-1].​

Note​

1.​For example, in the USA ANSI assigns, for a fee, Organization Identifiers to any requesting organization. Such an​ identifier may be used by the identified organization as a root to which it may add a suffix made of one or more compon-​ ents. The identified organization accepts the responsibility to properly register these suffixes to ensure uniqueness.​

2.​Following are two typical examples of obtaining a UID <org root>. These examples are not intended to illustrate all the​ possible methods for obtaining a UID <org root>, see [ISO/IEC 8824] and [ISO/IEC 9834-1] for complete specifications.​ Organization identifiers may be obtained from various ISO member bodies (e.g., IBN in Belgium, ANSI in the United​ States, AFNOR in France, BSI in Great Britain, DIN in Germany, COSIRA in Canada).​

The first example shows the case of an <org root> issued by an ISO Member Body (ANSI in the USA in this example).​ The<orgroot>iscomposedofanidentifierforISO,amemberbodybranchidentifier,acountrycodeandanorganization​ ID. Note that there is no requirement that an implementation using an ANSI issued <org root> be made or located in​ the USA. The <org root> is made up of the following components: 1.2.840.xxxxx​

•​1 identifies ISO​

•​2 identifies the ISO member body branch​

•​840 identifies the country code of a specific ISO member body (U.S. for ANSI)​

•​xxxxx identifies a specific organization as registered by the ISO member body ANSI.​

Thesecondexampleshowsthecaseofan<orgroot>issuedbyISO(isdelegatedtoBSI)toaninternationalorganization.​ It is composed of an identifier for ISO, an international organization branch identifier, and an International Code Desig-​ nator.Thevalueofthe<orgroot>isassignedbyaninternationalregistrationauthoritythatmaybeusedbymanydifferent​ UIDs defined by the same international organization. The <org root> is made up of the following components: 1.3.yyyy​

•​1 identifies ISO​

•​3 identifies the international organization branch​

- Standard -​