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 -