Table of Contents
List of Figures
List of Tables
List of Examples
The information in this publication was considered technically sound by the consensus of persons engaged in the development and approval of the document at the time it was developed. Consensus does not necessarily mean that there is unanimous agreement among every person participating in the development of this document.
NEMA standards and guideline publications, of which the document contained herein is one, are developed through a voluntary consensus standards development process. This process brings together volunteers and/or seeks out the views of persons who have an interest in the topic covered by this publication. While NEMA administers the process and establishes rules to promote fairness in the development of consensus, it does not write the document and it does not independently test, evaluate, or verify the accuracy or completeness of any information or the soundness of any judgments contained in its standards and guideline publications.
NEMA disclaims liability for any personal injury, property, or other damages of any nature whatsoever, whether special, indirect, consequential, or compensatory, directly or indirectly resulting from the publication, use of, application, or reliance on this document. NEMA disclaims and makes no guaranty or warranty, expressed or implied, as to the accuracy or completeness of any information published herein, and disclaims and makes no warranty that the information in this document will fulfill any of your particular purposes or needs. NEMA does not undertake to guarantee the performance of any individual manufacturer or seller's products or services by virtue of this standard or guide.
In publishing and making this document available, NEMA is not undertaking to render professional or other services for or on behalf of any person or entity, nor is NEMA undertaking to perform any duty owed by any person or entity to someone else. Anyone using this document should rely on his or her own independent judgment or, as appropriate, seek the advice of a competent professional in determining the exercise of reasonable care in any given circumstances. Information and other standards on the topic covered by this publication may be available from other sources, which the user may wish to consult for additional views or information not covered by this publication.
NEMA has no power, nor does it undertake to police or enforce compliance with the contents of this document. NEMA does not certify, test, or inspect products, designs, or installations for safety or health purposes. Any certification or other statement of compliance with any health or safety-related information in this document shall not be attributable to NEMA and is solely the responsibility of the certifier or maker of the statement.
This DICOM Standard was developed according to the procedures of the DICOM Standards Committee.
The DICOM Standard is structured as a multi-part document using the guidelines established in [ISO/IEC Directives, Part 2].
DICOM® is the registered trademark of the National Electrical Manufacturers Association for its standards publications relating to digital communications of medical information, all rights reserved.
HL7® and CDA® are the registered trademarks of Health Level Seven International, all rights reserved.
SNOMED®, SNOMED Clinical Terms®, SNOMED CT® are the registered trademarks of the International Health Terminology Standards Development Organisation (IHTSDO), all rights reserved.
LOINC® is the registered trademark of Regenstrief Institute, Inc, all rights reserved.
In this Part of the Standard the structure and encoding of the Data Set is specified. In the context of Application Entities communicating over a network (see PS3.7), a Data Set is that portion of a DICOM Message that conveys information about real world objects being managed over the network. A Data Set may have other contexts in other applications of this Standard; e.g., in media exchange the Data Set translates to file content structure.
This Part of the DICOM Standard specifies:
This Part of the DICOM Standard does not specify:
the structure and syntax of a message (this is specified in PS3.7)
the structure and usage of a Command Set (this is specified in PS3.7)
how an application service functions or is classified (this is specified in PS3.3 and PS3.4)
how Data Sets relate to network communication, media storage, or other services
The following standards contain provisions that, through references in this text, constitute provisions of this Standard. At the time of publication, the editions indicated were valid. All standards are subject to revision, and parties to agreements based on this Standard are encouraged to investigate the possibilities of applying the most recent editions of the standards indicated below.
[ANSI HISPP MSDS] 1993. Healthcare Informatics Standards Planning Panel Message Standard Developers Subcommittee Proposal on Common Data Types. http://www.meb.uni-bonn.de/standards/HISPP/MSDS/CommonDataType1102.ps .
[ANSI X3.4] 1986. Coded Character Set - 7-Bit American National Standard Code for Information Interchange.
[ANSI X3.9] 1978. Programming Language FORTRAN. http://www.fortran.com/F77_std/rjcnf-0.html .
[ASTM E-1238-91] 1991. Standard Specification for Transferring Clinical Observations Between Independent Computer Systems; Draft Revision 4.2.1.
[BDRWP 2.B] March 2005. White Paper Blu-ray Disc™ Format 2.B Audio Visual Application Format Specifications for BD-ROM.
[ECMA TR-098] 2009. JPEG File Interchange Format (JFIF). http://www.ecma-international.org/publications/techreports/E-TR-098.htm .
[IEEE 754] 2019. IEEE Standard for Floating Point Arithmetic. http://dx.doi.org/10.1109/IEEESTD.2019.8766229 .
[ISO/IEC Directives, Part 2] 2016/05. 7.0. Rules for the structure and drafting of International Standards. http://www.iec.ch/members_experts/refdocs/iec/isoiecdir-2%7Bed7.0%7Den.pdf .
[ISO/IEC 6429] 1990. Information Processing - Control functions for 7-bit and 8-bit coded character sets.
[ISO 7498] 1984. Information processing systems - Open System Interconnection - Basic Reference Model.
[ISO 7498-4] 1989. Information processing systems - Open Systems Interconnection - Part 4: Management Framework.
[ISO 8649] 1988. Information processing systems - Open Systems Interconnection - Service definition for the Association Control Service Element (ACSE).
[ISO 8822] 1988. Information processing systems - Open Systems Interconnection - Connection oriented presentation service definition.
[ISO/IEC 8824] 1990. Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1).
[ISO/IEC 8859-1] 1987. Information processing - 8-bit single-byte coded graphic character sets - Part 1: Latin alphabet No. 1.
[ISO/IEC 8859-2] 1987. Information processing - 8-bit single-byte coded graphic character sets - Part 2: Latin alphabet No. 2.
[ISO/IEC 8859-3] 1988. Information processing - 8-bit single-byte coded graphic character sets - Part 3: Latin alphabet No. 3.
[ISO/IEC 8859-4] 1988. Information processing - 8-bit single-byte coded graphic character sets - Part 4: Latin alphabet No. 4.
[ISO/IEC 8859-5] 1988. Information processing - 8-bit single-byte coded graphic character sets - Part 5: Latin/Cyrillic alphabet.
[ISO/IEC 8859-6] 1987. Information processing - 8-bit single-byte coded graphic character sets - Part 6: Latin/Arabic alphabet.
[ISO/IEC 8859-7] 1987. Information processing - 8-bit single-byte coded graphic character sets - Part 7: Latin/Greek alphabet.
[ISO/IEC 8859-8] 1988. Information processing - 8-bit single-byte coded graphic character sets - Part 8: Latin/Hebrew alphabet.
[ISO/IEC 8859-9] 1989. Information processing - 8-bit single-byte coded graphic character sets - Part 9: Latin alphabet No. 5.
[ISO/IEC 8859-15] 1999. Information technology — 8-bit single-byte coded graphic character sets — Part 15: Latin alphabet No. 9.
[ISO/IEC 9834-1] 2005. Information technology - Open Systems Interconnection - Procedures for the operation of OSI Registration Authorities: General procedures and top arcs of the ASN.1 Object Identifier tree.
[ISO/IEC 9834-8] 2014. Information technology - Open Systems Interconnection - Procedures for the operation of OSI Registration Authorities: Generation of universally unique identifiers (UUIDs) and their use in object identifiers.
[ISO/IEC 10646] 2020. Information Technology - Universal Coded Character Set (UCS). ISO/IEC 10646-2020 is the same as Unicode Version 13.0, available at http://unicode.org .
[ISO/IEC 10918-1] 1994. JPEG Standard for digital compression and encoding of continuous-tone still images. Part 1 - Requirements and implementation guidelines.
[ISO/IEC 10918-2] 1995. JPEG Standard for digital compression and encoding of continuous-tone still images. Part 2 - Testing.
[ISO/IEC 10918-5] 2013. JPEG Standard for digital compression and encoding of continuous-tone still images. Part 5 - JPEG File Interchange Format (JFIF).
[ISO/IEC 11172-3] 1993. Information technology -- Coding of moving pictures and associated audio for digital storage media at up to about 1,5 Mbit/s -- Part 3: Audio.
[ISO/IEC 13818-1] 2000. Information technology -- Generic coding of moving pictures and associated audio information - Part 1: Systems.
[ISO/IEC 13818-2] 2000. Information technology -- Generic coding of moving pictures and associated audio information - Part 2: Video.
[ISO/IEC 13818-3] 1998. Information technology -- Generic coding of moving pictures and associated audio information - Part 3: Audio.
[ISO/IEC 13818-4] 1998. Information technology -- Generic coding of moving pictures and associated audio information - Part 4: Conformance testing.
[ISO/IEC 13818-7] 1997. Information technology -- Generic coding of moving pictures and associated audio information - Part 7: Advanced Audio Coding (AAC).
[ISO/IEC 14495-1] 1997. Lossless and near-lossless coding of continuous tone still images (JPEG-LS).
[ISO/IEC 14496-10] 2009. Information technology - Coding of audio-visual objects - Part 10: Advanced Video Coding.
[ISO/IEC 14496-12] 2003. Information technology - Coding of audio-visual objects - Part 12: ISO base media file format.
[ISO/IEC 14496-14] 2003. Information technology - Coding of audio-visual objects - Part 14: MP4 file format.
[ISO 15076-1] 2005. Image technology colour management - Architecture, profile format, and data structure. Also available as ICC.1:2004-10 (Profile version 4.2.0.0), International Color Consortium, available at http://www.color.org/v4spec.xalter .
[ISO/IEC 15444-9] 2005. Information technology - JPEG 2000 image coding system: Interactivity tools, APIs and protocols.
[ISO/IEC 15444-15] 2019. Information technology - JPEG 2000 image coding system — Part 15: High-Throughput JPEG 2000.
[ISO/IEC 18181-1] 2022. Information technology - JPEG XL Image Coding System - Part 1 Core Coding System.
[ISO/IEC 23008-2] Information technology - High efficiency coding and media delivery in heterogeneous environments - Part 2: High efficiency video coding. http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=67660 .
[ITU-T X.667] 2012. Information technology - Procedures for the operation of object identifier registration authorities: Generation of universally unique identifiers and their use in object identifiers. http://www.itu.int/rec/T-REC-X.667/en .
[ENV 41 503] 1990. Information systems interconnection - European graphic character repertoires and their coding.
[ENV 41 508] 1990. Information systems interconnection - East European graphic character repertoires and their coding.
[JIS X 0212] 1990. Code of the supplementary Japanese Graphic Character set for information interchange.
[RFC1468] Japanese Character Encoding for Internet Messages. http://tools.ietf.org/html/rfc1468 .
[RFC1554] ISO-2022-JP-2: Multilingual Extension of ISO-2022-JP. http://tools.ietf.org/html/rfc1554 .
[RFC1951] DEFLATE Compressed Data Format Specification version 1.3. http://tools.ietf.org/html/rfc1951 .
[RFC3986] Uniform Resource Identifiers (URI) : Generic Syntax. http://tools.ietf.org/html/rfc3986 .
[RFC3987] Internationalized Resource Identifiers (IRIs). http://tools.ietf.org/html/rfc3987 .
[RFC5890] Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework. http://tools.ietf.org/html/rfc5890 .
[RFC5891] Internationalized Domain Names in Applications (IDNA): Protocol. http://tools.ietf.org/html/rfc5891 .
[TIS 620-2533] 1990. Thai Characters Code for Information Interchange. http://www.nectec.or.th/it-standards/std620/std620.html .
For the purposes of this Standard, the following definitions apply.
This Part of the Standard makes use of the following terms defined in [ISO 7498]:
See [ISO 7498].
See [ISO 7498].
This Part of the Standard makes use of the following terms defined in [ISO 8649]:
See [ISO 8649].
This Part of the Standard makes use of the following terms defined in [ISO 8822]:
See [ISO 8822].
See [ISO 8822].
See [ISO 8822].
See [ISO 8822].
This Part of the Standard makes use of the following terms defined in [ISO/IEC 8824]:
See [ISO/IEC 8824].
This Part of the Standard makes use of the following terms defined in PS3.1:
This Part of the Standard makes use of the following terms defined in PS3.2:
This Part of the Standard makes use of the following terms defined in PS3.3:
This Part of the Standard makes use of the following terms defined in PS3.4:
This Part of the Standard makes use of the following terms defined in PS3.8:
The following definitions are commonly used in this Standard:
A table of 32-bit pointers to individual Frames of an encapsulated Multi-frame Image.
A form of byte ordering where multiple byte binary values are encoded with the most significant byte encoded first, and the remaining bytes encoded in decreasing order of significance.
A finite set of different characters that is considered to be complete for a given purpose and is specified independently of their encoding (also referred to as a character set).
A string of characters identifying a controlled concept, including Defined Terms and Enumerated Values when represented as character strings. The scope of the controlled concept is limited to the Attribute for which the string provides the Value; i.e., the Attribute defines the allowed set of Values for the Code String, and a particular string may have different meanings in different Attributes. A Code String is formally an arbitrary code representing a semantic concept; however, English language words (using the constrained character set of the CS Value Representation) are often used as codes for the semantics of those words.
A unit of information as defined by a single entry in the data dictionary. An encoded Information Object Definition (IOD) Attribute that is composed of, at a minimum, three fields: a Data Element Tag, a Value Length, and a Value Field. For some specific Transfer Syntaxes, a Data Element also contains a VR Field where the Value Representation of that Data Element is specified explicitly.
A unique identifier for a Data Element composed of an ordered pair of numbers (a Group Number followed by an Element Number).
The field within a Data Element structure that contains the Data Element Tag.
Used to specify whether an Attribute of an Information Object Definition or an Attribute of a SOP Class Definition is mandatory, mandatory only under certain conditions, or optional. This translates to whether a Data Element of a Data Set is mandatory, mandatory only under certain conditions, or optional.
Exchanged information consisting of a structured set of Attribute values directly or indirectly related to Information Objects. The value of each Attribute in a Data Set is expressed as a Data Element. A collection of Data Elements ordered by increasing Data Element Tag number that is an encoding of the values of Attributes of a real world object.
The Basic G0 Set of the International Reference Version of [ISO 646] (ISO-IR 6) used as the default repertoire for character strings in DICOM.
The Value of a Data Element is a Defined Term when the Value of the Data Element may be one of an explicitly specified set of standard Values, and these Values may be extended by implementers.
The second number in the ordered pair of numbers that makes up a Data Element Tag.
The Pixel Data Stream is encoded in a form wherein Fragments are contained within Item Tags within the Pixel Data (7FE0,0010) Data Element, usually used for compressed data.
The Value of a Data Element is an Enumerated Value when the Value of the Data Element must be one of an explicitly specified set of standard Values, and these Values shall not be extended by implementers.
An encoding of a Data Element structure where the Value Representation of that Data Element is specified explicitly in the Value Representation Field.
A table of 64-bit pointers to individual Frames of an encapsulated Multi-frame Image.
One part or all of a Pixel Data Stream encoded within Encapsulated Pixel Data.
A Transfer Syntax that allows the Encapsulated Format Pixel Data Stream to be split into one or more Fragments.
The first number in the ordered pair of numbers that makes up a Data Element Tag.
An encoding of a Data Element structure where the Value Representation of that Data Element is specified implicitly, i.e. not in the Value Representation Field. This encoding is used for the DICOM Default Little Endian Transfer Syntax (see Section 10.1).
A component of the Value of a Data Element that is of Value Representation Sequence of Items. An Item contains a Data Set.
Used to mark the end of an Item of Undefined Length in a Sequence of Items. This is the last Data Element in an Item of Undefined Length.
A form of byte ordering where multiple byte binary values are encoded with the least significant byte encoded first; and the remaining bytes encoded in increasing order of significance.
The Pixel Data Stream is encoded in an uncompressed form and occupies the entire Value of the Pixel Data (7FE0,0010) Data Element.
A Data Set contained within a Data Element of another Data Set. Data Sets can be nested recursively. Only Data Elements with Value Representation Sequence of Items may, themselves, contain Data Sets.
A Transfer Syntax that requires the entire Encapsulated Format Pixel Data Stream be encoded in a single Fragment.
The container for a single Pixel Sample Value that may include unused bits. The size of a Pixel Cell shall be specified by the Bits Allocated (0028, 0100) Data Element.
Graphical data (e.g., images) of variable pixel-depth encoded in the Pixel Data, Float Pixel Data or Double Float Pixel Data Element.
The compressed or uncompressed octet-stream that constitutes the Pixel Data itself, without any DICOM-specific encapsulation structures.
A value associated with an individual pixel. An individual pixel consists of one or more Pixel Sample Values (e.g., color images).
Additional Data Element, defined by an implementer, to communicate information that is not contained in Standard Data Elements. Private Data Elements have odd Group Numbers.
Standard Data Elements within a particular range of Group Numbers where Data Elements that have identical Element Numbers have the same meaning within each Group (and the same VR, VM, and Data Element Type). Repeating Groups shall only exist for Overlay Planes (Group Numbers 60xx) and are a remnant of older versions of this Standard.
Repeating Groups were also used for Curves that were previously defined but have been retired. See PS3.5-2004.
A Data Element that is unsupported beginning with the current Standard. Implementations may continue to support Retired Data Elements for the purpose of backward compatibility, but this is not a requirement of the current Standard.
Item used to mark the end of a Sequence of Items of Undefined Length. This Item is the last Item in a Sequence of Items of Undefined Length.
A Value Representation for Data Elements that contain a sequence of Data Sets. Sequence of Items allows for Nested Data Sets.
A Data Element defined in the DICOM Standard, and therefore listed in the DICOM Data Element Dictionary in PS3.6.
A set of encoding rules that allow DICOM Application Entities to unambiguously negotiate the encoding techniques (e.g., Data Element structure, byte ordering, compression) they are able to support, thereby allowing these Application Entities to communicate. See also Transfer Syntax.
The ability to specify an unknown length for a Data Element Value (of Value Representation SQ, UN, OW, or OB) or Item. Data Elements and Items of Undefined Length are delimited with Sequence Delimitation Items and Item Delimitation Data Elements, respectively.
A string of characters used to provide global unique identification of a wide variety of items, guaranteeing uniqueness across multiple countries, sites, vendors and equipment. It uses the structure defined by [ISO/IEC 8824] for OSI Object Identifiers.
A component of a Value Field. A Value Field may consist of one or more of these components.
The field within a Data Element structure that contains the Value(s) of that Data Element.
The field within a Data Element structure that contains the Value Length.
Specifies the number of Values contained in the Value Field of a Data Element.
Specifies the data type and format of the Value(s) contained in the Value Field of a Data Element.
The field where the Value Representation of a Data Element is stored in the encoding of a Data Element structure with Explicit VR.
This Part of the Standard makes use of the following terms defined in [ISO/IEC 2022]
See [ISO/IEC 2022].
See [ISO/IEC 2022].
See [ISO/IEC 2022].
See [ISO/IEC 2022].
See [ISO/IEC 2022].
See [ISO/IEC 2022].
See [ISO/IEC 2022].
The following symbols and abbreviations are used in this Standard.
Word(s) are capitalized in this document (not headings) to help the reader understand that these word(s) have been previously defined in Section 3 of this document and are to be interpreted with that meaning.
The Data Element Tag is represented as (gggg,eeee), where gggg equates to the Group Number and eeee equates to the Element Number within that Group. The Data Element Tag is represented in hexadecimal notation as specified for each Data Element in PS3.6.
The notation XXXXH, where XXXX is one or more hexadecimal digits, and "H" is used to signify a hexadecimal number.
A Data Set is constructed by encoding the Values of Attributes specified in the Information Object Definition (IOD) of a Real-World Object. The specific content and semantics of these Attributes are specified in Information Object Definitions (see PS3.3). The range of possible data types of these Values and their encoding are specified in this section. The structure of a Data Set, which is composed of Data Elements containing these Values, is specified in Section 7.
Throughout this Part, as well as other parts of the DICOM Standard, Tags are used to identify both specific Attributes and their corresponding Data Elements.
Values that are text or character strings can be composed of Graphic and Control Characters. The Graphic Character set, independent of its encoding, is referred to as a Character Repertoire. Depending on the native language context in which Application Entities wish to exchange data using the DICOM Standard, different Character Repertoires will be used. The Character Repertoires supported by DICOM are:
[ISO/IEC 8859] 8-bit single-byte coded graphic character sets
[JIS X 0201] Code for Information Interchange
[JIS X 0208] Code for the Japanese Graphic Character set for information interchange
[JIS X 0212] Code of the supplementary Japanese Graphic Character set for information interchange
[KS X 1001] (registered as ISO-IR 149) for Korean Language
[TIS 620-2533] Thai Characters Code for Information Interchange
[ISO/IEC 10646] for the Unicode character set
[ISO/IEC 10646] corresponds to the Unicode character set. The ISO IR 192 corresponds to the use of the UTF-8 encoding for this character set.
The [GB 18030] character set is harmonized with the Unicode character set on a regular basis, to reflect updates from both the Chinese language and from Unicode extensions to support other languages.
The issue of font selection is not addressed by the DICOM Standard. Issues such as proper display of words like "bone" in Chinese or Japanese usage are managed through font selection. Similarly, other user interface issues like bidirectional character display and text orientation are not addressed by the DICOM Standard. The Unicode documents provide extensive documentation on these issues.
The [GBK] character set is an extension of the [GB 2312] character set and supports the Chinese characters in [GB 18030] that is the Chinese adaptation of Unicode. The [GBK] is code point backward compatible to [GB 2312]. The [GB 18030] character set is an extension of the [GBK] character set for support of Unicode, and provides backward code point compatibility.
As defined in the ISO Standards referenced in this section, byte values used for encoded representations of characters are represented in this section as two decimal numbers in the form column/row.
This means that the value can be calculated as (column * 16) + row, e.g., 01/11 corresponds to the value 27 (1BH).
Two digit hex notation will be used throughout the remainder of this Standard to represent character encoding. The column/row notation is used only within Section 6.1 to simplify any cross referencing with applicable ISO standards.
The byte encoding space is divided into four ranges of values:
[ISO/IEC 8859] does not differentiate between a code element, e.g., G0, and the area in the code table, e.g., GL, where it is invoked. The term "G0" specifies the code element as well as the area in the code table. In ISO/IEC 2022 there is a clear distinction between the code elements (G0, G1, G2, and G3) and the areas in which the code elements are invoked (GL or GR). In this Standard the nomenclature of ISO/IEC 2022 is used.
The Control Character set C0 shall be invoked in CL and the Graphic Character sets G0 and G1 in GL and GR respectively. Only some Control Characters from the C0 set are used in DICOM (see Section 6.1.3), and characters from the C1 set shall not be used.
A Character Repertoire, or character set, is a collection of Graphic Characters specified independently of their encoding.
The default repertoire for character strings in DICOM shall be the Basic G0 Set of the International Reference Version of [ISO 646] (ISO-IR 6). See Annex E for a table of the DICOM default repertoire and its encoding.
This Basic G0 Set is identical with the common character set of [ISO/IEC 8859].
DICOM Application Entities (AEs) that extend or replace the default repertoire convey this information in the Specific Character Set (0008,0005) Attribute.
The Attribute Specific Character Set (0008,0005) is encoded using a subset of characters from ISO-IR 6. See the definition for the Value Representation (VR) of Code String (CS) in Table 6.2-1.
For Data Elements with Value Representations of SH (Short String), LO (Long String), UC (Unlimited Characters), ST (Short Text), LT (Long Text), UT (Unlimited Text) or PN (Person Name) the Default Character Repertoire may be extended or replaced (these Value Representations are described in more detail in Section 6.2). If such an extension or replacement is used, the relevant "Specific Character Set" shall be defined as an Attribute of the SOP Common Module (0008,0005) (see PS3.3) and shall be stated in the Conformance Statement. PS3.2 gives conformance guidelines.
Preferred repertoires as defined in ENV 41 503 and ENV 41 508 for the use in Western and Eastern Europe, respectively, are: ISO-IR 100, ISO-IR 101, ISO-IR 144, ISO-IR 126. See Section 6.1.2.3.
Information Object Definitions using different character sets cannot rely per se on lexical ordering or string comparison of Data Elements represented as character strings. These operations can only be carried out within a given character repertoire and not across repertoire boundaries.
The 7-bit Default Character Repertoire can be replaced for use in Value Representations SH, LO, ST, LT, PN, UC and UT with one of the single-byte codes defined in PS3.3.
This replacement character repertoire does not apply to other textual Value Representations (AE and CS).
The replacement character repertoire shall be specified in Value 1 of the Attribute Specific Character Set (0008,0005). Defined Terms for the Attribute Specific Character Set are specified in PS3.3.
The code table is split into the GL area, which supports a 94 character set only (bit combinations 02/01 to 07/14) plus SPACE in 02/00, and the GR area, which supports either a 94 or 96 character set (bit combinations 10/01 to 15/14 or 10/00 to 15/15). The default character set (ISO-IR 6) is always invoked in the GL area.
All character sets specified in [ISO/IEC 8859] include ISO-IR 6. This set will always be invoked in the GL area of the code table and is the equivalent of ASCII [ANSI X3.4]), whereas the various extension repertoires are mapped onto the GR area of the code table.
The 8-bit code table of [JIS X 0201] includes ISO-IR 14 (romaji alphanumeric characters) as the G0 code element and ISO-IR 13 (katakana phonetic characters) as the G1 code element. ISO-IR 14 is identical to ISO-IR 6, except that bit combination 05/12 represents a "¥" (YEN SIGN) and bit combination 07/14 represents an over-line.
Two character codes of the single-byte character sets invoked in the GL area of the code table, 02/00 and 05/12, have special significance in the DICOM Standard. The character SPACE, represented by bit combination 02/00, shall be used for the padding of Data Element Values that are character strings. The Graphic Character represented by the bit combination 05/12, "\" (BACKSLASH) (reverse solidus) in the repertoire ISO-IR 6, shall only be used in character strings with Value Representations of UT, ST and LT (see Section 6.2). Otherwise the character code 05/12 is used as a separator for multi-valued Data Elements (see Section 6.4).
When the Value of Specific Character Set (0008,0005) is either "ISO_IR 13" or "ISO 2022 IR 13", the graphic character represented by the bit combination 05/12 is a "¥" (YEN SIGN) in the character set of ISO-IR 14.
The expected behavior on conversion during store-and-forward operations needs to be equivalent to the action of separating a multi-valued character stream for multi-valued VRs into individual values between 05/12 byte delimiters and to recombine them separated by 05/12 byte delimiters, regardless of which Graphic Character 05/12 represents in the respective Character Set.
Graphic Characters that match the delimiter specified for the Character Set for multi-valued VRs cannot be represented as Values in that Character Set. I.e., a BACKSLASH encoded as 05/12 cannot be present within a Value (as opposed to between Values) in the Default Character Set and a YEN SIGN encoded as 05/12 cannot be present within a Value in [JIS X 0201].
The character DELETE (bit combination 07/15) shall not be used in DICOM character strings.
The replacement Character Repertoire specified in Value 1 of Specific Character Set (0008,0005) (or the Default Character Repertoire if Value 1 is empty) may be further extended with additional Coded Character Sets, if needed and permitted by the replacement Character Repertoire. The additional Coded Character Sets and extension mechanism shall be specified in additional Values of the Attribute Specific Character Set. If Attribute Specific Character Set (0008,0005) has a single Value, the DICOM SOP Instance supports only one code table and no Code Extension techniques. If Attribute Specific Character Set (0008,0005) has multiple Values, the DICOM SOP Instance supports Code Extension techniques as described in ISO/IEC 2022:1994.
The Character Repertoires that prohibit extension are identified in PS3.3.
Considerations on the Handling of Unsupported Character Sets:
In DICOM, character sets are not negotiated between Application Entities but are indicated by a conditional Attribute of the SOP Common Module. Therefore, implementations may be confronted with character sets that are unknown to them.
The Unicode Standard includes a substantial discussion of the recommended means for display and print for characters that lack font support. These same recommendations may apply to the mechanisms for unsupported character sets.
The machine should print or display such characters by replacing all unknown characters with the four characters "\nnn", where "nnn" is the three digit octal representation of each byte.
An example of this for an ASCII based machine would be as follows:
Encoded representation: 04/07 15/12 06/14 07/04 06/08 06/05 07/02
ASCII based machine: G\374nther
Implementations may also encounter Control Characters that they have no means to print or display. The machine may print or display such Control Characters by replacing the Control Character with the four characters "\nnn", where "nnn" is the three digit octal representation of each byte.
Considerations for missing fonts
The Unicode standard and the [GB 18030] standard define mechanisms for print and display of characters that are missing from the available fonts. If GBK is specified in Specific Character Set (0008,0005), the [GB 18030] rules of print and display of characters shall apply. The DICOM Standard does not specify user interface behavior since it does not affect network or media data exchange.
The Unicode and [GB 18030] standards have distinct YEN SIGN, BACKSLASH, and several forms of reverse solidus. The separator for multi-valued Data Elements in DICOM is the character valued 05/12 regardless of what glyph is used to enter or display this character. The other reverse solidus characters that have a very similar appearance are not separators. The choice of font can affect the appearance of 05/12 significantly. Multi-byte encoding systems, such as [GB 18030], [GBK] and [ISO/IEC 2022], may generate encodings that contain a byte valued 05/12. Only the character that encodes as a single byte valued 05/12 is a delimiter.
For multi-valued Data Elements, existing implementations that are expecting only single-byte replacement character sets may misinterpret the Value Multiplicity of the Data Element as a consequence of interpreting 05/12 bytes in multi-byte characters or [ISO/IEC 2022] escape sequences as delimiters, and this may affect the integrity of store-and-forward operations. Applications that do not explicitly state support for [GB 18030], [GBK] or [ISO/IEC 2022] in their conformance statement, might exhibit such behavior.
For Data Elements with Value Representations of SH (Short String), LO (Long String), UC (Unlimited Characters), ST (Short Text), LT (Long Text), UT (Unlimited Text) or PN (Person Name), the Default Character Repertoire or the character repertoire specified by Value 1 of Attribute Specific Character Set (0008,0005), may be extended using the Code Extension techniques specified by ISO/IEC 2022:1994.
If such Code Extension techniques are used, the related Specific Character Set or Sets shall be specified by Value 2 to Value n of Specific Character Set (0008,0005) of the SOP Common Module (see PS3.3), and shall be stated in the Conformance Statement.
Defined Terms for Specific Character Set (0008,0005) are defined in PS3.3.
Support for Japanese kanji (ideographic), hiragana (phonetic), katakana (phonetic), Korean (Hangul phonetic and Hanja ideographic) and Chinese characters is defined in PS3.3.
The Chinese Character Set (GB18030) and Unicode [ISO/IEC 10646] do not allow the use of Code Extension Techniques. If either of these character sets is used, no other character set may be specified in the Specific Character Set (0008,0005) Attribute, that is, it may have only one Value.
DICOM supports Code Extension techniques if Specific Character Set (0008,0005) is multi-valued. The method employed for Code Extension in DICOM is as described in ISO/IEC 2022:1994. The following assumptions shall be made and the following restrictions shall apply:
Code element G0 and code element G1 (in 8-bit mode only) are always invoked in the GL and GR areas of the code table respectively. Designated character sets for these code elements are immediately in use. Code elements G2 and G3 are not used.
The primary set of Control Characters shall always be designated as the C0 code element and this shall be invoked in the CL area of the code table. The C1 code element shall not be used.
As code elements G0 and G1 always have shift status, Locking Shifts (SI, SO) are not required and shall not be used.
As code elements G2 and G3 are not used, Single Shifts (SS2 and SS3) cannot be used.
Only the ESC sequences specified in PS3.3 shall be used to activate Code Elements.
The character set specified by Value 1 of Specific Character Set (0008,0005), or the Default Character Repertoire if Value 1 is missing, shall be active at the beginning of each textual Data Element Value, and at the beginning of each line (i.e., after a CR and/or LF) or page (i.e., after an FF).
If within a textual Value a character set other than the one specified in Value 1 of Specific Character Set (0008,0005), or the Default Character Repertoire if Value 1 is missing, has been invoked, the character set specified in the Value 1, or the Default Character Repertoire if Value 1 is missing, shall be active in the following instances:
before any other Control Character other than ESC (e.g., before any TAB)
before the end of a Data Element Value (e.g., before the 05/12 character code that separates multiple textual Data Element Values - 05/12 corresponds to "\" (BACKSLASH) in the case of default repertoire IR-6 or "¥" (YEN SIGN) in the case of IR-14).
before the "^" and "=" delimiters separating name components and name component groups in Data Elements with a VR of PN.
If within a textual Value a character set other than the one specified in Value 1 of Specific Character Set (0008,0005), or the Default Character Repertoire if Value 1 is missing, is used, the Escape Sequence of this character set must be inserted explicitly in the following instances:
These requirements allow an application to skip lines, values, or components in a textual Data Element and start the new line with a defined character set without the need to track the character set changes in the text skipped. A similar restriction appears in the RFCs describing the use of multi-byte character sets over the Internet. An Escape Sequence switching to the Value 1 or default Specific Character Set is not needed within a line, value, or component if no Code Extensions are present. Nor is a switch needed to the Value 1 or default Specific Character Set if this character set has only the G0 Code Element defined, and the G0 Code Element is still active.
Attribute Specific Character Set (0008,0005) not present:
Implementation level: [ISO/IEC 2022] Level 1 - Elementary 7-bit code (code-level identifier 1)
Attribute Specific Character Set (0008,0005) single Value other than "ISO_IR 192", "GB18030" or "GBK":
Implementation level: [ISO/IEC 2022] Level 1 - Elementary 8-bit code (code-level identifier 11)
Initial designation: One of the [ISO/IEC 8859] defined character sets, the 8-bit code table [TIS 620-2533], or the 8-bit code table of [JIS X 0201] specified by Value 1 of Specific Character Set (0008,0005), as G0 and G1.
Attribute Specific Character Set (0008,0005) multi-valued:
Implementation level: [ISO/IEC 2022] Level 4 - Redesignation of Graphic Character Sets within a Code (code-level identifier 14)
Initial designation: One of the [ISO/IEC 8859] defined character sets, the 8-bit code table [TIS 620-2533], or the 8-bit code table of [JIS X 0201] specified by Value 1 of Specific Character Set (0008,0005), as G0 and G1. If Value 1 of Specific Character Set (0008,0005) is empty, ISO-IR 6 (ASCII) is assumed as G0, and G1 is undefined.
All character sets specified in the various Values of Attribute Specific Character Set (0008,0005), including Value 1, may participate in Code Extension.
Attribute Specific Character Set (0008,0005) single Value "ISO_IR 192", "GB18030" or "GBK":
Implementation level: not specified (not compatible with [ISO/IEC 2022])
Initial designation: as specified by Value 1 of Specific Character Set (0008,0005)
Textual data that is interchanged may require some formatting information. Control Characters are used to indicate formatting, but their use in DICOM is kept to a minimum since some machines may handle them inappropriately. [ISO 646] and ISO 6429:1990 define Control Characters. As shown in Table 6.1-1 below, only a subset of five Control Characters from the C0 set shall be used in DICOM for the encoding of Control Characters in text strings.
The ESC character shall be used only for [ISO/IEC 2022] character set control sequences, in accordance with Section 6.1.2.5.
In text strings (Value Representation ST, LT, or UT) a new line shall be represented as CR LF.
Some machines (such as UNIX based machines) may interpret LF (00/10) as a new line. In such cases, it is expected that the DICOM format is converted to the correct internal representation for that machine.
In previous editions of the Standard (see PS3.5 2015a), the TAB character was not listed as a Control Character.
The Value Representation of a Data Element describes the data type and format of that Data Element's Value(s). PS3.6 lists the VR of each Data Element by Data Element Tag.
Values with VRs constructed of character strings, except in the case of the VR UI, shall be padded with SPACE characters (20H, in the Default Character Repertoire) when necessary to achieve even length. Values with a VR of UI shall be padded with a single trailing NULL (00H) character when necessary to achieve even length. Values with a VR of OB shall be padded with a single trailing NULL byte value (00H) when necessary to achieve even length.
All new VRs defined in future versions of DICOM shall be of the same Data Element Structure as defined in Section 7.1.2 with reserved bytes after the VR and a 32-bit unsigned integer VL (i.e., following the format for VRs such as OB or UT), and may or may not permit Undefined Length.
Since all new VRs will be defined as specified in Section 7.1.2, an implementation may choose to ignore VRs not recognized by applying the rules stated in Section 7.1.2.
When converting a Data Set from an Explicit VR Transfer Syntax to a different Transfer Syntax, an implementation may copy Data Elements with unrecognized VRs in the following manner:
If the endianness of the Transfer Syntaxes is the same, the Value of the Data Element may be copied unchanged and if the target Transfer Syntax is Explicit VR, the VR bytes copied unchanged. In practice this only applies to Little Endian Transfer Syntaxes, since there was only one Big Endian Transfer Syntax defined.
If the source Transfer Syntax is Little Endian and the target Transfer Syntax is the (retired) Big Endian Explicit VR Transfer Syntax, then the Value of the Data Element may be copied unchanged and the VR changed to UN, since being unrecognized, whether or not byte swapping is required is unknown. If the VR were copied unchanged, the byte order of the Value might or might not be incorrect.
If the source Transfer Syntax is the (retired) Big Endian Explicit VR Transfer Syntax, then the Data Element cannot be copied, because whether or not byte swapping is required is unknown, and there is no equivalent of the UN VR to use when the Value is big endian rather than little endian.
The issues of whether or not the Data Element may be copied, and what VR to use if copying, do not arise when converting a Data Set from Implicit VR Little Endian Transfer Syntax, since the VR would not be present to be unrecognized, and if the Data Element VR is not known from a data dictionary, then UN would be used.
An individual Value, including padding, shall not exceed the Length of Value, except in the case of the last Value of a multi-valued field as specified in Section 6.4.
The lengths of Value Representations for which the Character Repertoire can be extended or replaced are expressly specified in characters rather than bytes in Table 6.2-1. This is because the mapping from a character to the number of bytes used for that character's encoding may be dependent on the character set used.
Escape Sequences used for Code Extension shall not be included in the count of characters.
Table 6.2-1. DICOM Value Representations
A string of characters that identifies an Application Entity with leading and trailing spaces (20H) being non-significant. A Value consisting solely of spaces shall not be used. |
Default Character Repertoire excluding character code 5CH (the BACKSLASH "\" in ISO-IR 6), and all control characters. |
||
A string of characters with one of the following formats -- nnnD, nnnW, nnnM, nnnY; where nnn shall contain the number of days for D, weeks for W, months for M, or years for Y. |
|||
Ordered pair of 16-bit unsigned integers that is the Value of a Data Element Tag. Example: A Data Element Tag of (0018,00FF) would be encoded as a series of 4 bytes in a Little-Endian Transfer Syntax as 18H,00H,FFH,00H. NoteThe encoding of an AT Value is exactly the same as the encoding of a Data Element Tag as defined in Section 7. |
|||
A string of characters identifying a controlled concept. Leading or trailing spaces (20H) are not significant. Alternatively, in the context of a Query with Empty Value Matching (see PS3.4), a string of two QUOTATION MARK characters, representing an empty key Value. |
Uppercase characters, "0"-"9", the SPACE character, and underscore "_", of the Default Character Repertoire In the context of a Query with Empty Value Matching (see PS3.4), the QUOTATION MARK character is allowed. |
In the context of a Query with Empty Value Matching (see PS3.4), the length is 2 bytes fixed. |
|
A string of characters of the format YYYYMMDD; where YYYY shall contain year, MM shall contain the month, and DD shall contain the day, interpreted as a date of the Gregorian calendar system. Note
Alternatively, in the context of a Query with Empty Value Matching (see PS3.4), a string of two QUOTATION MARK characters, representing an empty key Value. |
"0"-"9" of Default Character Repertoire In the context of a Query with Range Matching (see PS3.4), the character "-" is allowed, and a trailing SPACE character is allowed for padding. In the context of a Query with Empty Value Matching (see PS3.4), the QUOTATION MARK character is allowed. |
In the context of a Query with Range Matching (see PS3.4), the length is 18 bytes maximum. In the context of a Query with Empty Value Matching (see PS3.4), the length is 2 bytes fixed. |
|
A string of characters representing either a fixed point number or a floating point number. A fixed point number shall contain only the characters 0-9 with an optional leading "+" or "-" and an optional "." to mark the decimal point. A floating point number shall be conveyed as defined in ANSI X3.9, with an "E" or "e" to indicate the start of the exponent. Decimal Strings may be padded with leading or trailing spaces. Embedded spaces are not allowed. |
"0"-"9", "+", "-", "E", "e", "." and the SPACE character of Default Character Repertoire |
||
A concatenated date-time character string in the format: The components of this string, from left to right, are YYYY = Year, MM = Month, DD = Day, HH = Hour (range "00" - "23"), MM = Minute (range "00" - "59"), SS = Second (range "00" - "60"). FFFFFF = Fractional Second contains a fractional part of a second as small as 1 millionth of a second (range "000000" - "999999"). &ZZXX is an optional suffix for offset from Coordinated Universal Time (UTC), where & = "+" or "-", and ZZ = Hours and XX = Minutes of offset. The year, month, and day shall be interpreted as a date of the Gregorian calendar system. A 24-hour clock is used. Midnight shall be represented by only "0000" since "2400" would violate the hour range. The Fractional Second component, if present, shall contain 1 to 6 digits. If Fractional Second is unspecified the preceding "." shall not be included. The offset suffix, if present, shall contain 4 digits. The string may be padded with trailing SPACE characters. Leading and embedded spaces are not allowed. A component that is omitted from the string is termed a null component. Trailing null components of Date Time indicate that the Value is not precise to the precision of those components. The YYYY component shall not be null. Non-trailing null components are prohibited. The optional suffix is not considered as a component. A Date Time Value without the optional suffix is interpreted to be in the local time zone of the application creating the Data Element, unless explicitly specified by the Timezone Offset From UTC (0008,0201). UTC offsets are calculated as "local time minus UTC". The offset for a Date Time Value in UTC shall be +0000. Alternatively, in the context of a Query with Empty Value Matching (see PS3.4), a string of two QUOTATION MARK characters, representing an empty key Value. Note
|
"0"-"9", "+", "-", "." and the SPACE character of Default Character Repertoire In the context of a Query with Empty Value Matching (see PS3.4), the QUOTATION MARK character is allowed. |
In the context of a Query with Range Matching (see PS3.4), the length is 54 bytes maximum. In the context of a Query with Empty Value Matching (see PS3.4), the length is 2 bytes fixed. |
|
Single precision binary floating point value represented in [IEEE 754] binary32 format. All [IEEE 754] values are permitted, including NaN (Not a Number) and infinity values. |
|||
Double precision binary floating point value represented in [IEEE 754] binary64 format. All [IEEE 754] values are permitted, including NaN (Not a Number) and infinity values. |
|||
A string of characters representing an Integer in base-10 (decimal), shall contain only the characters 0 - 9, with an optional leading "+" or "-". It may be padded with leading and/or trailing spaces. Embedded spaces are not allowed. |
"0"-"9", "+", "-" and the SPACE character of Default Character Repertoire |
||
A character string that may be padded with leading and/or trailing spaces. The character code 5CH (the BACKSLASH "\" in ISO-IR 6) shall not be present, as it is used as the delimiter between Values in multi-valued Data Elements. The string shall not have Control Characters except for ESC. |
Default Character Repertoire and/or as defined by (0008,0005) excluding character code 5CH (the BACKSLASH "\" in ISO-IR 6), and all Control Characters except ESC when used for [ISO/IEC 2022] escape sequences. |
64 chars maximum (see Note in Section 6.2) |
|
A character string that may contain one or more paragraphs. It may contain the Graphic Character set and the Control Characters, CR, LF, FF, and ESC. It may be padded with trailing spaces, which may be ignored, but leading spaces are considered to be significant. Data Elements with this VR shall not be multi-valued and therefore character code 5CH (the BACKSLASH "\" in ISO-IR 6) may be used. |
Default Character Repertoire and/or as defined by (0008,0005) excluding Control Characters except TAB, LF, FF, CR (and ESC when used for [ISO/IEC 2022] escape sequences). |
10240 chars maximum (see Note in Section 6.2) |
|
An octet-stream where the encoding of the contents is specified by the negotiated Transfer Syntax. OB is a VR that is insensitive to byte ordering (see Section 7.3). The octet-stream shall be padded with a single trailing NULL byte value (00H) when necessary to achieve even length. |
|||
A stream of [IEEE 754] binary64 values. All [IEEE 754] values are permitted, including NaN (Not a Number) and infinity values. OD is a VR that requires byte swapping within each 64-bit word when changing byte ordering (see Section 7.3). |
|||
A stream of [IEEE 754] binary32 values. All [IEEE 754] values are permitted, including NaN (Not a Number) and infinity values. OF is a VR that requires byte swapping within each 32-bit word when changing byte ordering (see Section 7.3). |
|||
A stream of 32-bit words where the encoding of the contents is specified by the negotiated Transfer Syntax. OL is a VR that requires byte swapping within each word when changing byte ordering (see Section 7.3). |
|||
A stream of 64-bit words where the encoding of the contents is specified by the negotiated Transfer Syntax. OV is a VR that requires byte swapping within each word when changing byte ordering (see Section 7.3). |
|||
A stream of 16-bit words where the encoding of the contents is specified by the negotiated Transfer Syntax. OW is a VR that requires byte swapping within each word when changing byte ordering (see Section 7.3). |
|||
A character string encoded using a 5 component convention. The character code 5CH (the BACKSLASH "\" in ISO-IR 6) shall not be present, as it is used as the delimiter between Values in multi-valued Data Elements. The string may be padded with trailing spaces. For human use, the five components in their order of occurrence are: family name complex, given name complex, middle name, name prefix, name suffix. NoteHL7 prohibits leading spaces within a component; DICOM allows leading and trailing spaces and considers them insignificant. Any of the five components may be an empty string. The component delimiter shall be the caret "^" character (5EH). There shall be no more than four component delimiters, i.e., none after the last component if all components are present. Delimiters are required for interior null components. Trailing null components and their delimiters may be omitted. Multiple entries are permitted in each component and are encoded as natural text strings, in the format preferred by the named person. For veterinary use, the first two of the five components in their order of occurrence are: responsible party family name or responsible organization name, patient name. The remaining components are not used and shall not be present. This group of five components is referred to as a Person Name component group. For the purpose of writing names in ideographic characters and in phonetic characters, up to 3 groups of components (see Annex H, Annex I and Annex J) may be used. The delimiter for component groups shall be the equals character "=" (3DH). There shall be no more than two component group delimiters, i.e., none after the last component group if all component groups are present. The three component groups of components in their order of occurrence are: an alphabetic representation, an ideographic representation, and a phonetic representation. Any component group may be absent, including the first component group. In this case, the person name may start with one or more "=" delimiters. Delimiters are required for interior null component groups. Trailing null component groups and their delimiters may be omitted. Precise semantics are defined for each component group. See Section 6.2.1.2. For examples and notes, see Section 6.2.1.1. |
Default Character Repertoire and/or as defined by (0008,0005) excluding character code 5CH (the BACKSLASH "\" in ISO-IR 6) and all Control Characters except ESC when used for [ISO/IEC 2022] escape sequences. |
64 chars maximum per component group (see Note in Section 6.2) |
|
A character string that may be padded with leading and/or trailing spaces. The character code 05CH (the BACKSLASH "\" in ISO-IR 6) shall not be present, as it is used as the delimiter between Values for multi-valued Data Elements. The string shall not have Control Characters except ESC. |
Default Character Repertoire and/or as defined by (0008,0005) excluding character code 5CH (the BACKSLASH "\" in ISO-IR 6) and all Control Characters except ESC when used for [ISO/IEC 2022] escape sequences. |
16 chars maximum (see Note in Section 6.2) |
|
Signed binary integer 32 bits long in 2's complement form. |
|||
Value is a Sequence of zero or more Items, as defined in Section 7.5. |
not applicable (see Section 7.5) |
not applicable (see Section 7.5) |
|
Signed binary integer 16 bits long in 2's complement form. Represents an integer n in the range: |
|||
A character string that may contain one or more paragraphs. It may contain the Graphic Character set and the Control Characters, CR, LF, FF, and ESC. It may be padded with trailing spaces, which may be ignored, but leading spaces are considered to be significant. Data Elements with this VR shall not be multi-valued and therefore character code 5CH (the BACKSLASH "\" in ISO-IR 6) may be used. |
Default Character Repertoire and/or as defined by (0008,0005) excluding Control Characters except TAB, LF, FF, CR (and ESC when used for [ISO/IEC 2022] escape sequences). |
1024 chars maximum (see Note in Section 6.2) |
|
Signed binary integer 64 bits long. Represents an integer n in the range: |
|||
A string of characters of the format HHMMSS.FFFFFF; where HH contains hours (range "00" - "23"), MM contains minutes (range "00" - "59"), SS contains seconds (range "00" - "60"), and FFFFFF contains a fractional part of a second as small as 1 millionth of a second (range "000000" - "999999"). A 24-hour clock is used. Midnight shall be represented by only "0000" since "2400" would violate the hour range. The string may be padded with trailing spaces. Leading and embedded spaces are not allowed. One or more of the components MM, SS, or FFFFFF may be unspecified as long as every component to the right of an unspecified component is also unspecified, which indicates that the Value is not precise to the precision of those unspecified components. The FFFFFF component, if present, shall contain 1 to 6 digits. If FFFFFF is unspecified the preceding "." shall not be included. NoteAlternatively, in the context of a Query with Empty Value Matching (see PS3.4), a string of two QUOTATION MARK characters, representing an empty key Value. |
"0"-"9", "." and the SPACE character of Default Character Repertoire In the context of a Query with Range Matching (see PS3.4), the character "-" is allowed. In the context of a Query with Empty Value Matching (see PS3.4), the QUOTATION MARK character is allowed. |
In the context of a Query with Range Matching (see PS3.4), the length is 28 bytes maximum. In the context of a Query with Empty Value Matching (see PS3.4), the length is 2 bytes fixed. |
|
A character string that may be of unlimited length that may be padded with trailing spaces. The character code 5CH (the BACKSLASH "\" in ISO-IR 6) shall not be present, as it is used as the delimiter between Values in multi-valued Data Elements. The string shall not have Control Characters except for ESC. |
Default Character Repertoire and/or as defined by (0008,0005) excluding character code 5CH (the BACKSLASH "\" in ISO-IR 6), and all Control Characters except ESC when used for [ISO/IEC 2022] escape sequences. |
See Note 2 |
|
A character string containing a UID that is used to uniquely identify a wide variety of items. The UID is a series of numeric components separated by the period "." character. If a Value Field containing one or more UIDs is an odd number of bytes in length, the Value Field shall be padded with a single trailing NULL (00H) character to ensure that the Value Field is an even number of bytes in length. See Section 9 and Annex B for a complete specification and examples. |
|||
Unsigned binary integer 32 bits long. Represents an integer n in the range: |
|||
An octet-stream where the encoding of the contents is unknown (see Section 6.2.2). |
Any length valid for any of the other DICOM Value Representations |
||
Universal Resource Identifier or Universal Resource Locator (URI/URL) |
A string of characters that identifies a URI or a URL as defined in [RFC3986]. Leading spaces are not allowed. Trailing spaces shall be ignored. Data Elements with this VR shall not be multi-valued. Alternatively, in the context of a Query with Empty Value Matching (see PS3.4), a string of two QUOTATION MARK characters, representing an empty key Value. |
The subset of the Default Character Repertoire required for the URI as defined in IETF RFC3986 Section 2, plus the space (20H) character permitted only as trailing padding. Characters outside the permitted character set must be "percent encoded". In the context of a Query with Empty Value Matching (see PS3.4), the QUOTATION MARK character is allowed. |
See Note 2. In the context of a Query with Empty Value Matching (see PS3.4), the length is 2 bytes fixed. |
Unsigned binary integer 16 bits long. Represents integer n in the range: |
|||
A character string that may contain one or more paragraphs. It may contain the Graphic Character set and the Control Characters, CR, LF, FF, and ESC. It may be padded with trailing spaces, which may be ignored, but leading spaces are considered to be significant. Data Elements with this VR shall not be multi-valued and therefore character code 5CH (the BACKSLASH "\" in ISO-IR 6) may be used. |
Default Character Repertoire and/or as defined by (0008,0005) excluding Control Characters except TAB, LF, FF, CR (and ESC when used for [ISO/IEC 2022] escape sequences). |
See Note 2 |
|
Unsigned binary integer 64 bits long. Represents an integer n in the range: |
For Data Elements that were present in ACR-NEMA 1.0 and 2.0 and that have been retired, the specifications of Value Representation and Value Multiplicity provided are recommendations for the purpose of interpreting their Values in objects created in accordance with earlier versions of this Standard. These recommendations are suggested as most appropriate for a particular Data Element; however, there is no guarantee that historical objects will not violate some requirements or specified VR and/or VM.
The length of the Value of UC, UR and UT VRs is limited only by the size of the maximum unsigned integer representable in a 32 bit VL field minus two, since FFFFFFFFH is reserved and lengths are required to be even.
In previous editions of the Standard (see PS3.5 2015a), the TAB character was not listed as permitted for the ST, LT and UT VRs. It has been added for the convenience of formatting and the encoding of XML text.
Rev. John Robert Quincy Adams, B.A. M.Div.
"Adams^John Robert Quincy^^Rev.^B.A. M.Div."
[One family name; three given names; no middle name; one prefix; two suffixes.]
Susan Morrison-Jones, Ph.D., Chief Executive Officer
"Morrison-Jones^Susan^^^Ph.D., Chief Executive Officer"
[Two family names; one given name; no middle name; no prefix; two suffixes.]
[One family name; one given name; no middle name, prefix, or suffix. Delimiters have been omitted for the three trailing null components.]
(for examples of the encoding of Person Names using multi-byte character sets see Annex H)
[A cat, rather than a human, whose responsible party family name is Smith, and whose own name is Fluffy]
[A horse whose responsible organization is named ABC Farms, and whose name is "Running On Water"]
A similar multiple component convention is also used by the HL7 v2 XPN data type. However, the XPN data type places the suffix component before the prefix, and has a sixth component "degree" that DICOM subsumes in the name suffix. There are also differences in the manner in which name representation is identified.
In typical American and European usage the first occurrence of "given name" would represent the "first name". The second and subsequent occurrences of the "given name" would typically be treated as a middle name(s). The "middle name" component is retained for the purpose of backward compatibility with existing standards.
The implementer should remain mindful of earlier usage forms that represented "given names" as "first" and "middle" and that translations to and from this previous typical usage may be required.
For reasons of backward compatibility with older versions of this Standard, person names might be considered a single family name complex (single component without "^" delimiters).
Character strings representing person names are encoded using a convention for PN Value Representation based on component groups with 5 components.
For the purpose of writing names in ideographic characters and in phonetic characters, up to 3 component groups may be used. The delimiter of the component group shall be the equals character "=" (3DH). The three component groups in their order of occurrence are: an alphabetic representation, an ideographic representation, and a phonetic representation.
Any component group may be absent, including the first component group. In this case, the person name may start with one or more "=" delimiters. Delimiters are also required for interior null component groups. Trailing null component groups and their delimiters may be omitted.
The first component group (identified by DICOM as "alphabetic") shall be encoded using the character set specified by Specific Character Set (0008,0005), Value 1. If Attribute Specific Character Set (0008,0005) is not present, the Default Character Repertoire ISO-IR 6 shall be used. [ISO/IEC 2022] escapes for Code Extension shall not be used in this component group. When Specific Character Set (0008,0005) Value 1 specifies a multi-byte character set without Code Extension (i.e., Unicode in UTF-8, [GB 18030] or [GBK]), the characters of this component group may be encoded with multiple bytes, but shall be drawn from the code points U+0020 through U+1FFF of [ISO/IEC 10646], or the following [ISO/IEC 10646] code points:
The second group shall be used for ideographic characters. The character sets used will usually be those from Attribute Specific Character Set (0008,0005), Value 2 through n, and may use [ISO/IEC 2022] escapes.
The third group shall be used for phonetic characters. The character sets used shall be those from Attribute Specific Character Set (0008,0005), Value 1 through n, and may use [ISO/IEC 2022] escapes.
Delimiter characters "^" and "=" are taken from the character set specified by Value 1 of Specific Character Set (0008,0005). If Attribute Specific Character Set (0008,0005), Value 1 is not present, the Default Character Repertoire ISO-IR 6 shall be used.
At the beginning of the Value of the Person Name Data Element, the following initial condition is assumed: if Attribute Specific Character Set (0008,0005), Value 1 is not present, the Default Character Repertoire ISO-IR 6 is invoked, and if Specific Character Set (0008,0005), Value 1 is present, the character set specified by Value 1 of the Attribute is invoked.
At the end of the Value of the Person Name Data Element, and before the component delimiters "^" and "=", the character set shall be switched to the Default Character Repertoire ISO-IR 6, if Value 1 of Specific Character Set (0008,0005) is not present. If Value 1 of Specific Character Set (0008,0005) is present, the character set shall be switched to that specified by Value 1 of the Attribute.
The Value Length of each component group is 64 characters maximum, including the delimiter for the component group. Each combining character (e.g., diacritics or vowel marks) shall be considered a separate character for this maximum length, regardless of how an application may display such combining characters (i.e., combined into the glyph for the base character, or rendered separately).
The Unknown (UN) VR shall only be used for Private Data Elements and Standard Data Elements previously encoded as some DICOM VR other than UN using Implicit VR encoding, and whose Value Representation is currently unknown, or whose known Value Representation is one of those that have a 16-bit Value Length Field (see Section 7.1.2) when using Explicit VR encoding and whose Value Length exceeds 65534 (216-2). As long as the VR is unknown the Value Field is insensitive to byte ordering and shall not be 'byte-swapped' (see Section 7.3). In the case of Undefined Length Sequences, the Value shall remain in Implicit VR form. See Section 7.8 for a description of Private Data Attribute Elements and Section 10 and Annex A for a discussion of Transfer Syntaxes.
The UN VR shall not be used for Private Creator Data Elements (i.e., the VR is equal to LO, see Section 7.8.1).
The UN VR shall not be used for File Meta Information Data Elements (any Tag (0002,xxxx), see PS3.10).
All other (non-default) DICOM Transfer Syntaxes employ Explicit VR in their encoding, and therefore any Private and/or Standard Data Element Value Field encoded and decoded using any Transfer Syntax other than the DICOM Default Little Endian Transfer Syntax, and not having been translated to the DICOM Default Little Endian Transfer Syntax in the interim, will have a known VR.
If at some point an application knows the actual VR for a Data Element of VR UN (e.g., has its own applicable data dictionary), it can assume that the Value Field of the Data Element is encoded in Little Endian byte ordering with Implicit VR encoding, irrespective of the current Transfer Syntax.
This VR of UN is needed when an Explicit VR must be given to a Data Element whose Value Representation is unknown (e.g., store and forward).
This VR of UN is also needed for the encoding of Data Elements with Explicit VR whose Value Length exceeds 65534 (216-2) (FFFEH, the largest even length unsigned 16 bit number) but which are defined to have a 16 bit Explicit VR Value Length Field.
The Value Length Field of VR UN may contain Undefined Length (FFFFFFFFH), in which case the contents can be assumed to be encoded with Implicit VR. See Section 7.5.1 to determine how to parse Data Elements with an Undefined Length.
An example of a Standard Data Element using a UN VR is a Type 3 or Type U Standard Attribute added to an SOP Class definition. An existing application that does not support that new Attribute (and encounters it) could convert the VR to UN.
The URI/URL (UR) VR uses a subset of the Default Character Repertoire as defined in [RFC3986], and shall not use any code extension or replacement techniques. URI/URL domain name components that in their original form use characters outside the permitted character set shall use the Internationalized Domain Names for Applications encoding in accordance with IETF RFC5890 and RFC5891. Other URI/URL content that uses characters outside the permitted character set shall use the Internationalized Resource Identifiers encoding mechanism of IETF RFC 3987, representing the content string in UTF-8 and percent encoding characters as required.
For example, the use of a patient name in a URI/URL string may require use of the [RFC3987] technique.
The Value of certain Data Elements may be chosen among a set of explicit Values satisfying its VR. These explicit Values are either Enumerated Values or Defined Terms and are specified in PS3.3 and PS3.4.
Enumerated Values are used when the specified explicit Values are the only Values allowed for a Data Element. A Data Element with Enumerated Values that does not have a Value equivalent to one of the Values specified in this Standard has an invalid Value within the scope of a specific Information Object/SOP Class definition.
Patient Sex (0010, 0040) is an example of a Data Element having Enumerated Values. It is defined to have a Value that is either "M", "F", or "O" (see PS3.3). No other Value shall be given to this Data Element.
Future modifications of this Standard may add to the set of allowed Values for Data Elements with Enumerated Values. Such additions by themselves may or may not require a change in SOP Class UIDs, depending on the semantics of the Data Element.
Defined Terms are used when the specified explicit Values may be extended by implementers to include additional new Values. These new Values shall be specified in the Conformance Statement (see PS3.2) and shall not have the same meaning as currently defined Values in this Standard. A Data Element with Defined Terms that does not contain a Value equivalent to one of the Values currently specified in this Standard shall not be considered to have an invalid Value. An empty (zero length) Value is not a valid new Value for a Defined Term; empty Values shall be considered invalid unless the Standard specifically permits empty Values. New Values shall not have a meaning of unknown, since that concept, if permitted by the Standard, shall be conveyed explicitly either by allowing the Data Element to be zero length or by provision of a standard Defined Term with such a meaning.
Reporting Priority (0040,1009) is an example of a Data Element having Defined Terms. It is defined to have a Value that may be one of the set of standard Values; HIGH, ROUTINE, MEDIUM, or LOW (see PS3.3). Because this Data Element has Defined Terms other reporting priorities may be defined by the implementer.
The validity of empty Values is usually specified by the Attribute being defined as Type 2 (see Section 7.4.3). However, in the context of a required Type 1 Attribute with multiple Values, some (but not all) Values may be allowed to be empty (see Section 7.4.1); in this case the Standard explicitly specifies the validity of empty Values in the list of Defined Terms for each Value. Specific Character Set (0008,0005) is an example of a Data Element for which the Standard specifically permits the first Value to be empty when multiple Values are present. Image Type (0008,0008) is an example of a Data Element that in some IODs defined in PS3.3 is required to be present with multiple Values, but if an empty Value is not explicitly listed in the Defined Terms for Value 3 by an IOD an empty Value is invalid.
The Value Representation may affect the interpretation of Defined Terms and Enumerated Values for numeric Values. For binary Value Representations, the textual representation of the Value in the Standard does not affect the interpretation. For string Value Representations (IS and DS), the meaning of the Value in the Standard shall be used, not the literal string.
For example, an Enumerated Value of "1" expressed in the text of the Standard matches an IS or DS Value encoded as "001", or a DS Value encoded as "1.0" or "1." or "1.0000E+00" or any permitted encoding. Leading and trailing spaces are defined in Table 6.2-1 not to be significant and hence do not affect the interpretation.
The Value Multiplicity of a Data Element specifies the number of Values that can be encoded in the Value Field of that Data Element. The VM of each Data Element is specified explicitly in PS3.6. If the number of Values that may be encoded in a Data Element is variable, it shall be represented by two numbers separated by a dash; e.g., "1-10" means that there may be 1 to 10 Values in the Data Element.
Elements having a multiplicity of "S", which represented "single", in older versions of this Standard, will have a multiplicity of "1" in this version of this Standard.
When a Data Element has multiple Values, those Values shall be delimited as follows:
Each string Value in a multi-valued character string may be of even or odd length, but the length of the entire Value Field (including "\" delimiters) shall be of even length. If padding is required to make the Value Field of even length, a single padding character shall be applied to the end of the Value Field (to the last Value), in which case the length of the last Value may exceed the length of Value by 1.
A padding character may need to be appended to a fixed length character string Value in the above case.
Only the last UID Value in a multi-valued Data Element with a VR of UI shall be padded with a single trailing NULL (00H) character when necessary to ensure that the entire Value Field (including "\" delimiters) is of even length.
Data Elements with a VR of LT, OB, OD, OF, OL, OV, OW, SQ, ST, UN, UR or UT shall always have a Value Multiplicity of one. See Table 6.2-1.
A Data Set represents an instance of a real world Information Object. A Data Set is constructed of Data Elements. Data Elements contain the encoded Values of Attributes of that object. The specific content and semantics of these Attributes are specified in Information Object Definitions (see PS3.3).
The construction, characteristics, and encoding of a Data Set and its Data Elements are discussed in this section. Pixel Data and Overlays are Data Elements whose interpretation depends on other related Data Elements.
A Data Element is uniquely identified by a Data Element Tag. The Data Elements in a Data Set shall be ordered by increasing Data Element Tag Number and shall occur at most once in a Data Set.
A Data Element Tag may occur again within Nested Data Sets (see Section 7.5).
Two types of Data Elements are defined:
Standard Data Elements have an even Group Number that is not 0000, 0002, 0004, or 0006.
Usage of these groups is reserved for DIMSE Commands (see PS3.7) and DICOM File Formats.
Private Data Elements have an odd Group Number that is not 0001, 0003, 0005, 0007, or FFFF. Private Data Elements are discussed further in Section 7.8.
Although similar or related Data Elements often have the same Group Number; a Data Group does not convey any semantic meaning.
A Data Element shall have one of three structures. Two of these structures contain the VR of the Data Element (Explicit VR) but differ in the way their lengths are expressed, while the other structure does not contain the VR (Implicit VR). All three structures contain the Data Element Tag, Value Length and Value for the Data Element. See Figure 7.1-1.
Implicit and Explicit VR Data Elements shall not coexist in a Data Set and Data Sets nested within it (see Section 7.5). Whether a Data Set uses Explicit or Implicit VR, among other characteristics, is determined by the negotiated Transfer Syntax (see Section 10 and Annex A).
VRs are not contained in Data Elements when using DICOM Default Little Endian Transfer Syntax (Implicit VR Little Endian).
A Data Element is made up of fields. Three fields are common to all three Data Element structures; these are the Data Element Tag, Value Length, and Value Field. A fourth field, Value Representation, is only present in the two Explicit VR Data Element structures. The Data Element structures are defined in Section 7.1.2 and Section 7.1.3. The definitions of the fields are:
An ordered pair of 16-bit unsigned integers representing the Group Number followed by Element Number.
Two single byte characters containing the VR of the Data Element. The VR for a given Data Element Tag shall be as defined by the Data Dictionary as specified in PS3.6. The two byte VR shall be encoded using only upper case letters from the DICOM default character set.
a 16 or 32-bit (dependent on VR and whether VR is explicit or implicit) unsigned integer containing the Explicit Length of the Value Field as the number of bytes (even) that make up the Value. It does not include the length of the Data Element Tag, Value Representation, and Value Length Fields.
a 32-bit Value Length Field set to Undefined Length (FFFFFFFFH). Undefined Lengths may be used for Data Elements having the Value Representation (VR) Sequence of Items (SQ) and Unknown (UN). For Data Elements with Value Representation OW or OB Undefined Length may be used depending on the negotiated Transfer Syntax (see Section 10 and Annex A).
The decoder of a Data Set should support both Explicit and Undefined Lengths for VRs of SQ and UN and, when applicable, for VRs of OW and OB.
The 32-bit Value Length Field limits the maximum size of large data Value Fields such as Pixel Data sent in a Native Format (encoded in Transfer Syntaxes that use only the unencapsulated form).
An even number of bytes containing the Value(s) of the Data Element.
The data type of Value(s) stored in this field is specified by the Data Element's VR. The VR for a given Data Element Tag can be determined using the Data Dictionary in PS3.6, or using the VR Field if it is contained explicitly within the Data Element. The VR of Standard Data Elements shall agree with those specified in the Data Dictionary.
The Value Multiplicity specifies how many Values with this VR can be placed in the Value Field. If the VM is greater than one, multiple Values shall be delimited within the Value Field as defined previously in Section 6.4. The VMs of Standard Data Elements are specified in the Data Dictionary in PS3.6.
Value Fields with Undefined Length are delimited through the use of Sequence Delimitation Items and Item Delimitation Data Elements, which are described further in Section 7.5.
When using the Explicit VR structures, the Data Element shall be constructed of four consecutive fields: Data Element Tag, VR, Value Length, and Value. Depending on the VR of the Data Element, the Data Element will be structured in one of two ways:
for VRs of AE, AS, AT, CS, DA, DS, DT, FL, FD, IS, LO, LT, PN, SH, SL, SS, ST, TM, UI, UL and US the Value Length Field is the 16-bit unsigned integer following the two byte VR Field (Table 7.1-2). The value of the Value Length Field shall equal the length of the Value Field.
for all other VRs the 16 bits following the two byte VR Field are reserved for use by later versions of the DICOM Standard. These reserved bytes shall be set to 0000H and shall not be used or decoded (Table 7.1-1). The Value Length Field is a 32-bit unsigned integer.
for VRs of OB, OD, OF, OL, OV, OW, SQ and UN, if the Value Field has an Explicit Length, then the Value Length Field shall contain a value equal to the length (in bytes) of the Value Field, otherwise, the Value Field has an Undefined Length and a Sequence Delimitation Item marks the end of the Value Field.
for all other VRs with a 32-bit Value Length Field, the Value Length Field shall contain a value equal to the length (in bytes) of the Value Field.
Table 7.1-1. Data Element with Explicit VR other than as shown in Table 7.1-2
Table 7.1-2. Data Element with Explicit VR of AE, AS, AT, CS, DA, DS, DT, FL, FD, IS, LO, LT, PN, SH, SL, SS, ST, TM, UI, UL and US
When using the Implicit VR structure the Data Element shall be constructed of three consecutive fields: Data Element Tag, Value Length, and Value (see Table 7.1-3). If the Value Field has an Explicit Length then the Value Length Field shall contain a value equal to the length (in bytes) of the Value Field. Otherwise, the Value Field has an Undefined Length and a Sequence Delimitation Item marks the end of the Value Field.
Table 7.1-3. Data Element with Implicit VR
Even number of bytes containing the Data Elements Value encoded according to the VR specified in PS3.6 and the negotiated Transfer Syntax. Delimited with Sequence Delimitation Item if of Undefined Length. |
|||
Group Length (gggg,0000) Data Elements were implicitly defined for Standard and Private Data Element groups with a Value Representation of UL and a Value Multiplicity of 1, but have been retired. See PS3.5-2007.
All implementations shall be able to parse Group Length Data Elements, and may discard and not insert or re-insert them; if present they shall be consistent with the encoding of the Data Set even if the Transfer Syntax is changed resulting in a change in the actual length of a group of Data Elements. No implementation shall require the presence of Group Length Data Elements.
Elements in groups 0, 2, 4 and 6 are not Standard Data Elements. Mandatory requirements for Group Length for groups 0 and 2 are specified elsewhere in the Standard.
It is recommended that Group Length Data Elements be removed during storage or transfer in order to avoid the risk of inconsistencies arising during coercion of Data Element Values and changes in Transfer Syntax.
All nonretired Transfer Syntaxes in DICOM require the use of Little Endian Byte Ordering.
Little Endian byte ordering is defined as follows:
In a binary number consisting of multiple bytes (e.g., a 32-bit unsigned integer value, the Group Number, the Element Number, etc.), the least significant byte shall be encoded first; with the remaining bytes encoded in increasing order of significance.
In a character string consisting of multiple 8-bit single byte codes, the characters will be encoded in the order of occurrence in the string (left to right).
Big Endian byte ordering was previously described but has been retired, See PS3.5 2016b.
The packing of bits within Values of OB or OW Value Representation for Pixel Data and Overlay Data is described in Section 8. The OL and OV Value Representations are not used for Pixel Data or Overlay Data.
Byte ordering is a component of an agreed upon Transfer Syntax (see Section 10). The default DICOM Transfer Syntax, which shall be supported by all AEs, uses Little Endian encoding and is specified in Section A.1. Alternate Little Endian Transfer Syntaxes are also specified in Annex A.
The Command Set structure as specified in PS3.7 is encoded using the Little Endian Implicit VR Transfer Syntax.
In the case of Little Endian encoding, Big Endian Machines interpreting Data Sets shall do 'byte swapping' before interpreting or operating on certain Data Elements. The Data Elements affected are all those having VRs that are multiple byte Values and that are not a character string of 8-bit single byte codes. VRs constructed of a string of characters of 8-bit single byte codes are really constructed of a string of individual bytes, and are therefore not affected by byte ordering. The VRs that are not a string of characters and consist of multiple bytes are:
An Attribute, encoded as a Data Element, may or may not be required in a Data Set, depending on that Attribute's Data Element Type.
The Data Element Type of an Attribute of an Information Object Definition or an Attribute of a SOP Class Definition is used to specify whether that Attribute is mandatory or optional. The Data Element Type also indicates if an Attribute is conditional (only mandatory under certain conditions). The Data Element Types of Attributes of Composite IODs are specified in PS3.3. The Data Element Types of Attributes of Normalized IODs are specified as Attributes of SOP Classes in PS3.4.
IODs and SOP Classes define Type 1 Data Elements that shall be included and are mandatory Data Elements. The Value Field shall contain valid data as defined by the Data Element's VR and VM as specified in PS3.6. The Length of the Value Field shall not be zero. Absence of a valid Value in a Type 1 Data Element is a protocol violation.
For Data Elements with a string (CS, SH, LO) rather than binary, text or sequence Value Representation, and for which multiple Values are allowed, the presence of a single Value is sufficient to satisfy the Type 1 requirement, unless specified otherwise in the Attribute description, and other Values may be empty, unless otherwise specified by the IOD. The presence of one or more delimiter (BACKSLASH) characters alone, without any Values, is not sufficient to satisfy the Type 1 requirement, since even though the Value Length is greater than zero, there is no valid Value present.
A Type 1 Sequence Data Element will contain one or more Items, as defined by the IOD (irrespective of the VM of the Sequence, which is always one (Section 7.5)). Whether or not those Items may be empty (contain no Data Elements) depends on the IOD definition of the Data Set for each Item.
IODs and SOP Classes define Data Elements that shall be included under certain specified conditions. Type 1C Data Elements have the same requirements as Type 1 Data Elements under these conditions. It is a protocol violation if the specified conditions are met and the Data Element is not included.
When the specified conditions are not met, Type 1C Data Elements shall not be included in the Data Set unless it is specified that they may be present otherwise.
IODs and SOP Classes define Type 2 Data Elements that shall be included and are mandatory Data Elements. However, it is permissible that if a Value for a Type 2 Data Element is unknown it can be encoded with zero Value Length and no Value. If the Value is known the Value Field shall contain that Value as defined by the Data Element's VR and VM as specified in PS3.6. These Data Elements shall be included in the Data Set and their absence is a protocol violation.
The intent of Type 2 Data Elements is to allow a zero length to be conveyed when the operator or application does not know its Value or has a specific reason for not specifying its Value. It is the intent that the device should support these Data Elements.
A Type 2 Sequence Data Element will contain zero or more Items, as defined by the IOD (irrespective of the VM of the Sequence, which is always one (Section 7.5)). An empty Type 2 Sequence is one with no Items, as opposed to an Item that is present but empty. Whether or not Items may be empty (contain no Data Elements) depends on the IOD definition of the Data Set for each Item, rather than the Type of the enclosing Sequence Data Element.
IODs and SOP Classes define Type 2C Data Elements that have the same requirements as Type 2 Data Elements under certain specified conditions. It is a protocol violation if the specified conditions are met and the Data Element is not included.
When the specified conditions are not met, Type 2C Data Elements shall not be included in the Data Set unless it is specified that they may be present otherwise.
An example of a Type 2C Data Element is Inversion Time (0018,0082). For several SOP Class Definitions, this Data Element is required only if the Scanning Sequence (0018,0020) has the Value "IR." It is not required otherwise. See PS3.3.
IODs and SOP Classes define Type 3 Data Elements that are optional Data Elements. Absence of a Type 3 Data Element from a Data Set does not convey any significance and is not a protocol violation. Type 3 Data Elements may also be encoded with zero length and no Value. The meaning of a zero length Type 3 Data Element shall be precisely the same as that Data Element being absent from the Data Set.
When an IOD defines a Sequence Data Element (see Section 7.5), the Type of the Sequence Attribute defines whether the Sequence Attribute itself must be present, and the Attribute Description of the Sequence Attribute may define whether and how many Items shall be present in the Sequence. The Types of the Attributes of the Data Set included in the Sequence, including any conditionality, are specified within the scope of each Data Set, i.e., for each Item present in the Sequence.
The Type and Attribute Description of the Sequence determines whether Items are present; conditionality constraints on Data Elements of the Items cannot force an Item to be present.
Historically, many IODs declared Type 1 and Type 2 Data Elements of the Sequence to be Type 1C and Type 2C, respectively, with the condition that an Item is present. This is exactly the same as simply defining them as Type 1 and Type 2.
In particular, the conditionality constraint "Required if Sequence is sent" on the Type 1C or Type 2C Data Elements subsidiary to a Type 2 or 3 Sequence Attribute does not imply that an Item must be present in the Sequence. These conditions are meant to be equivalent to "Required if a Sequence Item is present", and the conditionality is not strictly necessary. Any Type 2 or Type 3 Sequence Attribute may be sent with zero length.
In particular, the conditionality constraint "Required if <name-of-parent-sequence-attribute> is sent" on the Type 1C or Type 2C Data Elements subsidiary to a Type 2 or 3 Sequence Attribute does not imply that an Item must be present in the Sequence. These conditions are meant to be equivalent to "Required if a Sequence Item is present", and the conditionality is not strictly necessary. Any Type 2 or Type 3 Sequence Attribute may be sent with zero length.
The VR identified "SQ" shall be used for Data Elements with a Value consisting of a Sequence of zero or more Items, where each Item contains a set of Data Elements. SQ provides a flexible encoding scheme that may be used for simple structures of repeating sets of Data Elements, or the encoding of more complex Information Object Definitions often called folders. SQ Data Elements can also be used recursively to contain multi-level nested structures.
Items present in an SQ Data Element shall be an ordered set where each Item may be referenced by its ordinal position. Each Item shall be implicitly assigned an ordinal position starting with the Value 1 for the first Item in the Sequence, and incremented by 1 with each subsequent Item. The last Item in the Sequence shall have an ordinal position equal to the number of Items in the Sequence.
This clause implies that item ordering is preserved during transfer and storage.
An IOD or Module Definition may choose to not use this ordering property of a Data Element with VR of SQ. This is simply done by not specifying any specific semantics to the ordering of Items, or by not specifying usage of the referencing of Items by ordering position.
The definition of the Data Elements encapsulated in each Item is provided by the specification of the Data Element (or associated Attribute) of Value Representation SQ. Items in a sequence of Items may or may not contain the same set of Data Elements. Data Elements with a VR of SQ may contain multiple Items but shall always have a Value Multiplicity of one (i.e., a single Sequence).
There are three special SQ related Data Elements that are not ruled by the VR encoding rules conveyed by the Transfer Syntax. They shall be encoded as Implicit VR. These special Data Elements are Item (FFFE,E000), Item Delimitation Item (FFFE,E00D), and Sequence Delimitation Item (FFFE,E0DD). However, the Data Set within the Value Field of the Data Element Item (FFFE,E000) shall be encoded according to the rules conveyed by the Transfer Syntax.
Each Item of a Data Element of Value Representation SQ shall be encoded as a DICOM Standard Data Element with a specific Data Element Tag of Value (FFFE,E000). The Item Tag is followed by a 4 byte Value (Item) Length field encoded in one of the following two ways:
Explicit Length: The number of bytes (even) contained in the Sequence Item Value (following but not including the Value (Item) Length Field) is encoded as a 32-bit unsigned integer value (see Section 7.1). This length shall include the total length of all Data Elements conveyed by this Item. This Value (Item) Length Field shall be equal to 00000000H if the Item contains no Data Set.
Undefined Length: The Value (Item) Length Field shall contain the value FFFFFFFFH to indicate an Undefined Length. It shall be used in conjunction with an Item Delimitation Data Element. This Item Delimitation Data Element has a Data Element Tag of (FFFE,E00D) and shall follow the Data Elements encapsulated in the Item. No Value shall be present in the Item Delimitation Data Element and its Value (Item) Length shall be 00000000H. An Item containing no Data Set is encoded by an Item Delimitation Data Element only.
The encoder of a Data Set may choose either one of the two ways of encoding. Both ways of encoding shall be supported by decoders of Data Sets. Data Element Tags (FFFF,eeee) are reserved by this Standard and shall not be used.
Each Item Value shall contain a DICOM Data Set composed of Data Elements. Within the context of each Item, these Data Elements shall be ordered by increasing Data Element Tag value and appear only once (as Data Set is defined in Section 7.1). There is no relationship between the ordering of the Data Elements contained within an Item and the ordering of the Data Element Tag of SQ Value Representation that contains that Item. One or more Data Elements in an Item may be of Value Representation SQ, thus allowing for recursion.
Data Elements with a group of 0000, 0002 and 0006 shall not be present within Sequence Items.
The use of Transfer Syntax UID (0002,0010) in particular is forbidden, since were it to differ from the Transfer Syntax of the enclosing Data Set then a change in encoding would be implied, which is not allowed.
Section 7.8 specifies rules for incorporating Private Data Elements into Sequence Items.
Delimitation of the last Item of a Sequence of Items, encapsulated in a Data Element of Value Representation SQ, shall be in one of the two following ways:
Explicit Length: The number of bytes (even) contained in the Data Element Value (following but not including the Value (Sequence) Length Field) is encoded as a 32-bit unsigned integer value (see Section 7.1). This length shall include the total length resulting from the sequence of zero or more items conveyed by this Data Element. This Data Element Length shall be equal to 00000000H if the sequence of Items contains zero Items.
Undefined Length: The Value (Sequence) Length Field shall contain a Value FFFFFFFFH to indicate a Sequence of Undefined Length. It shall be used in conjunction with a Sequence Delimitation Item. A Sequence Delimitation Item shall be included after the last Item in the sequence. Its Item Tag shall be (FFFE,E0DD) with a Value (Item) Length Field of 00000000H. No Value shall be present. A Sequence containing zero Items is encoded by a Sequence Delimitation Item only.
The encoder of a Sequence of Items may choose either one of the two ways of encoding. Both ways of encoding shall be supported by decoders of the Sequence of Items.
The Sequence Delimitation Item Tag (FFFE,E0DD) is different from the Item Delimitation Tag (FFFE,E00D) introduced above in that it indicates the end of a Sequence of Items whose Length was left undefined. If an Undefined Length Item is the last Item of a Sequence of Items of Undefined Length, then an Item Delimitation Tag will be followed by a Sequence Delimitation Tag.
For an example of an SQ Data Element of Explicit Length encapsulating Items of Explicit Length see Table 7.5-1.
For an example of an SQ Data Element of Undefined Length encapsulating Items of Explicit Length see Table 7.5-2.
For an example of an SQ Data Element of Undefined Length encapsulating Items of both Explicit and Undefined Length see Table 7.5-3.
Table 7.5-1. Example of a Data Element with Implicit VR Defined as a Sequence of Items (VR = SQ) with Three Items of Explicit Length
Table 7.5-2. Example of a Data Element with Explicit VR Defined as a Sequence of Items (VR = SQ) of Undefined Length, Containing Two Items of Explicit Length
The Data Set within the Item Values in Table 7.5-2 have VRs Explicitly defined.
Table 7.5-3. Example of a Data Element with Implicit VR Defined as a Sequence of Items (VR = SQ) of Undefined Length, Containing Two Items Where One Item is of Explicit Length and the Other Item is of Undefined Length
An encapsulated Data Set shall only include the Specific Character Set (0008,0005) Data Element if the Specific Character Set (0008,0005) is defined in the IOD for that Sequence of Items.
An encapsulated Data Set does not include the Specific Character Set (0008,0005) Data Element unless the Specific Character Set (0008,0005) is defined as part of the IOD for that Sequence.
If an encapsulated Data Set includes Specific Character Set (0008,0005), it shall apply only to the encapsulated Data Set. If Specific Character Set (0008,0005) is not explicitly included in an encapsulated Data Set, then the Specific Character Set (0008,0005) Value of the encapsulating Data Set applies.
Multiple Overlay Planes can be associated with a single Image (see PS3.3). Standard Data Elements with even Group Numbers 6000-601E represent Overlay Planes. This range of Group numbers is known as a Repeating Group. This use of Group Numbers is a remnant of older versions of this Standard, which associated a semantic meaning with particular Groups.
In this range of Group Numbers, Standard Data Elements that have identical Element Numbers have the same meaning within each Group (and the same VR, VM, and Data Element Type). The notation 60xx is used for the Group Number in Data Element Tags when referring to a common Data Element across these Groups (see PS3.6). Groups 60xx are called Repeating Groups because of these characteristics.
Repeating Groups shall only be allowed in the even numbered Groups 6000-601E. In the future, Data Elements with VRs of SQ shall be used to serve a similar purpose.
Encoding of Curves in the even Group Numbers 50xx was previously defined but has been retired. See PS3.5-2004
Private Groups in the odd Group Numbers 6001-601F may still be used, but there is no implication of repeating semantics, nor any implied shadowing of the standard Repeating Groups.
Certain Data Elements are no longer supported in the current Standard. These Data Elements are retired and are denoted as such (RET) in the VR column in PS3.6. Implementations may continue to support these Data Elements for the purpose of backward compatibility with older versions of this Standard, but this is not a requirement of the current Standard. If a retired Data Element is used it must contain valid data as specified in older versions of this Standard. Any other use of a retired Data Element, and its associated Data Element Tag, is reserved by this Standard. Retired Data Element Tags shall not be redefined in later versions of this Standard.
Implementations may require communication of information that cannot be contained in Standard Data Elements. Private Data Elements are intended to be used to contain such information. Such Private Data Elements shall not change the semantics of the Information Object Definition or SOP Class Definition.
Private Data Elements have the same structure as Standard Data Elements specified earlier in Section 7.1 (i.e., Data Element Tag Field, optional VR Field, Value Length Field, and Value Field). The Group Number used in the Element Tag of Private Data Elements shall be an odd number. Private Data Elements shall be contained in the Data Set in increasing numeric order of Data Element Tag. The Value Field of a Private Data Element shall have one of the VRs specified by this Standard in Section 6.2.
For each Information Object Definition or SOP Class Definition, certain Data Elements are required (Data Element Type 1, 1C, 2, or 2C) as specified in PS3.3 and PS3.4. Private Data Elements shall not be used in place of required Standard Data Elements.
It is possible that multiple implementers may define Private Elements with the same (odd) group number. To avoid conflicts, Private Elements shall be assigned Private Data Element Tags according to the following rules.
Private Creator Data Elements numbered (gggg,0010-00FF) (gggg is odd) shall be used to reserve a block of Elements with Group Number gggg for use by an individual implementer. The implementer shall insert an identification code in an unused (unassigned) Element in this series to reserve a block of Private Elements. The VR of the private identification code shall be LO (Long String) and the VM shall be equal to 1. A Private Creator identifier may be used only once within a Group; reserving multiple blocks of Elements in the same Group with the same identifier is not allowed. The Private Creator Data Elements shall only contain characters from the Default Character Repertoire and not an Extended or Replacement Character Repertoire, even though the LO VR is one that is affected by the Specific Character Set (0008,0005).
If an implementer needs repetitions of a Private Data Element, a private Sequence Data Element (see Section 7.5) may be used to contain each of the repeated Private Data Elements in separate items. Each item needs to claim the corresponding private block of Elements, as described below.
An implementer may use the same Private Creator identifier for multiple Groups.
The first Private Creator Data Element does not have to be (gggg,0010), nor do they have to be sequentially assigned. In particular, if a block of Private Data Elements is entirely removed along with its Private Creator Data Element, such as during de-identification, the other private blocks do not need to be renumbered.
A Private Creator Data Element may be present even though no corresponding Private Data Elements are used. In particular, if a block of Private Data Elements is entirely removed, such as during de-identification, the corresponding Private Creator Data Element does not need to be removed, though it may be.
Even though the Private Creator Data Element can only contain characters from the Default Character Repertoire, regardless of the actual Value(s) of Specific Character Set (0008,0005), it is suggested that only the range of values in the Default Character Set that represent Graphic Characters be used, and that certain values be avoided, so that reliable recognition is more likely. Specifically, in [JIS X 0201], not only does the byte value for the delimiter between values (05/12) represent a different character (YEN SIGN (‘¥’) versus BACKSLASH (‘\`)), but so too does 07/14 (OVERLINE (‘‾’) versus TILDE (‘~’)), so both 05/12 and 07/14 should be avoided.
Private Creator Data Element (gggg,0010) is required in order to identify Data Elements (gggg,1000-10FF) if present, Private Creator Data Element (gggg,0011) is required in order to identify Data Elements (gggg,1100-11FF) if present, through Private Creator Data Element (gggg,00FF), which identifies Data Elements (gggg,FF00-FFFF) if present.
Encoders of Private Data Elements shall be able to dynamically assign private data to any available (unreserved) block(s) within the Private group, and specify this assignment through the blocks corresponding Private Creator Data Element(s). Decoders of Private Data shall be able to accept reserved blocks with a given Private Creator identification code at any position within the Private group specified by the blocks corresponding Private Creator Data Element.
Older versions of this Standard described shadow groups. These were groups with a group number one greater than the standard groups. Elimination of conflicts in Private Data Element Tags have made this distinction obsolete and this terminology has been retired.
Older versions of this Standard specified private group Data Element numbers (gggg,10FF-7FFF) reserved for manufacturers and private group Data Element numbers (gggg, 8100-FFFF) reserved for users. Elimination of conflicts in Private Data Element Tags has made this distinction obsolete and this specification has been retired.
The requirements of this section do not allow any use of Data Elements in the ranges (gggg,0001-000F) and (gggg,0100-0FFF) where gggg is odd.
Elements with Tags (0001,xxxx), (0003,xxxx), (0005,xxxx), (0007,xxxx) and (FFFF,xxxx) shall not be used.
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.
Data Elements numbered (gggg,0000), where gggg is odd, were Group Length Elements, which have been retired, See Section 7.2.
Items within a sequence are self contained Data Sets (see Section 7.5 on the nesting of Data Sets via Sequences of Items), any Item in the sequence that contains Private Data Elements shall also have Private Creator Data Element reserving a block 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.
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.
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.
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 Element value, e.g., Private Creator Data Element (0029,00xx) = "Acme_CT_Parameters", and (0029,xx43), (0029,xx44), etc.
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. A Private Data Element with SQ VR (a Private Data Sequence) may include Items with both Standard and Private Data Elements. 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.
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 Data 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 Section 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 [IEEE 754] may be used, including NaN, Positive Infinity and Negative Infinity. See Table 6.2-1
Floating point binary32 and binary64 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.
Encoded Pixel Data of various bit depths shall be accommodated. The following three Data Elements shall define the Pixel structure:
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).
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.
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.
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.
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.
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), such that only a single Pixel Cell entirely occupies the allocated bits specified by Bits Allocated (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.
The 32-bit Value Length Field limits the maximum size of large data Value Fields such as Pixel Data sent in a Native Format (encoded in Transfer Syntaxes that use only the unencapsulated form).
In a Multi-frame Image that is transmitted in Native Format, the individual Frames are not padded. The individual Frames shall be concatenated and padding bits (if necessary) applied to the complete Value Field. At least one frame shall be present.
Receiving applications should be aware that some older applications may send Pixel Data with excess padding, which was not explicitly prohibited in earlier versions of the Standard. Applications should be prepared to accept such Pixel Data Data Elements, but may delete the excess padding. In no case should a sending application place private data in the padding data.
In a Multi-frame Image with a Bits Allocated (0028,0100) of 1 that is transmitted in Native Format, the individual Frames are not padded, therefore successive bits are packed into bytes or words as described in 8.2. I.e., a frame other than the first frame may start in the middle of a byte or word. This is consistent with the historical encoding of Multi-frame Overlays described in 8.1.
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 complement 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).
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:
There is no Data Element analogous to Bits Stored (0028,0101) since Overlay Planes always have a bit depth of 1.
Restrictions on the allowed Values for these Data Elements are defined in PS3.3. Formerly overlay data stored in unused bits of Pixel Data (7FE0,0010) was described, and these Attributes had meaningful Values but this usage has been retired. 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).
The DICOM Default Little Endian Transfer Syntax (Implicit VR Little Endian) does not explicitly convey Value Representation and therefore the VR of OB may not be used for Overlay 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. For a Multi-frame Overlay, the individual Frames are not padded. The individual Frames shall be concatenated and padding bits (if necessary) applied to the complete Value Field. 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 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).
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).
If Pixel Data (7FE0,0010) is sent in a Native Format, then the Photometric Interpretation (0028,0004) shall be other than:
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.
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).
The DICOM Default Little Endian 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.
The 32-bit Value Length Field limits the maximum size of large data Value Fields 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.
It is not permitted to have more than one of Pixel Data Provider URL (0028,7FE0), Pixel Data (7FE0,0010), Float Pixel Data (7FE0,0008) or Double Float Pixel Data (7FE0,0009) in the top level Data Set.
Pixel Data encoded in Float Pixel Data (7FE0,0008) or Double Float Pixel Data (7FE0,0009) can be considered as consisting 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. 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 significant 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).
For Pixel Data (7FE0,0010) encoded with the Value Representation OB, the Pixel Data (7FE0,0010) encoding is unaffected by byte ordering.
If encoding Pixel Data (7FE0,0010) with a Value for Bits Allocated (0028,0100) not equal to 16 be sure to read and understand Annex D.
If sent in an Encapsulated Format (i.e., other than the Native Format) the Value Representation OB is used. The Pixel Cells are encoded according to the encoding process defined by one of the negotiated Transfer Syntaxes (see Annex A).
Each Fragment conveys its own explicit even length (see Section A.4).
The Sequence of Fragments of the encapsulated stream is terminated by a Sequence Delimiter Item, thus allowing the support of encoding processes where the resulting length of the entire stream is not known until it is entirely encoded. Encapsulated Formats support 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.
Depending on the Fragmentable Encapsulated Transfer Syntax, a frame may be entirely contained within a single Fragment, or may span multiple Fragments 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 fragmentation of Frames, but an implementation that fails to support such fragmentation does not conform to the Standard.
The total size of the encapsulated stream, not including any trailing padding in the last Fragment, if known, may be encoded in Encapsulated Pixel Data Value Total Length (7FE0,0003); see PS3.3 Section C.7.6.6 “Multi-frame Module” and PS3.3 Section C.7.6.16 “Multi-frame Functional Groups Module”.
DICOM provides a mechanism for supporting the use of JPEG Image Compression through the Encapsulated Format. 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.
The context where the usage of lossy 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 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:
Any implementation that conforms to the DICOM Standard and has elected to support any one of the Transfer Syntaxes for Lossless JPEG Image Compression, shall support the following lossless compression: The subset (first-order horizontal prediction [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.
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).
The use of the DICOM Encapsulated Format to support JPEG 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 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.
If APP2 marker segments with an identifier of "ICC_PROFILE" (as defined in Annex B of [ISO 15076-1]) are present in the compressed data stream, their concatenated value shall be identical to the Value of ICC Profile (0028,2000) Attribute, if present, excluding padding.
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.
When decompressing, should the characteristics explicitly specified in the compressed data stream (e.g., spatial subsampling 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.
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 Data Set. For example a Photometric Interpretation of "YBR_FULL_422" would describe the color space that is commonly used to lossy compress images using JPEG. It is unusual to use an RGB color space for lossy compression, since no advantage is taken of correlation between the red, green and blue components (e.g., of luminance), and poor compression 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.
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 "abbreviated format" in which these tables are not sent (and the decoder is assumed to already have them). The JPEG Interchange 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.
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 compression process. However, for certain characteristics described in DICOM Data Elements but not explicitly described 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).
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 Data Element however as the value for JPEG compressed data is already known).
If JPEG 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 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.
DICOM provides a mechanism for supporting the use of Run Length Encoding (RLE) Image Compression, which is a byte oriented lossless compression scheme through the encapsulated Format (see PS3.3 of this Standard). Annex G defines RLE Image Compression and its Transfer Syntax.
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 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 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.
Table 8.2.2-1. Valid Values of Pixel Data Related Attributes for RLE Compression using Standard Photometric Interpretations
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 implementations, this requirement is now specified in terms of consistency with what is encapsulated.
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 Interpretation 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, green and blue components (e.g., of luminance), and poor compression is achieved (note however that the conversion 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).
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.
If RLE 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 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 decompressed in the Native format, in which case the Photometric Interpretation in the Data Set with the Native encoding would be YBR_FULL.
A Bits Allocated (0028,0100) of 1 for monochrome images supports compression of Segmentation IOD Pixel Data with a Segmentation Type (0062,0001) of BINARY.
DICOM provides a mechanism for supporting the use of JPEG-LS Image Compression through the Encapsulated Format. Annex A defines a number of Transfer Syntaxes that reference the JPEG-LS Standard and provide a number of lossless (bit preserving) and lossy (near-lossless) compression schemes.
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.
Table 8.2.3-1. Valid Values of Pixel Data Related Attributes for JPEG-LS Compression using Standard Photometric Interpretations
See also the notes in Section 8.2.1.
No color transformation Photometric Interpretation specific for JPEG-LS is currently defined in DICOM. Annex F of ISO 14495-2 describes a "Sample transformation for inverse colour transform" and a marker segment to encode its parameters, 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 Photometric Interpretation and component conversion could theoretically be used, in the absence of DC shifting it results in signed values to be encoded, which are not supported by JPEG-LS.
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 Interpretation will be changed to RGB in the Data Set with the Native encoding.
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.
DICOM provides a mechanism for supporting the use of JPEG 2000 Image Compression through the Encapsulated Format. Annex A defines a number of Transfer Syntaxes that reference the JPEG 2000 Standard and provide lossless (bit preserving) and lossy compression schemes.
The context where the usage of lossy 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 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 compressed data stream. The Pixel Data characteristics included in the JPEG 2000 bit stream 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.4-1. No other Standard Photometric Interpretation Values shall be used.
Table 8.2.4-1. Valid Values of Pixel Data Related Attributes for JPEG 2000 Transfer Syntaxes using Standard Photometric Interpretations
These requirements are specified in terms of consistency with what is encapsulated, rather than in terms of the uncompressed Pixel Data from which the compressed data stream may have been derived.
When decompressing, should the characteristics explicitly specified in the compressed data stream 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.
The JPEG 2000 bit stream specifies whether or not a reversible or irreversible multi-component (color) transformation [ISO 15444-1 Annex G], if any, has been applied. If no multi-component transformation has been applied, then the components shall correspond to those specified by the DICOM Attribute Photometric Interpretation (0028,0004). If the JPEG 2000 Part 1 reversible multi-component transformation has been applied then the DICOM Attribute Photometric Interpretation (0028,0004) shall be YBR_RCT. If the JPEG 2000 Part 1 irreversible multi-component transformation has been applied then the DICOM Attribute Photometric Interpretation (0028,0004) shall be YBR_ICT.
For example, single component may be present, and the Photometric Interpretation (0028,0004) may be MONOCHROME2.
The application of a JPEG 2000 Part 1 reversible multi-component transformation is signaled in the JPEG 2000 bit stream by a value of 1 rather than 0 in the SGcod Multiple component transformation type of the COD marker segment [ISO 15444-1 Table A.17]. No other Value of Photometric Interpretation than YBR_RCT or YBR_ICT is permitted when SGcod Multiple component transformation type is 1.
Though it would be unusual, would not take advantage of correlation between the red, green and blue components, and would not achieve effective compression, a Photometric Interpretation of RGB could be specified as long as no multi-component transformation [ISO 15444-1 Annex G] was specified by the JPEG 2000 bit stream. For some applications the use of RGB is permitted, e.g., Whole Slide Microscopy Images, to allow conversion to DICOM from proprietary formats without loss due to color space transformation. Alternative methods of decorrelation of the color components than those specified in [ISO 15444-1 Annex G] are permitted as defined in PS3.3, such as a Photometric Interpretation of YBR_FULL; this may be useful when converting existing YBR_FULL Pixel Data (e.g., in a different Transfer Syntax) without further loss.
In either case (Photometric Interpretation of RGB or YBR_FULL), the value of SGcod Multiple component transformation type would be 0.
PS3.3 may constrain the Values of Photometric Interpretation for specific IODs.
Despite the application of a multi-component color transformation and its reflection in the Photometric Interpretation Attribute, the "color space" remains undefined. There is currently no means of conveying "standard color spaces" either by fixed values (such as sRGB) or by ICC profiles. Note in particular that the JP2 file header is not sent in the JPEG 2000 bit stream that is encapsulated in DICOM.
If JPEG 2000 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 YBR_ICT or YBR_RCT to RGB during decompression and Native re-encoding, the Photometric Interpretation will be changed to RGB in the Data Set with the Native encoding.
The upper limit of 40 on Bits Allocated (0028,0100) and 38 on Bits Stored (0028,0101) reflects the maximum JPEG 2000 sample precision of 38 and the DICOM requirement to describe Bits Allocated (0028,0100) as multiples of bytes (octets).
A Bits Allocated (0028,0100) of 1 for monochrome images supports compression of Segmentation IOD Pixel Data with a Segmentation Type (0062,0001) of BINARY.
The JPEG 2000 bit stream is capable of encoding both signed and unsigned pixel values, hence the Value of Pixel Representation (0028,0103) may be either 0 or 1 for monochrome Photometric Interpretations depending on what has been encoded (as specified in the SIZ marker segment in the precision and sign of component parameter).
The Value of Planar Configuration (0028,0006) is irrelevant since the manner of encoding components is specified in the JPEG 2000 standard, hence it shall be set to 0.
DICOM provides a mechanism for supporting the use of MPEG2 Main Profile / Main Level Video Compression through the Encapsulated Format. Annex A defines Non-Fragmentable and Fragmentable Encapsulated Transfer Syntaxes that reference the MPEG2 Main Profile / Main Level Standard.
MPEG2 compression is inherently lossy. The context where the usage of lossy 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 MPEG2 Main Profile / Main Level are also beyond the scope of this Standard.
The use of the DICOM Encapsulated Format to support MPEG2 Main Profile / Main Level 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, with some specific exceptions noted here. The Pixel Data characteristics included in the MPEG2 Main Profile / Main Level bit stream shall be used to decode the compressed data stream.
These requirements are specified in terms of consistency with what is encapsulated, rather than in terms of the uncompressed Pixel Data from which the compressed data stream may have been derived.
When decompressing, should the characteristics explicitly specified in the compressed data stream 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.
The MPEG2 Main Profile / Main Level bit stream specifies whether or not a reversible or irreversible multi-component (color) transformation, if any, has been applied. If no multi-component transformation has been applied, then the components shall correspond to those specified by the DICOM Attribute Photometric Interpretation (0028,0004). MPEG2 Main Profile / Main Level applies an irreversible multi-component transformation, so DICOM Attribute Photometric Interpretation (0028,0004) shall be YBR_PARTIAL_420 in the case of multi-component data, and MONOCHROME2 in the case of single component data (even though the MPEG2 bit stream itself is always encoded as three components, one luminance and two chrominance).
If MPEG2 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 YBR_PARTIAL_420 to RGB during decompression and Native re-encoding, the Photometric Interpretation will be changed to RGB in the Data Set with the Native encoding.
MPEG2 proposes some video formats. Each of the standards specified is used in a different market, including: ITU-R BT.470-2 System M for SD NTSC and ITU-R BT.470-2 System B/G for SD PAL/SECAM. A PAL based system should therefore be based on ITU-BT.470 System B for each of Color Primaries, Transfer Characteristic (gamma) and matrix coefficients and should take a value of 5 as defined in [ISO/IEC 13818-2].
The Value of Planar Configuration (0028,0006) is irrelevant since the manner of encoding components is specified in the MPEG2 Main Profile / Main Level standard, hence it shall be set to 0.
Photometric Interpretation (0028,0004) shall be YBR_PARTIAL_420
Rows (0028,0010), Columns (0028,0011), Cine Rate (0018,0040) and Frame Time (0018,1063) or Frame Time Vector (0018,1065) shall be consistent with the limitations of Main Profile / Main Level, as specified in Table 8-1.
Although different combinations of Values for Rows and Columns are possible while respecting the maximum values listed above, it is recommended that the typical 4:3 ratio of image width to height be maintained in order to avoid image deformation by MPEG2 decoders. A common way to maintain the ratio of width to height is to pad the image with black areas on either side.
"Half" definition of pictures (240x352 and 288x352 for NTSC and PAL, respectively) are always supported by decoders.
Main Profile / Main Level allows for various different display and pixel aspect ratios, including the use of square pixels, and the use of non-square pixels with display aspect ratios of 4:3 and 16:9. DICOM specifies no additional restrictions beyond what is provided for in Main Profile / Main Level. All permutations allowed by Main Profile / Main Level are valid and are require to be supported by all DICOM decoders.
The actual frame rate for NTSC MPEG2 is approximately 29.97 frames/sec.
The nominal Frame Time is supplied for the purpose of inclusion on the DICOM Cine Module Attributes, and should be calculated from the actual frame rate.
For the Non-Fragmentable Encapsulated Transfer Syntax, one Fragment shall contain the whole MPEG2 stream.
For the Fragmentable Encapsulated Transfer Syntax, the stream may be segmented into multiple Fragments.
If a video stream exceeds the maximum length of one Fragment (2^32-2 bytes), it may be sent using a Fragmentable Encapsulated Transfer Syntax. Alternatively, it may be sent using a Non-Fragmentable Encapsulated Transfer Syntax as multiple SOP Instances, but each SOP Instance will contain an independent and playable bit stream, and not depend on the encoded bit stream in other (previous) instances. The manner in which such separate instances are related is not specified in the Standard, but mechanisms such as grouping into the same Series, and references to earlier instances using Referenced Image Sequence may be used.
Fragmentable Encapsulated Transfer Syntaxes allow for streams of essentially unlimited length; the only limit imposed is the maximum Number of Frames (0028,0008), which is 2^31-1 Frames (largest positive Value in an Integer String VR).
The Basic Offset Table shall be empty (present but zero length).
The Basic Offset Table is not used because MPEG2 contains its own mechanism for describing navigation of Frames. To enable decoding of only a part of the sequence, MPEG2 manages a header in any group of pictures (GOP) containing a time_code - a 25-bit integer containing the following: drop_frame_flag, time_code_hours, time_code_minutes, marker_bit, time_code_seconds and time_code_pictures.
The container format for the video bit stream is not constrained. For example, it may MPEG-2 Transport Stream (MPEG-TS), MPEG-2 Program Stream (MPEG-PS), MPEG-2 Elementary Stream (MPEG-ES), MPEG-2 Packetized Elementary Stream (MPEG-PES) (see [ISO/IEC 13818-1]) or MPEG-4 (MP4) container (see [ISO/IEC 14496-12] and [ISO/IEC 14496-14]).
Any audio components present within the MPEG bit stream shall comply with the following restrictions:
MPEG-1 Layer III is standardized in Part 3 of the MPEG-1 standard (see [ISO/IEC 11172-3]).
Although MPEG describes each channel as including up to 5 signals (e.g., for surround effects), it is recommended to limit each of the two channels to 2 signals each one (stereo).
MPEG2 Main Profile / High Level corresponds to what is commonly known as HDTV ('High Definition Television'). DICOM provides a mechanism for supporting the use of MPEG2 Main Profile / High Level Video Compression through the Encapsulated Format. Annex A defines Non-Fragmentable and Fragmentable Encapsulated Transfer Syntaxes that reference the MPEG2 Main Profile / High Level Standard.
MPEG2 compression is inherently lossy. The context where the usage of lossy 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 MPEG2 Main Profile / High Level are also beyond the scope of this Standard.
The use of the DICOM Encapsulated Format to support MPEG2 Main Profile / High Level 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, with some specific exceptions noted here. The Pixel Data characteristics included in the MPEG2 Main Profile / High Level bit stream shall be used to decode the compressed data stream.
These requirements are specified in terms of consistency with what is encapsulated, rather than in terms of the uncompressed Pixel Data from which the compressed data stream may have been derived.
When decompressing, should the characteristics explicitly specified in the compressed data stream 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.
If MPEG2 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 YBR_PARTIAL_420 to RGB during decompression and Native re-encoding, the Photometric Interpretation will be changed to RGB in the Data Set with the Native encoding.
Photometric Interpretation (0028,0004) shall be YBR_PARTIAL_420 or MONOCHROME2
Columns (0028,0011) shall be 1280 if Rows is 720, or shall be 1920 if Rows is 1080.
The value of MPEG2 aspect_ratio_information shall be 0011 in the encapsulated MPEG2 data stream corresponding to a 'Display Aspect Ratio' (DAR) of 16:9.
The DICOM Attribute Pixel Aspect Ratio (0028,0034) shall be absent. This corresponds to a 'Sampling Aspect Ratio' (SAR) of 1:1.
Cine Rate (0018,0040) and Frame Time (0018,1063) or Frame Time Vector (0018,1065) shall be consistent with the limitations of Main Profile / High Level, as specified in Table 8-2.
The requirements on rows and columns are to maximize interoperability between software environments and commonly available hardware MPEG2 encoder/decoder implementations. Should the source picture have a lower value, it should be re-formatted accordingly by scaling and/or pixel padding prior to MPEG2 encoding.
The frame rate of the acquiring camera for '30 Hz HD' MPEG2 may be either 30 or 30/1.001 (approximately 29.97) frames/sec. Similarly, the frame rate in the case of 60 Hz may be either 60 or 60/1.001 (approximately 59.94) frames/sec This may lead to small inconsistencies between the video timebase and real time.
The Frame Time (0018,1063) may be calculated from the frame rate of the acquiring camera. A frame time of 33.367 ms corresponds to 29.97 frames per second.
The value of chroma_format for this profile and level is defined by MPEG as 4:2:0.
Examples of screen resolutions supported by MPEG2 Main Profile / High Level are shown in Table 8-y. Frame rates of 50 Hz and 60 Hz (progressive) at the maximum resolution of 1080 by 1920 are not supported by Main Profile / High Level. Interlace at the maximum resolution is supported at a field rate of 50 Hz or 60 Hz, which corresponds to a frame rate of 25 Hz or 30 Hz respectively as described in Table 8-y.
An MPEG2 Main Profile / High Level decoder is able to decode bit streams conforming to lower levels. These include the 1080 by 1440 bit streams of MP@H-14, and the Main Level bit streams used in the existing MPEG2 Main Profile / Main Level Transfer Syntax in the Visible Light IOD.
The restriction of DAR to 16:9 is required to ensure interoperability because of limitations in commonly available hardware chip set implementations for MPEG2 Main Profile / High Level.
For the Non-Fragmentable Encapsulated Transfer Syntax, one Fragment shall contain the whole MPEG2 bit stream.
For the Fragmentable Encapsulated Transfer Syntax, the stream may be segmented into multiple Fragments.
If a video stream exceeds the maximum length of one Fragment (2^32-2 bytes), it may be sent using a Fragmentable Encapsulated Transfer Syntax. Alternatively, it may be sent using a Non-Fragmentable Encapsulated Transfer Syntax as multiple SOP Instances, but each SOP Instance will contain an independent and playable bit stream, and not depend on the encoded bit stream in other (previous) instances. The manner in which such separate instances are related is not specified in the Standard, but mechanisms such as grouping into the same Series, and references to earlier instances using Referenced Image Sequence may be used.
Fragmentable Encapsulated Transfer Syntaxes allow for streams of essentially unlimited length; the only limit imposed is the maximum Number of Frames (0028,0008), which is 2^31-1 frames (largest positive Value in an Integer String VR).
The Basic Offset Table in the Pixel Data (7FE0,0010) shall be empty (present but zero length).
The Basic Offset Table is not used because MPEG2 contains its own mechanism for describing navigation of Frames. To enable decoding of only a part of the sequence, MPEG2 manages a header in any group of pictures (GOP) containing a time_code - a 25-bit integer containing the following: drop_frame_flag, time_code_hours, time_code_minutes, marker_bit, time_code_seconds and time_code_pictures.
The container format for the video bit stream is not constrained. For example, it may MPEG-2 Transport Stream (MPEG-TS), MPEG-2 Program Stream (MPEG-PS), MPEG-2 Elementary Stream (MPEG-ES), MPEG-2 Packetized Elementary Stream (MPEG-PES) (see [ISO/IEC 13818-1]) or MPEG-4 (MP4) container (see [ISO/IEC 14496-12] and [ISO/IEC 14496-14]).
Any audio components present within the MPEG2 Main Profile / High Level bit stream shall comply with the restrictions as for MPEG2 Main Profile / Main Level as stated in Section 8.2.5.
MPEG-4 AVC/H.264 High Profile / Level 4.1 corresponds to what is commonly known as HDTV ('High Definition Television'). DICOM provides a mechanism for supporting the use of MPEG-4 AVC/H.264 Image Compression through the Encapsulated Format. Annex A defines Non-Fragmentable and Fragmentable Encapsulated Transfer Syntaxes that reference the MPEG-4 AVC/H.264 Standard.
MPEG-4 AVC/H.264 compression / High Profile compression is inherently lossy. The context where the usage of lossy 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 MPEG-4 AVC/H.264 High Profile / Level 4.1 are also beyond the scope of this Standard.
The use of the DICOM Encapsulated Format to support MPEG-4 AVC/H.264 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, with some specific exceptions noted here. The Pixel Data characteristics included in the MPEG-4 AVC/H.264 bit stream shall be used to decode the compressed data stream.
These requirements are specified in terms of consistency with what is encapsulated, rather than in terms of the uncompressed Pixel Data from which the compressed data stream may have been derived.
When decompressing, should the characteristics explicitly specified in the compressed data stream 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.
If MPEG-4 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 YBR_PARTIAL_420 to RGB during decompression and Native re-encoding, the Photometric Interpretation will be changed to RGB in the Data Set with the Native encoding.
Photometric Interpretation (0028,0004) shall be YBR_PARTIAL_420
The value of MPEG-4 AVC/H.264 sample aspect_ratio_idc shall be 1 in the encapsulated MPEG-4 AVC/H.264 bit stream if aspect_ratio_info_present_flag is 1.
Pixel Aspect Ratio (0028,0034) shall be absent. This corresponds to a 'Sampling Aspect Ratio' (SAR) of 1:1.
The possible Values for Rows (0028,0010), Columns (0028,0011), Cine Rate (0018,0040), and Frame Time (0018,1063) or Frame Time Vector (0018,1065) depend on the used Transfer Syntax.
For MPEG-4 AVC/H.264 High Profile / Level 4.1 Transfer Syntax, the Values for these Data Elements shall be compliant with the High Profile / Level 4.1 of the MPEG-4 AVC/H.264 standard ([ISO/IEC 14496-10]) and restricted to a square pixel aspect ratio.
For MPEG-4 AVC/H.264 BD-compatible High Profile / Level 4.1 Transfer Syntax, the Values for these Data Elements shall be as specified in Table 8-4.
The Value of Planar Configuration (0028,0006) is irrelevant since the manner of encoding components is specified in the MPEG-4 AVC/H.264 standard, hence it is set to 0.
The limitation on rows and columns are to maximize interoperability between software environments and commonly available hardware MPEG-4 AVC/H.264 encoder/decoder implementations. Source pictures that have a lower value should be re-formatted by scaling and/or pixel padding prior to MPEG-4 AVC/H.264 encoding.
The frame rate of the acquiring camera for '30 Hz HD' MPEG-4 AVC/H.264 may be either 30 or 30/1.001 (approximately 29.97) frames/sec. Similarly, the frame rate in the case of 60 Hz may be either 60 or 60/1.001 (approximately 59.94) frames/sec. This may lead to small inconsistencies between the video timebase and real time. The relationship between frame rate and frame time is shown in Table 8-5.
The Frame Time (0018,1063) may be calculated from the frame rate of the acquiring camera. A frame rate of 29.97 frames per second corresponds to a frame time of 33.367 ms.
The value of chroma_format for this profile and level is defined by MPEG as 4:2:0.
Example screen resolutions supported by MPEG-4 AVC/H.264 High Profile / Level 4.1 can be taken from Table 8-4. Frame rates of 50 Hz and 60 Hz (progressive) at the maximum resolution of 1080 by 1920 are not supported by MPEG-4 AVC/H.264 High Profile / Level 4.1. Interlace at the maximum resolution is supported at a field rate of 50 Hz or 60 Hz, which corresponds to a frame rate of 25 Hz or 30 Hz respectively. Smaller resolutions may be used as long as they comply with the square pixel aspect ratio. An example is XGA resolution with an image resolution of 768 by 1024 pixels. For smaller resolutions there are higher frame rates possible. For example it may be up to 80 Hz for XGA.
The display aspect ratio is defined implicitly by the pixel resolution of the video picture. Only square pixel aspect ratio is allowed. MPEG-4 AVC/H.264 BD-compatible High Profile / Level 4.1 will only support resolutions that result in a 16:9 display aspect ratio
The permitted screen resolutions for the MPEG-4 AVC/H.264 BD-compatible High Profile / Level 4.1 are listed in Table 8-4. Only HD resolutions and no progressive frame rates for 25 or 29.97 frames per seconds are supported. Frame rates of 50 Hz and 60 Hz (progressive) at the maximum resolution of 1080 by 1920 are not supported.
For the Non-Fragmentable Encapsulated Transfer Syntax, one Fragment shall contain the whole MPEG-4 AVC/H.264 bit stream.
For the Fragmentable Encapsulated Transfer Syntax, the stream may be segmented into multiple Fragments.
If a video stream exceeds the maximum length of one Fragment (2^32-2 bytes), it may be sent using a Fragmentable Encapsulated Transfer Syntax. Alternatively, it may be sent using a Non-Fragmentable Encapsulated Transfer Syntax as multiple SOP Instances, but each SOP Instance will contain an independent and playable bit stream, and not depend on the encoded bit stream in other (previous) instances. The manner in which such separate instances are related is not specified in the Standard, but mechanisms such as grouping into the same Series, and references to earlier instances using Referenced Image Sequence may be used.
Fragmentable Encapsulated Transfer Syntaxes allow for streams of essentially unlimited length; the only limit imposed is the maximum Number of Frames (0028,0008), which is 2^31-1 frames (largest positive Value in an Integer String VR).
The container format for the video bit stream shall be MPEG-2 Transport Stream, a.k.a. MPEG-TS (see [ISO/IEC 13818-1]) or MPEG-4, a.k.a. MP4 container (see [ISO/IEC 14496-12] and [ISO/IEC 14496-14]). The PTS/DTS of the transport stream shall be used in the MPEG coding.
Any audio components included in the data container shall follow the constraints detailed in Section 8.2.12 Constraints for Audio Data Integration in AVC and HEVC Compressed Bit Streams.
DICOM provides a mechanism for supporting the use of MPEG-4 AVC/H.264 Image Compression through the Encapsulated Format. Annex A defines Transfer Syntaxes that reference the MPEG-4 AVC/H.264 Standard.
MPEG-4 AVC/H.264 compression / High Profile compression is inherently lossy. The context where the usage of lossy 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 MPEG-4 AVC/H.264 High Profile / Level 4.2 are also beyond the scope of this Standard.
The use of the DICOM Encapsulated Format to support MPEG-4 AVC/H.264 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, with some specific exceptions noted here. The Pixel Data characteristics included in the MPEG-4 AVC/H.264 bit stream shall be used to decode the compressed data stream.
These requirements are specified in terms of consistency with what is encapsulated, rather than in terms of the uncompressed Pixel Data from which the compressed data stream may have been derived.
When decompressing, should the characteristics explicitly specified in the compressed data stream 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.
If MPEG-4 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 YBR_PARTIAL_420 to RGB during decompression and Native re-encoding, the Photometric Interpretation will be changed to RGB in the Data Set with the Native encoding.
Photometric Interpretation (0028,0004) shall be YBR_PARTIAL_420
The value of MPEG-4 AVC/H.264 sample aspect_ratio_idc shall be 1 in the encapsulated MPEG-4 AVC/H.264 bit stream if aspect_ratio_info_present_flag is 1.
Pixel Aspect Ratio (0028,0034) shall be absent. This corresponds to a 'Sampling Aspect Ratio' (SAR) of 1:1.
The Values for Rows (0028,0010), Columns (0028,0011), Cine Rate (0018,0040), and Frame Time (0018,1063) or Frame Time Vector (0018,1065) shall be compliant with the High Profile / Level 4.2 of the MPEG-4 AVC/H.264 standard ([ISO/IEC 14496-10]) and restricted to a square pixel aspect ratio.
The Value of Planar Configuration (0028,0006) is irrelevant since the manner of encoding components is specified in the MPEG-4 AVC/H.264 standard, hence it is set to 0.
The frame rate of the acquiring camera for '30 Hz HD' MPEG-4 AVC/H.264 may be either 30 or 30/1.001 (approximately 29.97) frames/sec. Similarly, the frame rate in the case of 60 Hz may be either 60 or 60/1.001 (approximately 59.94) frames/sec. This may lead to small inconsistencies between the video timebase and real time. The relationship between frame rate and frame time is shown in Table 8-7.
The Frame Time (0018,1063) may be calculated from the frame rate of the acquiring camera. A frame rate of 29.97 frames per second corresponds to a frame time of 33.367 ms.
The value of chroma_format for this profile and level is defined by MPEG as 4:2:0.
Stereo Pairs Present (0022,0028) shall be YES if stereoscopic pairs are present, otherwise shall be NO or absent.
For the Non-Fragmentable Encapsulated Transfer Syntax, one Fragment shall contain the whole MPEG-4 AVC/H.264 bit stream.
For the Fragmentable Encapsulated Transfer Syntax, the stream may be segmented into multiple Fragments.
If a video stream exceeds the maximum length of one Fragment (2^32-2 bytes), it may be sent using a Fragmentable Encapsulated Transfer Syntax. Alternatively, it may be sent using a Non-Fragmentable Encapsulated Transfer Syntax as multiple SOP Instances, but each SOP Instance will contain an independent and playable bit stream, and not depend on the encoded bit stream in other (previous) instances. The manner in which such separate instances are related is not specified in the Standard, but mechanisms such as grouping into the same Series, and references to earlier instances using Referenced Image Sequence may be used.
Fragmentable Encapsulated Transfer Syntaxes allow for streams of essentially unlimited length; the only limit imposed is the maximum Number of Frames (0028,0008), which is 2^31-1 frames (largest positive Value in an Integer String VR).
The container format for the video bit stream shall be MPEG-2 Transport Stream, a.k.a. MPEG-TS (see [ISO/IEC 13818-1]) or MPEG-4, a.k.a. MP4 container (see [ISO/IEC 14496-12] and [ISO/IEC 14496-14]). The PTS/DTS of the transport stream shall be used in the MPEG coding.
Any audio components included in the data container shall follow the constraints detailed in Section 8.2.12 Constraints for Audio Data Integration in AVC and HEVC Compressed Bit Streams.
DICOM provides a mechanism for supporting the use of MPEG-4 AVC/H.264 Image Compression through the Encapsulated Format. Annex A defines Non-Fragmentable and Fragmentable Encapsulated Transfer Syntaxes that reference the MPEG-4 AVC/H.264 Standard.
MPEG-4 AVC/H.264 Stereo High Profile can achieve better compression by additionally making use of prediction between the base and dependent stereoscopic views. The base view frames make use of intra and inter prediction as in MPEG-4 AVC/H.264 High Profile. This makes it possible for decoders which do not know how to decode the stereoscopic data to decode only the base view. The dependent view is encoded to make use of redundancy due to prediction based upon similarities between the base and the dependent views.
MPEG-4 AVC/H.264 Stereo High Profile makes use of the Level table A-1 of the MPEG-4 specification to set through-put limits. The properties required by the MPEG-4 AVC/H.264 Stereo High Profile Compression are identical to the properties defined in Section 8.2.8, except that Stereo Pairs Present (0022,0028) shall always be YES.
The container format for the video bit stream shall be MPEG-2 Transport Stream, a.k.a. MPEG-TS (see [ISO/IEC 13818-1]) or MPEG-4, a.k.a. MP4 container (see [ISO/IEC 14496-12] and [ISO/IEC 14496-14]). The PTS/DTS of the transport stream shall be used in the MPEG coding.
Any audio components included in the data container shall follow the constraints detailed in Section 8.2.12 Constraints for Audio Data Integration in AVC and HEVC Compressed Bit Streams.
HEVC/H.265 Main Profile / Level 5.1 Main tier is designed for the compression of 4:2:0 video formats up to 4k at 60 frames per second with a bit depth of 8 bits. DICOM provides a mechanism for supporting the use of HEVC/H.265 Image Compression through the Encapsulated Format. Annex A defines a Fragmentable Encapsulated Transfer Syntax that references the HEVC/H.265 Standard.
The use of the DICOM Encapsulated Format to support HEVC/H.265 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, with some specific exceptions noted here. The Pixel Data characteristics included in the HEVC/H.265 bit stream shall be used to decode the compressed data stream.
These requirements are specified in terms of consistency with what is encapsulated, rather than in terms of the uncompressed Pixel Data from which the compressed data stream may have been derived.
When decompressing, should the characteristics explicitly specified in the compressed data stream 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.
Photometric Interpretation (0028,0004) shall be YBR_PARTIAL_420
The value of HEVC/H.265 sample aspect_ratio_idc shall be 1 in the encapsulated HEVC/H.265 bit stream if aspect_ratio_info_present_flag is 1.
Pixel Aspect Ratio (0028,0034) shall be absent. This corresponds to a 'Sampling Aspect Ratio' (SAR) of 1:1.
The Values for Rows (0028,0010), Columns (0028,0011), Cine Rate (0018,0040) and Frame Time (0018,1063) or Frame Time Vector (0018,1065) shall be compliant with the Main Profile / Level 5.1 of the HEVC/H.265 standard [ISO/IEC 23008-2] and restricted to a square pixel aspect ratio.
The Value of Planar Configuration (0028,0006) is irrelevant since the manner of encoding components is specified in the HEVC/H.265 standard, hence it is set to 0.
The limitation on rows and columns are to maximize interoperability between software environments and commonly available hardware HEVC/H.265 encoder/decoder implementations. Source pictures that have a lower value should be re-formatted by scaling and/or pixel padding prior to HEVC/H.265 encoding.
The Frame Time (0018,1063) may be calculated from the frame rate of the acquiring camera. A frame rate of 29.97 frames per second corresponds to a frame time of 33.367 ms.
The value of chroma_format_idc for this profile and level is equal to 1, indicating the usage of 4:2:0 content.
The encapsulated Pixel Data Stream may be segmented into multiple Fragments.
The recipient is expected to concatenate the Fragments while decoding them. This allows for essentially unlimited length streams; the only limit imposed is the maximum Value for Number of Frames (0028,0008) which is 2^31-1 frames (largest positive Value in an Integer String VR).
The container format for the video bit stream shall be MPEG-2 Transport Stream, a.k.a. MPEG-TS (see [ISO/IEC 13818-1]) or MPEG-4, a.k.a. MP4 container (see [ISO/IEC 14496-12] and [ISO/IEC 14496-14]). The PTS/DTS of the transport stream shall be used in the MPEG coding.
Any audio components included in the data container shall follow the constraints detailed in Section 8.2.12 Constraints for Audio Data Integration in AVC and HEVC Compressed Bit Streams.
HEVC/H.265 Main 10 Profile / Level 5.1 Main tier is designed for the compression of 4:2:0 video formats up to 4k at 60 frames per second with a bit depth of 10 bits. DICOM provides a mechanism for supporting the use of HEVC/H.265 Image Compression through the Encapsulated Format. Annex A defines a Fragmentable Encapsulated Transfer Syntax that references the HEVC/H.265 Standard.
The use of the DICOM Encapsulated Format to support HEVC/H.265 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, with some specific exceptions noted here. The Pixel Data characteristics included in the HEVC/H.265 bit stream shall be used to decode the compressed data stream.
These requirements are specified in terms of consistency with what is encapsulated, rather than in terms of the uncompressed Pixel Data from which the compressed data stream may have been derived.
When decompressing, should the characteristics explicitly specified in the compressed data stream 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.
Photometric Interpretation (0028,0004) shall be YBR_PARTIAL_420
The value of HEVC/H.265 sample aspect_ratio_idc shall be 1 in the encapsulated HEVC/H.265 bit stream if aspect_ratio_info_present_flag is 1.
Pixel Aspect Ratio (0028,0034) shall be absent. This corresponds to a 'Sampling Aspect Ratio' (SAR) of 1:1.
The Values for Rows (0028,0010), Columns (0028,0011), Cine Rate (0018,0040), and Frame Time (0018,1063) or Frame Time Vector (0018,1065) shall be compliant with the Main 10 Profile / Level 5.1 of the HEVC/H.265 standard [ISO/IEC 23008-2] and restricted to a square pixel aspect ratio.
The Value of Planar Configuration (0028,0006) is irrelevant since the manner of encoding components is specified in the HEVC/H.265 standard, hence it is set to 0.
The limitation on rows and columns are to maximize interoperability between software environments and commonly available hardware HEVC/H.265 encoder/decoder implementations. Source pictures that have a lower value should be re-formatted by scaling and/or pixel padding prior to HEVC/H.265 encoding.
The Frame Time (0018,1063) may be calculated from the frame rate of the acquiring camera. A frame rate of 29.97 frames per second corresponds to a frame time of 33.367 ms.
The value of chroma_format_idc for this profile and level is equal to 1, indicating the usage of 4:2:0 content.
The encapsulated Pixel Data Stream may be segmented into multiple Fragments.
The recipient is expected to concatenate the Fragments while decoding them. This allows for essentially unlimited length streams; the only limit imposed is the maximum Value for Number of Frames (0028,0008) which is 2^31-1 frames (largest positive Value in an Integer String VR).
The container format for the video bit stream shall be MPEG-2 Transport Stream, a.k.a. MPEG-TS (see [ISO/IEC 13818-1]) or MPEG-4, a.k.a. MP4 container (see [ISO/IEC 14496-12] and [ISO/IEC 14496-14]). The PTS/DTS of the transport stream shall be used in the MPEG coding.
Any audio components included in the data container shall follow the constraints detailed in Section 8.2.12 Constraints for Audio Data Integration in AVC and HEVC Compressed Bit Streams.
This section describes the constraints pertaining to the presence of audio data alongside Pixel Data in DICOM objects. It affects the following Pixel Data encapsulation Transfer Syntaxes:
Any audio components present within a bit stream whose Transfer Syntax is among those listed above shall be interleaved in either LPCM, AC-3, AAC, MP3 or MPEG-1 Layer II audio format and shall comply with the following restrictions:
AC-3 is standardized in [ETSI TS 102 366]
If AC-3 is used for Audio components, the container format shall be MPEG-2 TS.
AAC is standardized in Part 7 of the MPEG-2 standard (see [ISO/IEC 13818-7], and Subpart 4 in Part 3 of the MPEG-4 standard (see [ISO/IEC 14496-3]).
CBR MPEG-1 LAYER III (MP3) Audio Standard
MPEG-1 Layer III is standardized in Part 3 of the MPEG-1 standard (see [ISO/IEC 11172-3]).
Although MPEG describes each channel as including up to 5 signals (e.g., for surround effects), it is recommended to limit each of the two channels to 2 signals each one (stereo).
MPEG-1 Layer II is standardized in Part 3 of the MPEG-1 standard (see [ISO/IEC 11172-3]).
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:
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] .
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.
DICOM provides a mechanism for supporting the use of High-Throughput JPEG 2000 (HTJ2K) Image Compression through the Encapsulated Format. Annex A defines three Transfer Syntaxes that reference the HTJ2K Standard and provide one lossy compression scheme, and two lossless compression schemes, the second of which is optimized for display of progressive bit streams.
The context where the usage of lossy 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 HTJ2K lossy compression are also beyond the scope of this Standard.
The use of the DICOM Encapsulated Format to support HTJ2K 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 HTJ2K bit stream 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.14-1. No other Standard Photometric Interpretation Values shall be used.
Table 8.2.14-1. Valid Values of Pixel Data Related Attributes for HTJ2K Transfer Syntaxes using Standard Photometric Interpretations
These requirements are specified in terms of consistency with what is encapsulated, rather than in terms of the uncompressed Pixel Data from which the compressed data stream may have been derived.
When decompressing, should the characteristics explicitly specified in the compressed data stream 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.
The HTJ2K bit stream specifies whether or not a reversible or irreversible multi-component (color) transformation [ISO 15444-1 Annex G], if any, has been applied. If no multi-component transformation has been applied, then the components shall correspond to those specified by the DICOM Attribute Photometric Interpretation (0028,0004). If the JPEG 2000 Part 1 reversible multi-component transformation has been applied then the DICOM Attribute Photometric Interpretation (0028,0004) shall be YBR_RCT. If the JPEG 2000 Part 1 irreversible multi-component transformation has been applied then the DICOM Attribute Photometric Interpretation (0028,0004) shall be YBR_ICT.
For example, single component may be present, and the Photometric Interpretation (0028,0004) may be MONOCHROME2.
The application of a JPEG 2000 Part 1 reversible multi-component transformation is signaled in the JPEG 2000 bit stream by a value of 1 rather than 0 in the SGcod Multiple component transformation type of the COD marker segment [ISO 15444-1 Table A.17]. No other Value of Photometric Interpretation than YBR_RCT or YBR_ICT is permitted when SGcod Multiple component transformation type is 1.
Though it would be unusual, would not take advantage of correlation between the red, green and blue components, and would not achieve effective compression, a Photometric Interpretation of RGB could be specified as long as no multi-component transformation [ISO 15444-1 Annex G] was specified by the JPEG 2000 bit stream. For some applications the use of RGB is permitted, e.g., Whole Slide Microscopy Images, to allow conversion to DICOM from proprietary formats without loss due to color space transformation. Alternative methods of decorrelation of the color components than those specified in [ISO 15444-1 Annex G] are permitted as defined in PS3.3, such as a Photometric Interpretation of YBR_FULL; this may be useful when converting existing YBR_FULL Pixel Data (e.g., in a different Transfer Syntax) without further loss.
In either case (Photometric Interpretation of RGB or YBR_FULL), the value of SGcod Multiple component transformation type would be 0.
PS3.3 may constrain the Values of Photometric Interpretation for specific IODs.
Despite the application of a multi-component color transformation and its reflection in the Photometric Interpretation Attribute, the "color space" remains undefined. There is currently no means of conveying "standard color spaces" either by fixed values (such as sRGB) or by ICC profiles. Note in particular that the JP2 file header is not sent in the HTJ2K bit stream that is encapsulated in DICOM.
If HTJ2K 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 YBR_ICT or YBR_RCT to RGB during decompression and Native re-encoding, the Photometric Interpretation will be changed to RGB in the Data Set with the Native encoding.
The upper limit of 40 on Bits Allocated (0028,0100) and 38 on Bits Stored (0028,0101) reflects the maximum HTJ2K sample precision of 38 and the DICOM requirement to describe Bits Allocated (0028,0100) as multiples of bytes (octets).
The HTJ2K bit stream is capable of encoding both signed and unsigned pixel values, hence the Value of Pixel Representation (0028,0103) may be either 0 or 1 for monochrome Photometric Interpretations depending on what has been encoded (as specified in the SIZ marker segment in the precision and sign of component parameter).
The Value of Planar Configuration (0028,0006) is irrelevant since the manner of encoding components is specified in the JPEG 2000 standard, hence it shall be set to 0.
DICOM provides a mechanism for supporting the use of JPEG XL Image Compression through the Encapsulated Format. Annex A defines a number of Transfer Syntaxes that reference the JPEG XL Standard. The JPEG XL Lossless Transfer Syntax provides a compression scheme that preserves the bits of the original image, i.e., lossless. The JPEG XL JPEG Recompression Transfer Syntax preserves the bits of the (lossy) JPEG encoding. The JPEG XL Transfer Syntax is a potentially lossy compression of the original image.
The context where the usage of lossy 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 XL lossy compression are also beyond the scope of this Standard.
The use of the DICOM Encapsulated Format to support JPEG XL 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 XL bit stream shall be used to decode 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.15-1. No other Standard Photometric Interpretation values shall be used.
Table 8.2.15-1. Valid Values of Pixel Data Related Attributes for JPEG XL Transfer Syntaxes using Standard Photometric Interpretations
These requirements are specified in terms of consistency with what is encapsulated, rather than in terms of the uncompressed Pixel Data from which the compressed data stream may have been derived.
When decompressing, should the characteristics explicitly specified in the compressed data stream 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.
PS3.3 may constrain the values of Photometric Interpretation for specific IODs.
The JPEG XL bit stream is capable of encoding both signed and unsigned pixel values, hence the value of Pixel Representation (0028,0103) may be either 0 or 1 for monochrome Photometric Interpretations depending on what has been encoded.
The value of Planar Configuration (0028,0006) is irrelevant since the manner of encoding components is specified in the JPEG XL standard, hence it shall be set to 0.
The DICOM protocol provides for the exchange of encoded time-based signals, or waveforms, encoded in the Waveform Data 5400,1010).
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 Data Element defines the size of each waveform data sample within the Waveform Data (5400,1010). Allowed Values are 8, 16, 32 and 64 bits.
The Value Representation of the Waveform Data (5400,1010) shall be OW; OB shall be used in cases where Waveform Bits Allocated has a Value of 8, but only with Transfer Syntaxes where the Value Representation is explicitly conveyed.
Under the Default Transfer Syntax, OB and OW VRs have the identical byte transfer order.
Conversion of a SOP Instance from the Default Transfer Syntax to an Explicit VR Transfer Syntax (uncompressed) requires the interpretation of the Waveform Bits Allocated (5400,1004) Data Element, to determine the proper VR of the Waveform 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).
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.
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).
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 including the specific target information. Additional parameters required by the application may be appended to the URL when accessing the Pixel Data provider.
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 or HTJ2K bit stream depending on the negotiated Transfer Syntax.
The JPIP server shall return a Content-type of image/jp2, image/jpp-stream, image/jpt-stream, image/jph or image/jphc, all of which shall be supported by the JPIP client, depending on the supported Transfer Syntaxes.
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.
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.
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."
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:
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.
Unique Identifiers (UIDs) provide the capability to uniquely identify a wide variety of items. They guarantee uniqueness across multiple countries, sites, vendors and equipment. Different classes of objects, instance of objects and information entities can be distinguished from one another across the DICOM universe of discourse irrespective of any semantic context.
For example the same UID cannot be used to identify both a study instance (Study Instance UID) and a series instance (Series Instance UID) within that study or a different study. Implementers also need to be cautioned against building new UIDs 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>:
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 in the <org root> is responsible for guaranteeing <suffix> uniqueness by providing registration policies. These policies shall guarantee <suffix> uniqueness for all UIDs created by that organization. Unlike the <org root>, which may be common for UIDs in an organization, 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.
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.
Each component numeric value shall be encoded using the characters 0-9 of the Basic G0 Set of the International Reference Version of [ISO 646] (the DICOM Default Character Repertoire).
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.
Each UID used in DICOM shall be defined and registered in one of the following two ways:
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.
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.
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 Object Identifiers [ISO/IEC 9834-1]. The private organization defining the UID shall accept the responsibility of ensuring its uniqueness.
A Transfer Syntax is a set of encoding rules able to unambiguously represent one or more Abstract Syntaxes. In particular, it allows communicating Application Entities to negotiate common encoding techniques they both support (e.g., byte ordering, compression, etc.). A Transfer Syntax is an attribute of a Presentation Context, one or more of which are negotiated at the establishment of an Association between DICOM Application Entities. This Association negotiation is specified in PS3.8 and discussed in PS3.7.
The selection of a Transfer Syntax applies to the encoding rules for the Data Set portion of a DICOM Message only. All DICOM Standard and Private Transfer Syntaxes implicitly specify a fixed encoding for the Command Set portion of a DICOM Message as specified in PS3.7.
This Part of the DICOM Standard defines standard DICOM Transfer Syntaxes and assigns a unique Transfer Syntax Name to each one. The standard DICOM Transfer Syntaxes are specified in Annex A. The DICOM notation for Transfer Syntax names is the notation used for UIDs (see Section 9).
The organization responsible for the definition and registration of DICOM Transfer Syntaxes is NEMA. NEMA guarantees uniqueness for all DICOM Transfer Syntax Names.
Privately defined Transfer Syntax Names may also be used; however, they will not be registered by NEMA. Organizations that define private Transfer Syntax Names shall follow the registration process defined in Section 9.2.
DICOM defines a Default Transfer Syntax, the DICOM Implicit VR Little Endian Transfer Syntax (identified by Transfer Syntax UID = "1.2.840.10008.1.2"), which shall be supported by every conformant DICOM Implementation. This implies that:
If an Application Entity issues an A-ASSOCIATE request, it shall offer the DICOM Implicit VR Little Endian Transfer Syntax in at least one of the Presentation Contexts associated with each offered Abstract Syntax.
Offering Abstract Syntax (AS1) in two Presentation Contexts with Transfer Syntaxes (TS1) and (TS2) is not valid, but offering AS1-TS1, AS1-TS2 and AS1-TSD is valid because the DICOM Default Little Endian Transfer Syntax (TSD) is present in at least one of the Presentation Contexts that are based on Abstract Syntax (AS1).
If an Application Entity receives an A-ASSOCIATE indication corresponding to a request that follows the requirements specified in Section 10.1 (a), every Presentation Context related to a given Abstract Syntax cannot be rejected in an A-ASSOCIATE response for the reason that none of the Transfer Syntaxes are supported.
Both of these requirements, (a) and (b), are waived when the Application Entity sending the Pixel Data has only access to the Pixel Data in lossy compressed form or the Pixel Data in a lossless compressed or encapsulated uncompressed form that is of such length that it cannot be encoded in the Default Transfer Syntax, and a Transfer Syntax that uses a Pixel Data reference is not offered.
Requirement (b) to accept the Default Transfer Syntax is waived if a Transfer Syntax that uses a Pixel Data reference is offered.
In other words, every sending AE is required to be able to convert any Data Set it is going to transmit into the Default Transfer Syntax, regardless of the form in which it originally received or stored the Data Set, except in the cases of when the decompressed or unencapsulated Pixel Data is too large to encode in the Default Transfer Syntax or is received in a lossy compressed form. In the case of lossy compressed Pixel Data, the sending AE is permitted to propose only the lossy compressed Transfer Syntax appropriate to the lossy form that was received. In the case of lossless compressed or encapsulated uncompressed Pixel Data that is too large to encode in the Default Transfer Syntax, the sending AE is permitted to propose any appropriate lossless compression Transfer Syntax or encapsulated uncompressed Transfer Syntax, not necessarily that in which the image was received, as an alternative to the Default Transfer Syntax.
This waiver does not apply to Data Sets received in a lossless compressed or encapsulated uncompressed form if the decompressed or unencapsulated Pixel Data is small enough to encode in the Default Transfer Syntax, which means that any AE receiving a Data Set in a lossless compressed Transfer Syntax or encapsulated uncompressed Transfer Syntax that needs to re-send the Data Set is required to be able to decompress or unencapsulate it in order to support (at least) the Default Transfer Syntax.
Similar concerns apply to the Web Services transactions and are addressed by specific requirements in PS3.18.
DICOM defines a default for Lossless JPEG Image Compression, which uses a subset of coding Process 14 with a first-order prediction (Selection Value 1). It is identified by Transfer Syntax UID = "1.2.840.10008.1.2.4.70" and shall be supported by every DICOM implementation that chooses to support one or more of the lossless JPEG compression processes. This implies that:
If an Application Entity issues an A-ASSOCIATE request where any offered Abstract Syntaxes is associated in one or more Presentation Context with a JPEG lossless compression Transfer Syntax, at least one of the Presentation Contexts that include this Abstract Syntax, shall include the DICOM Default Lossless JPEG Compression Transfer Syntax and the DICOM Default Little Endian Transfer Syntax (uncompressed).
Offering Abstract Syntax (AS1) in two Presentation Contexts with Transfer Syntaxes JPEG lossless (JL1) and (JL2) is not valid, but offering AS1-JL1, AS1-JL2, AS1-TSD, and AS1-JLD is valid because the DICOM Default Lossless JPEG Compression Transfer Syntax (JLD) and the DICOM Default Little Endian Transfer Syntax (TSD) are present in at least one of the Presentation Contexts that are based on Abstract Syntax (AS1).
If an Application Entity that supports one or more lossless JPEG Transfer Syntax receives an A-ASSOCIATE indication corresponding to a request that follows the requirements specified in Section 10.2 (a), every Presentation Context related to a given Abstract Syntax cannot be rejected in an A-ASSOCIATE response for the reason that the DICOM Default Lossless JPEG Compression Transfer Syntax is not supported.
When Abstract Syntax (AS1) is offered in four Presentation Contexts with Transfer Syntaxes JPEG lossless (JL1) and (JL2) as well as (JLD) and (TSD), both the DICOM Default Lossless JPEG Compression Transfer Syntax (JLD) and the DICOM Default Little Endian Transfer Syntax (TSD) can be rejected if at least one of the other Presentation Contexts for Abstract Syntax (AS1) is accepted.
DICOM defines defaults for Lossy JPEG Image Compression, one for 8-bit images and the other for 12-bit images. JPEG coding Process 1 (identified by Transfer Syntax UID = "1.2.840.10008.1.2.4.50") is used for 8-bit images. JPEG coding Process 4 (identified by Transfer Syntax UID = "1.2.840.10008.1.2.4.51") is used for 12-bit images. This implies that:
If an Application Entity issues an A-ASSOCIATE request where any offered Abstract Syntaxes is associated in one or more Presentation Context(s) with a JPEG lossy compression Transfer Syntax, at least one of the Presentation Contexts that include this Abstract Syntax, shall include the appropriate DICOM Default Lossy JPEG Compression Transfer Syntax.
Offering Abstract Syntax (AS1) in two Presentation Contexts with Transfer Syntaxes JPEG lossy (JL1) and (JL2) is not valid, but offering AS1-JL1, AS1-JL2 and AS1-JLD is valid because the DICOM Default Lossy JPEG Transfer Syntax (JLD) is present in at least one of the Presentation Contexts that are based on Abstract Syntax (AS1).
The DICOM Default Little Endian Transfer Syntax (uncompressed) may be offered if the sender has access to the original Pixel Data in an uncompressed or lossless compressed form.
If an Application Entity that supports one or more Lossy JPEG Transfer Syntaxes receives an A-ASSOCIATE indication corresponding to a request that follows the requirements specified in Section 10.3 (a), every Presentation Context related to a given Abstract Syntax cannot be rejected in an A-ASSOCIATE response for the reason that the DICOM Default Lossy JPEG Transfer Syntax is not supported.
The 12 bit Default Transfer Syntax 1.2.840.10008.1.2.4.51 can also be used to encode 8 bit images, but the bit stream required is not identical to that used in the 8 bit Default Transfer Syntax 1.2.840.10008.1.2.4.50 (see A.4.1).
When Abstract Syntax (AS1) is offered in three Presentation Contexts with Transfer Syntaxes JPEG lossy (JL1) and (JL2) as well as (JLD), the DICOM Default JPEG Lossy Compression Transfer Syntax (JLD) can be rejected if at least one of the other Presentation Contexts for Abstract Syntax (AS1) is accepted.
DICOM defines the RLE Image Compression (see Annex G). This implies that:
If an Application Entity issues an A-ASSOCIATE request where any offered Abstract Syntaxes is associated in one or more Presentation Contexts(s) with RLE compression Transfer Syntax, at least one of the Presentation Contexts that include this Abstract Syntax, shall include the DICOM Default Little Endian Transfer Syntax (uncompressed).
One Transfer Syntax is specified for JPEG-LS Lossless Image Compression, and one Transfer Syntax is specified for JPEG-LS Lossy (Near-Lossless) Image Compression. The JPEG-LS Lossless Transfer Syntax shall be supported as a baseline if the JPEG-LS Lossy (Near-Lossless) Transfer Syntax is supported.
One Transfer Syntax is specified for JPEG 2000 Image Compression (Lossless Only), and one Transfer Syntax is specified for JPEG 2000 Image Compression. Either of these may be negotiated separately and there is no default or baseline specified (other than as described in Section 10.1).
All JPEG 2000 codecs are required by [ISO/IEC 15444-1] to support both reversible and irreversible wavelet and multi-component transformations. The reason for specifying two separate Transfer Syntaxes in DICOM is to allow an application to request the transfer of images in a lossless manner when possible. The JPEG 2000 Image Compression Transfer Syntax allows for either lossless or lossy compression to be used at the sender's discretion.
When the Pixel Data has been received in the JPEG 2000 Image Compression Transfer Syntax, since it may have been lossy compressed, the waiver of the requirement in Section 10.1 to support the DICOM Default Little Endian Transfer Syntax still applies.
In addition, one Transfer Syntax is specified for JPEG 2000 Multi-component Image Compression (Lossless Only) with Multi-Component Transformation Extensions, and one Transfer Syntax is specified for JPEG 2000 Multi-component Image Compression with Multi-Component Transformation Extensions. Either of these may be negotiated separately and there is no default or baseline specified (other than as described in Section 10.1).
JPEG 2000 codecs that support the Part 2 JPEG 2000 Multi-Component Transformation Extensions are required to support all the multi-component extensions as described in Annex J of [ISO/IEC 15444-2]. This includes both array based transformations and the 9-7 and 5-3 wavelet transformations that are also used in Part 1 of JPEG 2000. This also includes component reordering, component collections and application of more than one multi-component transformation in succession.
Two Transfer Syntaxes are specified for JPIP Referenced Pixel Data.
The persistence of the references in objects transferred with one of these Transfer Syntaxes is not defined. That is, applications should make no assumptions as to the timeframe when the referenced Pixel Data will be available. Due to the indeterminate time that the URL remains valid, it may be inappropriate to cache the URL. Because the Pixel Data may not have been retrieved in its entirety or full fidelity, it may be inappropriate to use this Transfer Syntax for the purpose of permanent storage or to reference such instances in Storage Commitment and Performed Procedure Step service classes.
These Transfer Syntaxes shall not be used for media storage defined by PS3.10.
Two Transfer Syntaxes are specified for MPEG-4 AVC/H.264 High Profile / Level 4.1 Video Compression and two Transfer Syntaxes are specified for MPEG-4 AVC/H.264 BD-compliant High Profile / Level 4.1. Transfer Syntax MPEG-4 AVC/H.264 High Profile / Level 4.1 corresponds to the ITU-T H.264 standard's profile and level specifications. Transfer Syntax MPEG-4 AVC/H.264 BD-compliant High Profile / Level 4.1 corresponds to a restricted set of spatial and temporal resolutions described Table 8-4. This Transfer Syntax limits the ITU-T H.264 High Profile / Level 4.1 to HD video formats that are supported by Blu-ray™ (BDRWP 2.B).
Two Transfer Syntaxes are specified for MPEG-4 AVC/H.264 High Profile / Level 4.2 for 2D Video Compression and two Transfer Syntaxes are specified for MPEG-4 AVC/H.264 High Profile / Level 4.2 for 3D Video Compression. Transfer Syntax MPEG-4 AVC/H.264 High Profile / Level 4.2 for 2D Video Compression corresponds to the ITU-T H.264 standard's profile and level specifications except that the use of frame packing formats for 3D video is not allowed as defined in Table 8-8. Transfer Syntax MPEG-4 AVC/H.264 High Profile / Level 4.2 for 3D Video Compression corresponds to the ITU-T H.264 standard's profile and level specifications. It should be used for transmitting stereoscopic 3D content with frame packing formats as defined in Table 8-8.
Two Transfer Syntaxes are specified for MPEG-4 AVC/H.264 Stereo High Profile / Level 4.2 Video Compression. Transfer Syntax MPEG-4 AVC/H.264 Stereo High Profile corresponds to the ITU-T H.264 standard's profile and level specifications.
One Transfer Syntax is specified for HEVC/H.265 Main Profile / Level 5.1 Video Compression. Transfer Syntax HEVC/H.265 Main Profile corresponds to the [ISO/IEC 23008-2] HEVC standard's profile and level specifications.
One Transfer Syntax is specified for HEVC/H.265 Main 10 Profile / Level 5.1 Video Compression. Transfer Syntax HEVC/H.265 Main 10 Profile corresponds to the [ISO/IEC 23008-2] HEVC standard's profile and level specifications.
This Transfer Syntax is used for Uncompressed Video pixels carried in a DICOM-RTV Flow (separated from DICOM-RTV Metadata Flow) as described by [SMPTE ST 2110-20], in the case the video is progressive (e.g., 1080p). The main parameters of the Transfer Syntax are described in Section A.8.
This Transfer Syntax is used for Uncompressed Video pixels carried in a DICOM-RTV Flow (separated from DICOM-RTV Metadata Flow) as described by [SMPTE ST 2110-20], in the case the video is interlaced (e.g., 1080i). The main parameters of the Transfer Syntax are described in Section A.9.
Interlaced video supports transmitting video with a smaller bandwidth. One frame contains only odd lines and the next one contains only even lines. Interlaced video is acceptable for display but may cause problems in image processing. It is recommended to use progressive video. However, in case an original interlaced video signal is converted in the DICOM-RTV format, it is recommended to maintain the interlaced format and let the processing application deal with it.
This Transfer Syntax is used for audio channel data carried in a DICOM-RTV Flow (separated from DICOM-RTV Metadata Flow) as described by [SMPTE ST 2110-30]. The main parameters of the Transfer Syntax are described in Section A.10.
Two Transfer Syntaxes are specified for High-Throughput JPEG 2000 Image Compression (Lossless Only) (HTJ2KLossless and HTJ2KLosslessRPCL), and one for unconstrained High-Throughput JPEG 2000 Image Compression (HTJ2K). Any of these may be negotiated separately and there is no default or baseline specified (other than as described in Section 10.1).
All HTJ2K codecs are required by [ISO/IEC 15444-1] to support both reversible and irreversible wavelet and multi-component transformations. The reason for specifying three separate Transfer Syntaxes in DICOM is to allow an application to request the transfer of images in a lossless manner when possible. The HTJ2K Image Compression Transfer Syntax allows for either lossless or lossy compression to be used at the sender's discretion.
When the Pixel Data has been received in the HTJ2K Image Compression Transfer Syntax, since it may have been lossy compressed, the waiver of the requirement in Section 10.1 to support the DICOM Default Little Endian Transfer Syntax still applies.
The HTJ2K Lossless RPCL Transfer Syntax allows for progressive display of images, as well as retrieval of thumbnail images.
The progression order shall be RPCL (Resolution Position Component Layer). This sequences the resolution blocks so that lower resolutions can be read first.
The number of decompositions shall be sufficient for the width or height of the base resolution to be <= 64. This permits retrieving a thumbnail resolution image.
The Tile Length Markers (TLM) shall be present. This allows finding the resolution breakpoints to support smart streaming.
One Transfer Syntax is specified for JPEG XL Lossless Image Compression, one for JPEG XL JPEG Recompression, which allows for transcoding JPEG encoded data without additional loss, and one for a general JPEG XL Image Compression scheme for any JPEG XL encoded data. Any of these may be negotiated separately and there is no default or baseline specified (other than as described in Section 10.1).
This Transfer Syntax applies to the encoding of the entire DICOM Data Set. This implies that when a DICOM Data Set is being encoded with the DICOM Implicit VR Little Endian Transfer Syntax the following requirements shall be met:
The Data Elements contained in the Data Set structure shall be encoded with Implicit VR (without a VR Field) as specified in Section 7.1.3.
The encoding of the overall Data Set structure (Data Element Tags, Value Length, and Value) shall be in Little Endian as specified in Section 7.3.
The encoding of the Data Elements of the Data Set shall be as follows according to their Value Representations:
For all Value Representations defined in this Part, except for the Value Representations OB and OW, the encoding shall be in Little Endian as specified in Section 7.3.
For the Value Representations OB, OL, OV and OW, the encoding shall meet the following specification depending on the Data Element Tag:
Pixel Data (7FE0,0010) has the Value Representation OW and shall be encoded in Little Endian.
The OL and OV Value Representations are not used for Pixel Data, even if it has a Bits Allocated (0028,0100) of 32 or 64, since OL and OV were added to the Standard after the encoding of Pixel Data had been established
The 32-bit Value Length Field limits the maximum size of the Pixel Data that can be encoded in Implicit VR Little Endian Transfer Syntax, since they are sent in a Native Format.
Overlay Data (60xx,3000) has the Value Representation OW and shall be encoded in Little Endian.
Waveform Data (5400,1010) shall have Value Representation OW and shall be encoded in Little Endian.
Red Palette Color Lookup Table Data (0028,1201), Green Palette Color Lookup Table Data (0028,1202), Blue Color Palette Lookup Table Data (0028,1203) and Alpha Palette Color Lookup Table Data (0028,1204) have the Value Representation OW and shall be encoded in Little Endian.
Previous versions of the Standard either did not specify the encoding of Red Palette Color Lookup Table Data (0028,1201), Green Palette Color Lookup Table Data (0028,1202) and Blue Color Palette Lookup Table Data (0028,1203) in this Part, but specified a VR of US or SS in PS3.6-1993, or specified OW in this Part but a VR of US, SS or OW in PS3.6-1996. The actual encoding of the Values and their byte order would be identical in each case.
Red Palette Color Lookup Table Descriptor (0028,1101), Green Palette Color Lookup Table Descriptor (0028,1102) and Blue Palette Color Lookup Table Descriptor (0028,1103) have the Value Representation SS or US (depending on rules specified in the IOD in PS3.3), and shall be encoded in Little Endian. The first and third Values are always interpreted as unsigned, regardless of the Value Representation.
Data Elements (0028,1221),(0028,1222),(0028,1223) Segmented Red, Green, Blue Palette Color Lookup Table Data have the Value Representation OW and shall be encoded in Little Endian.
LUT Data (0028,3006) has the Value Representation US or OW and shall be encoded in Little Endian.
Previous versions of the Standard did not specify the encoding of these Data Elements in this Part, but specified a VR of US or SS in PS3.6-1998. A VR of OW has been added to support Explicit VR Transfer Syntaxes. Moreover this Data Element is always unsigned, therefore the VR of SS has been removed. The actual encoding of the Values and their byte order would be identical in each case.
LUT Descriptor (0028,3002) has the Value Representation SS or US (depending on rules specified in the IOD in PS3.3), and shall be encoded in Little Endian. The first and third Values are always interpreted as unsigned, regardless of the Value Representation.
Blending Lookup Table Data (0028,1408) has the Value Representation OW and shall be encoded in Little Endian.
Track Point Index List (0066,0129) has the Value Representation OL and shall be encoded in Little Endian and is always interpreted as unsigned.
Encoding of Curve Data (50xx,3000) and Audio Sample Data (50xx,200C) was previously defined but has been retired. See PS3.5-2004.
Vertex Point Index List (0066,0025), Edge Point Index List (0066,0024), Triangle Point Index List (0066,0023) and Primitive Point Index List (0066,0029) were previously defined with a Value Representation of OW and always interpreted as unsigned, but have been retired. These have been replaced by corresponding OL Data Elements, which allow Values larger than 65535 to index the full range of points that can be encoded in Point Coordinates Data (0066,0016). See PS3.5-2015c.
This DICOM Implicit VR Little Endian Transfer Syntax shall be identified by a UID of Value "1.2.840.10008.1.2".
This Transfer Syntax applies to the encoding of the entire DICOM Data Set. This implies that when a DICOM Data Set is being encoded with the DICOM Little Endian Transfer Syntax the following requirements shall be met:
The Data Elements contained in the Data Set structure shall be encoded with Explicit VR (with a VR Field) as specified in Section 7.1.2.
The encoding of the overall Data Set structure (Data Element Tags, Value Length, and Value) shall be in Little Endian as specified in Section 7.3.
The encoding of the Data Elements of the Data Set shall be as follows according to their Value Representations:
For all Value Representations defined in this Part, except for the Value Representations OB and OW, the encoding shall be in Little Endian as specified in Section 7.3.
For the Value Representations OB, OL, OV and OW, the encoding shall meet the following specification depending on the Data Element Tag:
The OL and OV Value Representations are not used for Pixel Data, even if it has a Bits Allocated (0028,0100) of 32 or 64, since OL and OV were added to the Standard after the encoding of Pixel Data had been established
The 32-bit Value Length Field limits the maximum size of the Pixel Data that can be encoded in Little Endian Transfer Syntax (Explicit VR) since they are sent in a Native Format.
shall have the Value Representation OB or OW and shall be encoded in Little Endian.
Previous versions of the Standard specified that the choice of OB or OW VR was based on whether or not Overlay Bits Allocated (60xx,0100) was greater than, or less than or equal to, 8. However, since only one bit plane can be encoded in each Overlay Data (60xx,3000) Element, no Value of Overlay Bits Allocated other than 1 makes sense. Such a restriction is now present in PS3.3.
Waveform Data (5400,1010) has the Value Representation specified in its Explicit VR Field. The component points shall be encoded in Little Endian.
Red Palette Color Lookup Table Data (0028,1201), Green Palette Color Lookup Table Data (0028,1202), Blue Color Palette Lookup Table Data (0028,1203) and Alpha Palette Color Lookup Table Data (0028,1204) have the Value Representation OW and shall be encoded in Little Endian.
Previous versions of the Standard either did not specify the encoding of Red Palette Color Lookup Table Data (0028,1201), Green Palette Color Lookup Table Data (0028,1202) and Blue Color Palette Lookup Table Data (0028,1203) in this Part, but specified a VR of US or SS in PS3.6-1993, or specified OW in this Part but a VR of US, SS or OW in PS3.6-1996. The actual encoding of the Values and their byte order would be identical in each case, though the explicitly encoded VR field would be different. However, an Explicit VR of US or SS cannot be used to encode a table of 216 entries, since the Value Length is restricted to 16 bits.
Red Palette Color Lookup Table Descriptor (0028,1101), Green Palette Color Lookup Table Descriptor (0028,1102) and Blue Palette Color Lookup Table Descriptor (0028,1103) have the Value Representation SS or US (depending on rules specified in the IOD in PS3.3), and shall be encoded in Little Endian. The first and third Values are always interpreted as unsigned, regardless of the Value Representation.
Segmented Red Palette Color Lookup Table Data (0028,1221), Segmented Green Palette Color Lookup Table Data (0028,1222) and Segmented Blue Palette Color Lookup Table Data (0028,1223) have the Value Representation OW and shall be encoded in Little Endian.
LUT Data (0028,3006) has the Value Representation US or OW and shall be encoded in Little Endian.
Previous versions of the Standard did not specify the encoding of these Data Elements in this Part, but specified a VR of US or SS in PS3.6-1998. However, an Explicit VR of US or SS cannot be used to encode a table of 216 entries, since the Value Length is restricted to 16 bits. Hence a VR of OW has been added. Moreover this Data Element is always unsigned, therefore the VR of SS has been removed. The actual encoding of the Values and their byte order would be identical in each case, though the explicitly encoded VR field would be different.
LUT Descriptor (0028,3002) has the Value Representation SS or US (depending on rules specified in the IOD in PS3.3), and shall be encoded in Little Endian. The first and third Values are always interpreted as unsigned, regardless of the Value Representation.
Blending Lookup Table Data (0028,1408) has the Value Representation OW and shall be encoded in Little Endian.
Track Point Index List (0066,0129) has the Value Representation OL and shall be encoded in Little Endian and is always interpreted as unsigned.
For Data encoded with the Value Representation OB, the Data encoding is unaffected by byte ordering.
Encoding of Curve Data (50xx,3000) and Audio Sample Data (50xx,200C) was previously defined but has been retired. See PS3.5-2004.
Vertex Point Index List (0066,0025), Edge Point Index List (0066,0024), Triangle Point Index List (0066,0023) and Primitive Point Index List (0066,0029) were previously defined with a Value Representation of OW and always interpreted as unsigned, but have been retired. These have been replaced by corresponding OL Data Elements, which allow Values larger than 65535 to index the full range of points that can be encoded in Point Coordinates Data (0066,0016). See PS3.5-2015c.
This DICOM Explicit VR Little Endian Transfer Syntax shall be identified by a UID of Value "1.2.840.10008.1.2.1".
These Transfer Syntaxes apply to the encoding of the entire DICOM Data Set, even though the image Pixel Data (7FE0,0010) portion of the DICOM Data Set is the only portion that is encoded by an encapsulated format. These Transfer Syntaxes shall only be used when Pixel Data (7FE0,0010) is present in the top level Data Set, and hence shall not be used when Float Pixel Data (7FE0,0008) or Double Float Pixel Data (7FE0,0009) are present. This implies that when a DICOM Message is being encoded according to an encapsulation Transfer Syntax the following requirements shall be met:
The Data Elements contained in the Data Set structure shall be encoded with Explicit VR (with a VR Field) as specified in Section 7.1.2.
The encoding of the overall Data Set structure (Data Element Tags, Value Length, etc.) shall be in Little Endian as specified in Section 7.3.
The encoding of the Data Elements of the Data Set shall be as follows according to their Value Representations:
For all Value Representations defined in this Part of the DICOM Standard, except for the Value Representations OB and OW, the encoding shall be in Little Endian as specified in Section 7.3.
For the Value Representations OB, OL, OV and OW, the encoding shall meet the following specification depending on the Data Element Tag:
Pixel Data (7FE0,0010) may be encapsulated or native.
It shall be encapsulated if present in the top-level Data Set (i.e., not nested within a Sequence Data Element).
The distinction between defined Value Length (native) and undefined Value Length (encapsulated) is present so that the top level Data Set Pixel Data can be compressed (and hence encapsulated), but the Pixel Data within an Icon Image Sequence may or may not be compressed.
If native, it shall have a defined Value Length, and be encoded as follows:
If encapsulated, it has the Value Representation OB and is an octet-stream resulting from one of the encoding processes. It contains the encoded Pixel Data Stream fragmented into one or more Item(s). This Pixel Data Stream may represent a Single-frame or Multi-frame Image. See Table A.4-1 and Table A.4-2.
The Length of the Data Element (7FE0,0010) shall be set to the Value for Undefined Length (FFFFFFFFH).
Each Data Stream Fragment encoded according to the specific encoding process shall be encapsulated as a DICOM Item with a specific Data Element Tag of Value (FFFE,E000). The Item Tag is followed by a 4 byte Value (Item) Length Field encoding the explicit number of bytes of the Item.
All items containing an encoded Fragment shall be made of an even number of bytes greater or equal to two. The last Fragment of a Frame may be padded, if necessary, to meet the Sequence Item format requirements of the DICOM Standard.
Any necessary padding may be added in the JPEG or JPEG-LS compressed data stream as per ISO 10918-1 and ISO 14495-1 such that the End of Image (EOI) marker ends on an even byte boundary, or may be appended after the EOI marker, depending on the implementation.
ISO 10918-1 and ISO 14495-1 define the ability to add any number of padding bytes FFH before any marker (all of which also begin with FFH). It is strongly recommended that FFH padding bytes not be added before the Start of Image (SOI) marker.
The first Item in the Sequence of Items before the encoded Pixel Data Stream shall be a Basic Offset Table item. The Basic Offset Table Item Value, however, is not required to be present:
When the Item Value is not present, the Item Length shall be zero (00000000H) (see Table A.4-1).
When the Item Value is present, the Basic Offset Table Item Value shall contain concatenated 32-bit unsigned integer values that are byte offsets to the first byte of the Item Tag of the first Fragment for each Frame in the Sequence of Items. These offsets are measured from the first byte of the first Item Tag following the Basic Offset Table item (see Table A.4-2).
For a Multi-frame Image containing only one Frame or a Single-frame Image, the Basic Offset Table Item Value may be present or not. If present it will contain a single 00000000H value.
Decoders of encapsulated Pixel Data, whether Single-frame or Multi-frame, need to accept both an empty Basic Offset Table (zero length) and a Basic Offset Table filled with 32 bit offset values.
A Basic Offset Table Item Value is not permitted (i.e., the Item Length of the first Item will be zero) if Extended Offset Table (7FE0,0001) is present.
If the Basic Offset Table Item Value is not zero length, the first entry will always be 00000000H.
The offset is to the first byte of the Item Tag itself, not the first byte of the Value Field within the Item
This Sequence of Items is terminated by a Sequence Delimiter Item with the Tag (FFFE,E0DD) and an Value (Item) Length Field of Value (00000000H) (i.e., no Value Field shall be present).
Waveform Data (5400,1010) has the Value Representation specified in its Explicit VR Field. The component points shall be encoded in Little Endian.
Red Palette Color Lookup Table Data (0028,1201), Green Palette Color Lookup Table Data (0028,1202), Blue Color Palette Lookup Table Data (0028,1203) and Alpha Palette Color Lookup Table Data (0028,1204) have the Value Representation OW and shall be encoded in Little Endian.
Previous versions of the Standard either did not specify the encoding of Data Elements 0028,1201), (0028,1202), (0028,1203) in this Part, but specified a VR of US or SS in PS3.6-1993, or specified OW in this Part but a VR of US, SS or OW in PS3.6-1996. The actual encoding of the Values and their byte order would be identical in each case, though the explicitly encoded VR field would be different. However, an Explicit VR of US or SS cannot be used to encode a table of 216 entries, since the Value Length is restricted to 16 bits.
Red Palette Color Lookup Table Descriptor (0028,1101), Green Palette Color Lookup Table Descriptor (0028,1102) and Blue Palette Color Lookup Table Descriptor (0028,1103) have the Value Representation SS or US (depending on rules specified in the IOD in PS3.3), and shall be encoded in Little Endian. The first and third Values are always interpreted as unsigned, regardless of the Value Representation.
Segmented Red Palette Color Lookup Table Data (0028,1221), Segmented Green Palette Color Lookup Table Data (0028,1222) and Segmented Blue Palette Color Lookup Table Data (0028,1223) have the Value Representation OW and shall be encoded in Little Endian.
LUT Data (0028,3006) has the Value Representation US or OW and shall be encoded in Little Endian.
Previous versions of the Standard did not specify the encoding of these Data Elements in this Part, but specified a VR of US or SS in PS3.6-1998. However, an Explicit VR of US or SS cannot be used to encode a table of 216 entries, since the Value Length is restricted to 16 bits. Hence a VR of OW has been added. Moreover this Data Element is always unsigned, therefore the VR of SS has been removed. The actual encoding of the Values and their byte order would be identical in each case, though the explicitly encoded VR field would be different.
LUT Descriptor (0028,3002) has the Value Representation SS or US (depending on rules specified in the IOD in PS3.3), and shall be encoded in Little Endian. The first and third Values are always interpreted as unsigned, regardless of the Value Representation.
Blending Lookup Table Data (0028,1408) has the Value Representation OW and shall be encoded in Little Endian.
Track Point Index List (0066,0129) has the Value Representation OL and shall be encoded in Little Endian and is always interpreted as unsigned.
For Data encoded with the Value Representation OB, the Data encoding is unaffected by byte ordering.
Encoding of Curve Data (50xx,3000) and Audio Sample Data (50xx,200C) was previously defined but has been retired. See PS3.5-2004.
Vertex Point Index List (0066,0025), Edge Point Index List (0066,0024), Triangle Point Index List (0066,0023) and Primitive Point Index List (0066,0029) were previously defined with a Value Representation of OW and always interpreted as unsigned, but have been retired. These have been replaced by corresponding OL Data Elements, which allow Values larger than 65535 to index the full range of points that can be encoded in Point Coordinates Data (0066,0016). See PS3.5-2015c.
Table A.4-1. Example for Elements of an Encoded Single-frame Image Defined as a Sequence of Three Fragments Without Basic Offset Table Item Value