PS3.5

Информация в настоящей публикации была признана технически обоснованной по консенсусу лиц, участвовавших в разработке и утверждении документа на момент его создания. Консенсус не обязательно означает единогласное согласие среди всех лиц, участвующих в разработке настоящего документа.

Стандарты и руководящие публикации NEMA, одной из которых является документ, содержащийся в настоящем издании, разрабатываются в рамках процесса добровольной разработки стандартов на основе консенсуса. Этот процесс объединяет добровольцев и/или выявляет мнения лиц, заинтересованных в теме, охваченной настоящей публикацией. Хотя NEMA управляет процессом и устанавливает правила для обеспечения справедливости при выработке консенсуса, она не составляет документ и не проводит независимо тестирование, оценку или проверку точности или полноты любой информации или обоснованности любых суждений, содержащихся в её стандартах и руководящих публикациях.

NEMA не несёт ответственности за любые телесные повреждения, ущерб имуществу или иные убытки любого характера, будь то особые, косвенные, последующие или компенсационные, прямо или косвенно вытекающие из публикации, использования, применения или полагания на настоящий документ. NEMA отказывается и не даёт никаких гарантий или поручительств, явных или подразумеваемых, относительно точности или полноты любой информации, опубликованной в настоящем издании, и отказывается и не гарантирует, что информация в настоящем документе будет отвечать каким-либо вашим конкретным целям или потребностям. NEMA не обязуется гарантировать характеристики продукции или услуг любого отдельного производителя или продавца в силу настоящего стандарта или руководства.

Публикуя и предоставляя доступ к настоящему документу, NEMA не берёт на себя оказание профессиональных или иных услуг для любого лица или организации или от их имени, равно как и NEMA не берёт на себя выполнение каких-либо обязанностей, возложенных на любое лицо или организацию в отношении третьих лиц. Любое лицо, использующее настоящий документ, должно полагаться на собственное независимое суждение или, в зависимости от обстоятельств, обращаться за консультацией к компетентному специалисту при определении меры разумной осторожности в каждой конкретной ситуации. Информация и другие стандарты по теме, охваченной настоящей публикацией, могут быть доступны из других источников, к которым пользователь может пожелать обратиться за дополнительными мнениями или сведениями, не охваченными настоящей публикацией.

NEMA не имеет полномочий и не берёт на себя контроль или обеспечение соблюдения положений настоящего документа. NEMA не сертифицирует, не испытывает и не инспектирует продукцию, конструкцию или установки в целях безопасности или охраны здоровья. Любая сертификация или иное заявление о соответствии любой информации, связанной со здоровьем или безопасностью, в настоящем документе не может быть приписана NEMA и является исключительной ответственностью лица, проводящего сертификацию, или автора соответствующего заявления.

Предисловие

Настоящий стандарт DICOM был разработан в соответствии с процедурами Комитета по стандартам DICOM.

Стандарт DICOM структурирован как многочастный документ с использованием руководящих принципов, установленных в [ISO/IEC Directives, Part 2].

DICOM® является зарегистрированным товарным знаком Национальной ассоциации производителей электрооборудования (National Electrical Manufacturers Association) для её публикаций стандартов, относящихся к цифровой связи медицинской информации, все права защищены.

SNOMED®, SNOMED Clinical Terms®, SNOMED CT® являются зарегистрированными товарными знаками Международной организации по разработке стандартов терминологии в области здравоохранения (International Health Terminology Standards Development Organisation, IHTSDO), все права защищены.

1 Область применения

В настоящей Части стандарта определяются структура и кодирование набора данных (Data Set). В контексте прикладных объектов (Application Entities), взаимодействующих по сети (см. PS3.7), набор данных — это та часть DICOM-сообщения, которая передаёт информацию о реальных объектах, управляемых в сети. Набор данных может иметь иное назначение в других вариантах применения настоящего Стандарта; например, при обмене посредством носителей набор данных преобразуется в структуру содержимого файла.

Настоящая часть стандарта DICOM определяет:

кодирование значений (Values)
структуру и использование набора данных (Data Set)
использование элементов данных (Data Elements) и их связи с другими элементами данных
построение и использование вложенных наборов данных (Nested Data Sets)
построение и использование наборов данных, содержащих данные пикселей (Pixel Data)
способ однозначной идентификации информации
спецификацию стандартных синтаксисов передачи DICOM (Transfer Syntaxes)

Настоящая часть стандарта DICOM не определяет:

структуру и синтаксис сообщения (это определено в PS3.7)
структуру и использование набора команд (это определено в PS3.7)
как функционирует или классифицируется служба приложений (это определено в PS3.3 и PS3.4)
как наборы данных связаны с сетевым обменом, хранением на носителях или другими службами

2 Нормативные ссылки

Следующие стандарты содержат положения, которые посредством ссылок в настоящем тексте составляют положения настоящего Стандарта. На момент публикации указанные редакции были действующими. Все стандарты подлежат пересмотру, и сторонам соглашений, основанных на настоящем Стандарте, рекомендуется изучить возможности применения самых последних редакций указанных ниже стандартов.

[ANSI HISPP MSDS] ANSI. 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] ANSI. 1986. Coded Character Set - 7-Bit American National Standard Code for Information Interchange.

[ANSI X3.9] ANSI. 1978. Programming Language FORTRAN. http://www.fortran.com/F77_std/rjcnf-0.html .

[ASTM E-1238-91] ASTM. 1991. Standard Specification for Transferring Clinical Observations Between Independent Computer Systems; Draft Revision 4.2.1.

[BDRWP 2.B] Blu-ray Disc™ Association. March 2005. White Paper Blu-ray Disc™ Format 2.B Audio Visual Application Format Specifications for BD-ROM.

[ECMA TR-098] European Computer Manufacturers Association. 2009. JPEG File Interchange Format (JFIF). http://www.ecma-international.org/publications/techreports/E-TR-098.htm .

[ETSI TS 102 366] ETSI. Feb. 2005. Audio Compression (AC-3, Enhanced AC-3) Standard.

[GBK] China National Information Technology Standardization Technical Committee. 1995. Chinese Internal Code Extension Specification.

[GB 2312] National Standard Administration of China. 1981. GB/T 2312 Simplified Chinese Characters Coding Specification.

[GB 18030] Standards Administration of China. Information Technology - Chinese Coded character set.

[IEEE 754] IEEE. 2019. IEEE Standard for Floating Point Arithmetic. http://dx.doi.org/10.1109/IEEESTD.2019.8766229 .

[ISO/IEC Directives, Part 2] ISO/IEC. 2021. 9.0. Rules for the structure and drafting of International Standards. http://www.iso.org/sites/directives/current/part2/index.xhtml .

[ISO 646] ISO. 1990. Information Processing - ISO 7-bit coded character set for information interchange.

[ISO/IEC 2022] ISO/IEC. 1994. Information technology - Character code structure and extension techniques.

[ISO 2375] ISO. 1986. Data Processing - Procedure for the registration of escape sequences.

[ISO/IEC 6429] ISO/IEC. 1990. Information Processing - Control functions for 7-bit and 8-bit coded character sets.

[ISO 6523] ISO. 1984. Data interchange - Structures for identification of organizations.

[ISO 7498] ISO. 1984. Information processing systems - Open System Interconnection - Basic Reference Model.

[ISO 7498-4] ISO. 1989. Information processing systems - Open Systems Interconnection - Part 4: Management Framework.

[ISO 8649] ISO. 1988. Information processing systems - Open Systems Interconnection - Service definition for the Association Control Service Element (ACSE).

[ISO 8822] ISO. 1988. Information processing systems - Open Systems Interconnection - Connection oriented presentation service definition.

[ISO/IEC 8824] ISO/IEC. 1990. Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1).

[ISO/IEC 8859] ISO/IEC. Information processing - 8-bit single-byte coded graphic character sets.

[ISO/IEC 8859-1] ISO/IEC. 1987. Information processing - 8-bit single-byte coded graphic character sets - Part 1: Latin alphabet No. 1.

[ISO/IEC 8859-2] ISO/IEC. 1987. Information processing - 8-bit single-byte coded graphic character sets - Part 2: Latin alphabet No. 2.

[ISO/IEC 8859-3] ISO/IEC. 1988. Information processing - 8-bit single-byte coded graphic character sets - Part 3: Latin alphabet No. 3.

[ISO/IEC 8859-4] ISO/IEC. 1988. Information processing - 8-bit single-byte coded graphic character sets - Part 4: Latin alphabet No. 4.

[ISO/IEC 8859-5] ISO/IEC. 1988. Information processing - 8-bit single-byte coded graphic character sets - Part 5: Latin/Cyrillic alphabet.

[ISO/IEC 8859-6] ISO/IEC. 1987. Information processing - 8-bit single-byte coded graphic character sets - Part 6: Latin/Arabic alphabet.

[ISO/IEC 8859-7] ISO/IEC. 1987. Information processing - 8-bit single-byte coded graphic character sets - Part 7: Latin/Greek alphabet.

[ISO/IEC 8859-8] ISO/IEC. 1988. Information processing - 8-bit single-byte coded graphic character sets - Part 8: Latin/Hebrew alphabet.

[ISO/IEC 8859-9] ISO/IEC. 1989. Information processing - 8-bit single-byte coded graphic character sets - Part 9: Latin alphabet No. 5.

[ISO/IEC 8859-15] ISO/IEC. 1999. Information technology — 8-bit single-byte coded graphic character sets — Part 15: Latin alphabet No. 9.

[ISO/IEC 9834-1] ISO/IEC. 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] ISO/IEC. 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] ISO/IEC. 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] ISO/IEC. 1994. JPEG Standard for digital compression and encoding of continuous-tone still images. Part 1 - Requirements and implementation guidelines.

[ISO/IEC 10918-2] ISO/IEC. 1995. JPEG Standard for digital compression and encoding of continuous-tone still images. Part 2 - Testing.

[ISO/IEC 10918-5] ISO/IEC. 2013. JPEG Standard for digital compression and encoding of continuous-tone still images. Part 5 - JPEG File Interchange Format (JFIF).

[ISO/IEC 11172-3] ISO/IEC. 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] ISO/IEC. 2000. Information technology -- Generic coding of moving pictures and associated audio information - Part 1: Systems.

[ISO/IEC 13818-2] ISO/IEC. 2000. Information technology -- Generic coding of moving pictures and associated audio information - Part 2: Video.

[ISO/IEC 13818-3] ISO/IEC. 1998. Information technology -- Generic coding of moving pictures and associated audio information - Part 3: Audio.

[ISO/IEC 13818-4] ISO/IEC. 1998. Information technology -- Generic coding of moving pictures and associated audio information - Part 4: Conformance testing.

[ISO/IEC 13818-7] ISO/IEC. 1997. Information technology -- Generic coding of moving pictures and associated audio information - Part 7: Advanced Audio Coding (AAC).

[ISO/IEC 14495-1] ISO/IEC. 1997. Lossless and near-lossless coding of continuous tone still images (JPEG-LS).

[ISO/IEC 14496-3] ISO/IEC. 2009. Information technology - Coding of audio-visual objects - Part 3: Audio.

[ISO/IEC 14496-10] ISO/IEC. 2009. Information technology - Coding of audio-visual objects - Part 10: Advanced Video Coding.

[ISO/IEC 14496-12] ISO/IEC. 2003. Information technology - Coding of audio-visual objects - Part 12: ISO base media file format.

[ISO/IEC 14496-14] ISO/IEC. 2003. Information technology - Coding of audio-visual objects - Part 14: MP4 file format.

[ISO 15076-1] ISO. 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-1] ISO/IEC. 2004. JPEG 2000 Image Coding System.

[ISO/IEC 15444-2] ISO/IEC. 2004. JPEG 2000 Image Coding System: Extensions.

[ISO/IEC 15444-9] ISO/IEC. 2005. Information technology - JPEG 2000 image coding system: Interactivity tools, APIs and protocols.

[ISO/IEC 15444-15] ISO/IEC. 2019. Information technology - JPEG 2000 image coding system — Part 15: High-Throughput JPEG 2000.

[ISO/IEC 18181-1] ISO/IEC. 2022. Information technology - JPEG XL Image Coding System - Part 1 Core Coding System.

[ISO/IEC 23008-2] ISO/IEC. 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] ITU. 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] ENV. 1990. Information systems interconnection - European graphic character repertoires and their coding.

[ENV 41 508] ENV. 1990. Information systems interconnection - East European graphic character repertoires and their coding.

[JIS X 0201] JIS. 1976. Code for Information Interchange.

[JIS X 0208] JIS. 1990. Code for the Japanese Graphic Character set for information interchange.

[JIS X 0212] JIS. 1990. Code of the supplementary Japanese Graphic Character set for information interchange.

[KS X 1001] KS. 1997. Code for Information Interchange (Hangul and Hanja).

[RFC1468] IETF. Japanese Character Encoding for Internet Messages. http://tools.ietf.org/html/rfc1468 .

[RFC1554] IETF. ISO-2022-JP-2: Multilingual Extension of ISO-2022-JP. http://tools.ietf.org/html/rfc1554 .

[RFC1951] IETF. DEFLATE Compressed Data Format Specification version 1.3. http://tools.ietf.org/html/rfc1951 .

[RFC3986] IETF. Uniform Resource Identifiers (URI) : Generic Syntax. http://tools.ietf.org/html/rfc3986 .

[RFC3987] IETF. Internationalized Resource Identifiers (IRIs). http://tools.ietf.org/html/rfc3987 .

[RFC5890] IETF. Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework. http://tools.ietf.org/html/rfc5890 .

[RFC5891] IETF. Internationalized Domain Names in Applications (IDNA): Protocol. http://tools.ietf.org/html/rfc5891 .

[SMPTE ST 2110-10] Society of Motion Picture and Television Engineers (SMPTE). 2017. Professional Media over IP Networks: System Timing and Definitions.

[SMPTE ST 2110-20] Society of Motion Picture and Television Engineers (SMPTE). 2017. Professional Media over IP Networks: Uncompressed Active Video.

[SMPTE ST 2110-30] Society of Motion Picture and Television Engineers (SMPTE). 2017. Professional Media over IP Networks: PCM Digital Audio.

[TIS 620-2533] Thai Industrial Standards Institute. 1990. Thai Characters Code for Information Interchange. http://www.nectec.or.th/it-standards/std620/std620.html .

3 Definitions

Для целей настоящего Стандарта применяются следующие определения.

3.1 Определения эталонной модели

В настоящей части Стандарта используются следующие термины, определённые в [ISO 7498]:

Application Entity: См. [ISO 7498].
OSI Presentation Protocol: См. [ISO 7498].

3.2 Определения служб ACSE

В настоящей части Стандарта используются следующие термины, определённые в [ISO 8649]:

Association: См. [ISO 8649].

3.3 Определения служб представления

В настоящей части Стандарта используются следующие термины, определённые в [ISO 8822]:

Presentation Context: См. [ISO 8822].
Presentation Data Value (PDV): См. [ISO 8822].
Transfer Syntax: См. [ISO 8822].
Transfer Syntax Name: См. [ISO 8822].

3.4 Определения идентификации объектов

В настоящей части Стандарта используются следующие термины, определённые в [ISO/IEC 8824]:

OSI Object Identification: См. [ISO/IEC 8824].

3.5 Определения введения и обзора DICOM

В настоящей части Стандарта используются следующие термины, определённые в PS3.1:

Attribute: См. Attribute в PS3.1 .
Command Element: См. Command Element в PS3.1 .
Data Dictionary: См. Data Dictionary в PS3.1 .
Service-Object Pair Class (SOP Class): См. Service-Object Pair Class в PS3.1

3.6 Определения соответствия DICOM

В настоящей части Стандарта используются следующие термины, определённые в PS3.2:

Conformance Statement: См. Conformance Statement в PS3.2 .

3.7 Определения информационных объектов DICOM

В настоящей части Стандарта используются следующие термины, определённые в PS3.3:

Attribute Tag: См. Attribute Tag в PS3.3 .
Frame: См. Frame в PS3.3 .
Information Entity: См. Information Entity в PS3.3 .
Information Object Definition (IOD): См. Information Object Definition в PS3.3 .
Multi-frame Image: См. Multi-frame Image в PS3.3 .

3.8 Определения спецификаций классов служб DICOM

В настоящей части Стандарта используются следующие термины, определённые в PS3.4:

Service-Object Pair Instance (SOP Instance): См. Service-Object Pair Instance в PS3.4

3.9 Определения поддержки сетевого обмена сообщениями DICOM

В настоящей части Стандарта используются следующие термины, определённые в PS3.8:

DICOM Upper Layer Service: См. DICOM Upper Layer Service в PS3.8 .

3.10 Определения структур данных и кодирования DICOM

Следующие определения обычно используются в настоящем Стандарте:

Basic Offset Table (BOT): Таблица 32-битных указателей на отдельные Frame инкапсулированного Multi-frame Image.
Big Endian: Форма порядка байтов, при которой многобайтовые бинарные значения кодируются старшим байтом первым, а остальные байты — в порядке убывания значимости.
Character Repertoire: Конечный набор различных символов, который считается полным для заданной цели и специфицируется независимо от их кодирования (также называется набором символов).
Code String: Строка символов, идентифицирующая контролируемое понятие, включая Defined Term и Enumerated Value, когда они представлены в виде строк символов. Область контролируемого понятия ограничена Attribute, для которого строка предоставляет Value; иными словами, Attribute определяет допустимый набор Value для Code String, и конкретная строка может иметь разные значения в разных Attribute. Code String формально является произвольным кодом, представляющим семантическое понятие; однако английские слова (с использованием ограниченного набора символов CS Value Representation) часто используются в качестве кодов для семантики этих слов.
Data Element: Единица информации, определённая одной записью в словаре данных. Кодированный Attribute Information Object Definition (IOD), состоящий как минимум из трёх полей: Data Element Tag, Value Length и Value Field. Для некоторых конкретных Transfer Syntax, Data Element также содержит VR Field, где Value Representation данного Data Element указывается явно.
Data Element Tag: Уникальный идентификатор Data Element, состоящий из упорядоченной пары чисел (Group Number, за которым следует Element Number).
Data Element Tag Field: Поле в структуре Data Element, содержащее Data Element Tag.
Data Element Type: Используется для указания, является ли Attribute Information Object Definition или Attribute SOP Class Definition обязательным, обязательным только при определённых условиях или необязательным. Это определяет, является ли Data Element в Data Set обязательным, обязательным только при определённых условиях или необязательным.
Data Set: Обмениваемая информация, представляющая собой структурированный набор значений Attribute, прямо или косвенно связанных с Information Object. Значение каждого Attribute в Data Set выражается как Data Element. Совокупность Data Element, упорядоченных по возрастанию номера Data Element Tag, представляющая собой кодирование значений Attribute реального объекта.
Default Character Repertoire: Базовый набор G0 из International Reference Version стандарта [ISO 646] (ISO-IR 6), используемый как набор символов по умолчанию для строк символов в DICOM.
Defined Term: Значение Data Element является Defined Term, когда Value Data Element может быть одним из явно заданного набора стандартных Value, и эти Value могут быть расширены разработчиками.
Element Number: Второе число в упорядоченной паре чисел, составляющих Data Element Tag.
Encapsulated Format: Pixel Data Stream кодируется в форме, при которой Fragment содержатся внутри Item Tag в Data Element Pixel Data (7FE0,0010), обычно используется для сжатых данных.
Enumerated Value: Значение Data Element является Enumerated Value, когда Value Data Element должно быть одним из явно заданного набора стандартных Value, и эти Value не должны расширяться разработчиками.
Explicit VR: Кодирование структуры Data Element, при котором Value Representation данного Data Element указывается явно в Value Representation Field.
Extended Offset Table (EOT): Таблица 64-битных указателей на отдельные Frame инкапсулированного Multi-frame Image.
Fragment: Одна часть или весь Pixel Data Stream, кодированный внутри Encapsulated Pixel Data.
Fragmentable Encapsulated Transfer Syntax: Transfer Syntax, позволяющий разделить Encapsulated Format Pixel Data Stream на один или несколько Fragment.
Group Number: Первое число в упорядоченной паре чисел, составляющих Data Element Tag.
Implicit VR: Кодирование структуры Data Element, при котором Value Representation данного Data Element указывается неявно, т.е. не в Value Representation Field. Данное кодирование используется для DICOM Default Little Endian Transfer Syntax (см. Section 10.1).
Item: Компонент Value Data Element, имеющего Value Representation Sequence of Items. Item содержит Data Set.
Item Delimitation Data Element: Используется для отметки конца Item с Undefined Length в Sequence of Items. Это последний Data Element в Item с Undefined Length.
Little Endian: Форма порядка байтов, при которой многобайтовые бинарные значения кодируются младшим байтом первым, а остальные байты — в порядке возрастания значимости.
Native Format: Pixel Data Stream кодируется в несжатой форме и занимает всё значение Data Element Pixel Data (7FE0,0010).
Nested Data Set: Data Set, содержащийся внутри Data Element другого Data Set. Data Set могут быть вложены рекурсивно. Только Data Element с Value Representation Sequence of Items могут сами содержать Data Set.
Non-Fragmentable Encapsulated Transfer Syntax: Transfer Syntax, требующий, чтобы весь Encapsulated Format Pixel Data Stream был закодирован в одном Fragment.
Pixel Cell: Контейнер для одного Pixel Sample Value, который может включать неиспользуемые биты. Размер Pixel Cell должен указываться Data Element Bits Allocated (0028, 0100).
Pixel Data: Графические данные (например, изображения) переменной пиксельной глубины, закодированные в Data Element Pixel Data, Float Pixel Data или Double Float Pixel Data.
Pixel Data Stream: Сжатый или несжатый поток октетов, составляющий сами Pixel Data без каких-либо специфичных для DICOM структур инкапсуляции.
Pixel Sample Value: Значение, связанное с отдельным пикселем. Отдельный пиксель состоит из одного или нескольких Pixel Sample Value (например, цветные изображения).
Private Data Element: Дополнительный Data Element, определённый разработчиком для передачи информации, не содержащейся в Standard Data Element. Private Data Element имеют нечётные Group Number.
QUOTATION MARK: Символ 22H в Default Character Repertoire.
Repeating Group: Standard Data Element в определённом диапазоне Group Number, где Data Element с одинаковыми Element Number имеют одинаковое значение в каждой Group (а также одинаковые VR, VM и Data Element Type). Repeating Group существуют только для Overlay Plane (Group Number 60xx) и являются пережитком старых версий настоящего Стандарта.

Примечание

Repeating Group также использовались для Curve, которые были ранее определены, но удалены. См. PS3.5-2004.
Retired Data Element: Data Element, который не поддерживается начиная с текущей версии Стандарта. Реализации могут продолжать поддерживать Retired Data Element для целей обратной совместимости, но это не является требованием текущего Стандарта.
Sequence Delimitation Item: Item, используемый для отметки конца Sequence of Items с Undefined Length. Этот Item является последним Item в Sequence of Items с Undefined Length.
Sequence of Items: Value Representation для Data Element, которые содержат последовательность Data Set. Sequence of Items допускает Nested Data Set.
Standard Data Element: Data Element, определённый в стандарте DICOM и, следовательно, перечисленный в DICOM Data Element Dictionary в PS3.6.
DICOM Transfer Syntax: Набор правил кодирования, позволяющий DICOM Application Entity однозначно согласовать методы кодирования (например, структуру Data Element, порядок байтов, сжатие), которые они способны поддерживать, тем самым позволяя этим Application Entity обмениваться данными. См. также Transfer Syntax.
Undefined Length: Возможность указать неизвестную длину для Value Data Element (с Value Representation SQ, UN или OB) или Item. Data Element и Item с Undefined Length ограничиваются Sequence Delimitation Item и Item Delimitation Data Element соответственно.
Unique Identifier (UID): Строка символов, используемая для обеспечения глобальной уникальной идентификации широкого спектра объектов, гарантирующая уникальность в разных странах, на разных сайтах, у разных производителей и оборудования. Она использует структуру, определённую [ISO/IEC 8824] для OSI Object Identifier.
Value: Компонент Value Field. Value Field может состоять из одного или нескольких таких компонентов.
Value Field: Поле в структуре Data Element, содержащее Value данного Data Element.
Value Length: Длина Value Field данного Data Element.
Value Length Field: Поле в структуре Data Element, содержащее Value Length.
Value Multiplicity (VM): Указывает количество Value, содержащихся в Value Field Data Element.
Value Representation (VR): Указывает тип данных и формат Value, содержащихся в Value Field Data Element.
Value Representation (VR) Field: Поле, в котором Value Representation Data Element хранится при кодировании структуры Data Element с Explicit VR.

3.11 Определения обработки символов

В настоящей части Стандарта используются следующие термины, определённые в [ISO/IEC 2022]

Coded Character Set: См. [ISO/IEC 2022].
Code Extension: См. [ISO/IEC 2022].
Control Character: См. [ISO/IEC 2022].
To Designate: См. [ISO/IEC 2022].
Escape Sequence: См. [ISO/IEC 2022].
Graphic Character: См. [ISO/IEC 2022].
To Invoke: См. [ISO/IEC 2022].

4 Символы и сокращения

Следующие символы и сокращения используются в настоящей части Стандарта.

ACR: Американский колледж радиологии
AE: Application Entity
ANSI: Американский национальный институт стандартов
AVC: Advanced Video Coding
CEN TC251: Comité Européen de Normalisation - Технический комитет 251 — Медицинская информатика
DICOM: Цифровая визуализация и коммуникации в медицине
HEVC: Высокопроизводительное видеокодирование
HISPP: Плановая панель по стандартам медицинской информации
HL7: Стандарты интерфейса отрасли здравоохранения уровня 7
IEEE: Институт инженеров электротехники и электроники
IOD: Information Object Definition
ISO: Международная организация по стандартизации
JPEG: Объединённая группа экспертов по фотографии
JIRA: Японская ассоциация производителей медицинских систем визуализации и радиологических систем
MPEG: Группа экспертов по движущимся изображениям
MSDS: Подкомитет разработчиков стандартов медицинских сообщений
NEMA: Национальная ассоциация производителей электрооборудования
OSI: Взаимодействие открытых систем
RLE: Кодирование длин серий
TCP/IP: Протокол управления передачей/Интернет-протокол
UID: Unique Identifier
SOP: Service-Object Pair
UTC: Координированное всемирное время
URI/URL: Унифицированный идентификатор/локатор ресурса
VM: Value Multiplicity
VR: Value Representation

5 Соглашения

Слова в данном документе пишутся с заглавной буквы (не заголовки), чтобы помочь читателю понять, что эти слова были ранее определены в Section 3 данного документа и должны толковаться в этом значении.

Data Element Tag представляется как (gggg,eeee), где gggg соответствует Group Number, а eeee соответствует Element Number в этой Group. Data Element Tag представляется в шестнадцатеричной нотации, как указано для каждого Data Element в PS3.6.

Нотация XXXXH, где XXXX — одна или несколько шестнадцатеричных цифр, а «H» используется для обозначения шестнадцатеричного числа.

6 Value Encoding

Набор данных (Data Set) создаётся путём кодирования Значений Атрибутов, определённых в Определении объекта информации (IOD) реального объекта. Конкретное содержимое и семантика этих Атрибутов определяются в Определениях объектов информации (см. PS3.3). Диапазон возможных типов данных этих Значений и их кодирование описываются в данном разделе. Структура Набора данных, состоящего из Элементов данных, содержащих эти Значения, описана в Разделе 7.

На протяжении всей данной части, а также других частей стандарта DICOM, Теги используются для идентификации как конкретных Атрибутов, так и соответствующих им Элементов данных.

6.1 Поддержка репертуаров символов

Значения, представляющие собой текст или строки символов, могут состоять из графических и управляющих символов. Набор графических символов, независимо от его кодирования, называется репертуаром символов (Character Repertoire). В зависимости от языкового контекста, в котором прикладные сущности (Application Entities) желают обмениваться данными с использованием стандарта DICOM, будут использоваться различные репертуары символов. Репертуары символов, поддерживаемые DICOM, включают:

[ISO/IEC 8859] 8-битные однобайтные кодируемые наборы графических символов
[JIS X 0201] Код для обмена информацией
[JIS X 0208] Код набора японских графических символов для обмена информацией
[JIS X 0212] Код дополнительного набора японских графических символов для обмена информацией
[KS X 1001] (зарегистрирован как ISO-IR 149) для корейского языка
[TIS 620-2533] Код тайских символов для обмена информацией
[ISO/IEC 10646] для набора символов Unicode
[GB 18030]
[GB 2312]
[GBK]

Примечание

[ISO/IEC 10646] соответствует набору символов Unicode. ISO IR 192 соответствует использованию кодировки UTF-8 для данного набора символов.
Набор символов [GB 18030] регулярно согласуется с набором символов Unicode для отражения обновлений как китайского языка, так и расширений Unicode для поддержки других языков.
Вопрос выбора шрифтов не рассматривается в стандарте DICOM. Такие вопросы, как корректное отображение слов, например «bone» при использовании китайского или японского языка, решаются посредством выбора шрифта. Аналогичным образом, другие вопросы пользовательского интерфейса, такие как двунаправленное отображение символов и ориентация текста, не рассматриваются стандартом DICOM. Документы Unicode содержат обширную документацию по этим вопросам.
Набор символов [GBK] является расширением набора символов [GB 2312] и поддерживает китайские символы из [GB 18030], который является китайской адаптацией Unicode. [GBK] обратно совместим по кодовым точкам с [GB 2312]. Набор символов [GB 18030] является расширением набора символов [GBK] для поддержки Unicode и обеспечивает обратную совместимость по кодовым точкам.

6.1.1 Представление закодированных символьных значений

Как определено в стандартах ISO, указанных в данном разделе, значения байтов, используемые для кодированного представления символов, представлены в данном разделе в виде двух десятичных чисел в формате столбец/строка.

Это означает, что значение может быть вычислено как (столбец * 16) + строка, например, 01/11 соответствует значению 27 (1BH).

Примечание

Шестнадцатеричная запись из двух цифр будет использоваться далее по всему стандарту для представления кодирования символов. Нотация столбец/строка используется только в Разделе 6.1 для упрощения перекрёстных ссылок на применимые стандарты ISO.

Пространство кодирования байтов разделено на четыре диапазона значений:

CL — байты от 00/00 до 01/15
GL — байты от 02/00 до 07/15
CR — байты от 08/00 до 09/15
GR — байты от 10/00 до 15/15

Примечание

[ISO/IEC 8859] не различает элемент кода (например, G0) и область в таблице кодов (например, GL), где он активирован. Термин «G0» обозначает как элемент кода, так и область в таблице кодов. В ISO/IEC 2022 проводится чёткое различие между элементами кода (G0, G1, G2 и G3) и областями, в которых эти элементы активированы (GL или GR). В данном стандарте используется номенклатура ISO/IEC 2022.

Набор управляющих символов C0 должен быть активирован в CL, а наборы графических символов G0 и G1 — в GL и GR соответственно. В DICOM используется лишь некоторое подмножество управляющих символов из набора C0 (см. Раздел 6.1.3), а символы из набора C1 не должны использоваться.

6.1.2 Графические символы

Репертуар символов, или набор символов, представляет собой совокупность графических символов, определённых независимо от их кодирования.

6.1.2.1 Репертуар символов по умолчанию

Репертуаром по умолчанию для строк символов в DICOM должен быть базовый набор G0 Международной справочной версии [ISO 646] (ISO-IR 6). Таблица репертуара символов DICOM по умолчанию и его кодирования приведена в Приложении E.

Примечание

Данный базовый набор G0 идентичен общему набору символов [ISO/IEC 8859].

6.1.2.2 Расширение или замена репертуара символов по умолчанию

Прикладные сущности DICOM (Application Entities, AE), которые расширяют или заменяют репертуар по умолчанию, сообщают эту информацию в атрибуте Specific Character Set (0008,0005).

Примечание

Атрибут Specific Character Set (0008,0005) кодируется с использованием подмножества символов из ISO-IR 6. См. определение для представления значения (VR) Code String (CS) в Таблице 6.2-1.

Для элементов данных с представлениями значений SH (Short String), LO (Long String), UC (Unlimited Characters), ST (Short Text), LT (Long Text), UT (Unlimited Text) или PN (Person Name) репертуар символов по умолчанию может быть расширен или заменён (эти представления значений описаны более подробно в Разделе 6.2). Если такое расширение или замена используется, соответствующий «Specific Character Set» должен быть определён как атрибут модуля SOP Common (0008,0005) (см. PS3.3) и должен быть указан в заявлении о соответствии. В PS3.2 приведены руководящие принципы соответствия.

Примечание

Предпочтительные репертуары, определённые в ENV 41 503 и ENV 41 508 для использования в Западной и Восточной Европе соответственно: ISO-IR 100, ISO-IR 101, ISO-IR 144, ISO-IR 126. См. Раздел 6.1.2.3.
Определения объектов информации, использующие различные наборы символов, не могут сами по себе полагаться на лексикографическое упорядочение или сравнение строк элементов данных, представленных как строки символов. Эти операции могут выполняться только в пределах заданного репертуара символов, а не через границы репертуаров.

6.1.2.3 Кодирование репертуаров символов

7-битный репертуар символов по умолчанию может быть заменён для использования в представлениях значений SH, LO, ST, LT, PN, UC и UT одним из однобайтных кодов, определённых в PS3.3.

Примечание

Этот заменяющий репертуар символов не применяется к другим текстовым представлениям значений (AE и CS).

Заменяющий репертуар символов должен быть указан в Значении 1 атрибута Specific Character Set (0008,0005). Определённые термины (Defined Terms) для атрибута Specific Character Set приведены в PS3.3.

Примечание

Таблица кодов разделена на область GL, которая поддерживает только 94-символьный набор (битовые комбинации с 02/01 по 07/14) плюс SPACE в позиции 02/00, и область GR, которая поддерживает либо 94-, либо 96-символьный набор (битовые комбинации с 10/01 по 15/14 или с 10/00 по 15/15). Набор символов по умолчанию (ISO-IR 6) всегда активирован в области GL.
Все наборы символов, указанные в [ISO/IEC 8859], включают ISO-IR 6. Этот набор всегда активирован в области GL таблицы кодов и эквивалентен ASCII ([ANSI X3.4]), тогда как различные расширяющие репертуары отображаются в область GR таблицы кодов.
8-битная таблица кодов [JIS X 0201] включает ISO-IR 14 (ромадзи — буквенно-цифровые символы) в качестве элемента кода G0 и ISO-IR 13 (катакана — фонетические символы) в качестве элемента кода G1. ISO-IR 14 идентичен ISO-IR 6, за исключением того, что битовая комбинация 05/12 представляет «¥» (YEN SIGN), а битовая комбинация 07/14 представляет надчёркивание.

Два символьных кода однобайтных наборов символов, активированных в области GL таблицы кодов — 02/00 и 05/12 — имеют особое значение в стандарте DICOM. Символ SPACE, представленный битовой комбинацией 02/00, должен использоваться для заполнения (padding) значений элементов данных, представляющих собой строки символов. Графический символ, представленный битовой комбинацией 05/12 — «\» (BACKSLASH, обратная косая черта) в репертуаре ISO-IR 6 — должен использоваться в строках символов только с представлениями значений UT, ST и LT (см. Раздел 6.2). В остальных случаях символьный код 05/12 используется как разделитель многозначных элементов данных (см. Раздел 6.4).

Примечание

Если значение атрибута Specific Character Set (0008,0005) равно «ISO_IR 13» или «ISO 2022 IR 13», графический символ, представленный битовой комбинацией 05/12, — это «¥» (YEN SIGN) в наборе символов ISO-IR 14.
Ожидаемое поведение при преобразовании в процессе операций «сохранить и переслать» (store-and-forward) должно быть эквивалентно действию разделения многозначного символьного потока для многозначных VR на отдельные значения по байтовым разделителям 05/12 и повторному их объединению, разделённым байтами 05/12, независимо от того, какой графический символ представляет 05/12 в соответствующем наборе символов.
Графические символы, совпадающие с разделителем, указанным для набора символов для многозначных VR, не могут быть представлены как значения в этом наборе символов. Т. е. BACKSLASH, закодированный как 05/12, не может присутствовать внутри значения (в отличие от разделения значений) в репертуаре символов по умолчанию, а YEN SIGN, закодированный как 05/12, не может присутствовать внутри значения в [JIS X 0201].

Символ DELETE (битовая комбинация 07/15) не должен использоваться в строках символов DICOM.

Заменяющий репертуар символов, указанный в Значении 1 атрибута Specific Character Set (0008,0005) (или репертуар символов по умолчанию, если Значение 1 пустое), может быть дополнительно расширен дополнительными кодируемыми наборами символов, если это необходимо и допускается заменяющим репертуаром символов. Дополнительные кодируемые наборы символов и механизм расширения должны быть указаны в дополнительных значениях атрибута Specific Character Set. Если атрибут Specific Character Set (0008,0005) имеет единственное значение, экземпляр SOP DICOM поддерживает только одну таблицу кодов и не поддерживает методы расширения кода. Если атрибут Specific Character Set (0008,0005) имеет несколько значений, экземпляр SOP DICOM поддерживает методы расширения кода, описанные в ISO/IEC 2022:1994.

Репертуары символов, для которых запрещено расширение, перечислены в PS3.3.

Примечание

Соображения по обработке неподдерживаемых наборов символов:

В DICOM наборы символов не согласовываются между прикладными сущностями, а указываются условным атрибутом модуля SOP Common. Поэтому реализации могут столкнуться с наборами символов, которые им неизвестны.

Стандарт Unicode содержит подробное обсуждение рекомендуемых способов отображения и печати символов, для которых отсутствует поддержка шрифтов. Эти же рекомендации могут применяться к механизмам для неподдерживаемых наборов символов.

Машина должна печатать или отображать такие символы путём замены всех неизвестных символов четырьмя символами «\nnn», где «nnn» — трёхзначное восьмеричное представление каждого байта.

Пример для машины на базе ASCII:

Строка символов: Günther

Кодированное представление: 04/07 15/12 06/14 07/04 06/08 06/05 07/02

Машина на базе ASCII: G\374nther

Реализации также могут встретить управляющие символы, которые они не имеют средств для печати или отображения. Машина может печатать или отображать такие управляющие символы путём замены управляющего символа четырьмя символами «\nnn», где «nnn» — трёхзначное восьмеричное представление каждого байта.
Соображения по отсутствующим шрифтам

Стандарт Unicode и стандарт [GB 18030] определяют механизмы печати и отображения символов, отсутствующих в доступных шрифтах. Если в Specific Character Set (0008,0005) указано значение GBK, применяются правила [GB 18030] для печати и отображения символов. Стандарт DICOM не определяет поведение пользовательского интерфейса, поскольку оно не влияет на сетевой обмен данными или обмен данными на носителях.
Стандарты Unicode и [GB 18030] содержат различные символы YEN SIGN, BACKSLASH и несколько форм обратной косой черты. Разделителем для многозначных элементов данных в DICOM является символ со значением 05/12, независимо от того, какой глиф используется для ввода или отображения этого символа. Другие символы обратной косой черты, имеющие очень похожий внешний вид, разделителями не являются. Выбор шрифта может существенно влиять на отображение символа 05/12. Системы многобайтного кодирования, такие как [GB 18030], [GBK] и [ISO/IEC 2022], могут создавать кодировки, содержащие байт со значением 05/12. Разделителем является только символ, который кодируется одним байтом со значением 05/12.

Для многозначных элементов данных существующие реализации, рассчитанные только на однобайтные заменяющие наборы символов, могут неверно интерпретировать кратность значения (Value Multiplicity) элемента данных в результате интерпретации байтов 05/12 в многобайтных символах или escape-последовательностей [ISO/IEC 2022] как разделителей, что может повлиять на целостность операций «сохранить и переслать». Приложения, в заявлении о соответствии которых явно не указана поддержка [GB 18030], [GBK] или [ISO/IEC 2022], могут демонстрировать такое поведение.

6.1.2.4 Методы расширения кода

Для элементов данных с представлениями значений SH (Short String), LO (Long String), UC (Unlimited Characters), ST (Short Text), LT (Long Text), UT (Unlimited Text) или PN (Person Name) репертуар символов по умолчанию или репертуар символов, указанный в Значении 1 атрибута Specific Character Set (0008,0005), может быть расширен с использованием методов расширения кода, определённых в ISO/IEC 2022:1994.

Если такие методы расширения кода используются, соответствующий набор или наборы Specific Character Set должны быть указаны в значениях со 2-го по n-й атрибута Specific Character Set (0008,0005) модуля SOP Common (см. PS3.3) и должны быть отражены в заявлении о соответствии.

Примечание

Определённые термины для Specific Character Set (0008,0005) приведены в PS3.3.
Поддержка японских иероглифов (кандзи — идеографические), хираганы (фонетические), катаканы (фонетические), корейских символов (хангыль — фонетические и ханча — идеографические) и китайских символов определена в PS3.3.
Китайский набор символов (GB18030) и Unicode [ISO/IEC 10646] не допускают использования методов расширения кода. Если используется любой из этих наборов символов, никакой другой набор символов не может быть указан в атрибуте Specific Character Set (0008,0005), то есть он может иметь только одно значение.

6.1.2.5 Использование расширения кода

DICOM поддерживает методы расширения кода, если атрибут Specific Character Set (0008,0005) является многозначным. Метод, используемый для расширения кода в DICOM, описан в ISO/IEC 2022:1994. Должны быть сделаны следующие допущения и применены следующие ограничения:

6.1.2.5.1 Предполагаемые начальные состояния

Элементы кода G0 и G1 (только в 8-битном режиме) всегда активированы в областях GL и GR таблицы кодов соответственно. Назначенные наборы символов для этих элементов кода немедленно вступают в силу. Элементы кода G2 и G3 не используются.
Первичный набор управляющих символов всегда должен быть назначен как элемент кода C0 и должен быть активирован в области CL таблицы кодов. Элемент кода C1 не должен использоваться.

6.1.2.5.2 Ограничения для расширения кода

Поскольку элементы кода G0 и G1 всегда имеют статус сдвига, блокирующие сдвиги (Locking Shifts, SI, SO) не требуются и не должны использоваться.
Поскольку элементы кода G2 и G3 не используются, одиночные сдвиги (Single Shifts, SS2 и SS3) не могут использоваться.
Для активации элементов кода должны использоваться только ESC-последовательности, указанные в PS3.3.

6.1.2.5.3 Требования

Набор символов, указанный в Значении 1 атрибута Specific Character Set (0008,0005), или репертуар символов по умолчанию (если Значение 1 отсутствует), должен быть активным в начале каждого текстового значения элемента данных, а также в начале каждой строки (т. е. после CR и/или LF) или страницы (т. е. после FF).

Если в пределах текстового значения был активирован набор символов, отличный от указанного в Значении 1 атрибута Specific Character Set (0008,0005), или репертуара символов по умолчанию (если Значение 1 отсутствует), набор символов, указанный в Значении 1, или репертуар символов по умолчанию (если Значение 1 отсутствует), должен быть активным в следующих случаях:

перед концом строки (т. е. перед CR и/или LF)
перед концом страницы (т. е. перед FF)
перед любым другим управляющим символом, кроме ESC (например, перед любым TAB)
перед концом значения элемента данных (например, перед символьным кодом 05/12, который разделяет множественные текстовые значения элементов данных — 05/12 соответствует «\» (BACKSLASH) в случае репертуара по умолчанию IR-6 или «¥» (YEN SIGN) в случае IR-14).
перед разделителями «^» и «=», разделяющими компоненты имени и группы компонентов имени в элементах данных с VR типа PN.

Если в пределах текстового значения используется набор символов, отличный от указанного в Значении 1 атрибута Specific Character Set (0008,0005), или репертуара символов по умолчанию (если Значение 1 отсутствует), escape-последовательность этого набора символов должна быть явно вставлена в следующих случаях:

перед первым использованием набора символов в строке
перед первым использованием набора символов на странице
перед первым использованием набора символов в значении элемента данных
перед первым использованием набора символов в компоненте имени и группе компонентов имени в элементе данных с VR типа PN

Примечание

Эти требования позволяют приложению пропускать строки, значения или компоненты в текстовом элементе данных и начинать новую строку с определённым набором символов без необходимости отслеживать изменения набора символов в пропущенном тексте. Аналогичное ограничение содержится в RFC, описывающих использование многобайтных наборов символов в Интернете. Escape-последовательность переключения на Значение 1 или набор символов Specific Character Set по умолчанию не требуется внутри строки, значения или компонента, если в них отсутствуют расширения кода. Также не требуется переключение на Значение 1 или набор символов Specific Character Set по умолчанию, если этот набор символов имеет только определённый элемент кода G0, и элемент кода G0 всё ещё активен.

6.1.2.5.4 Уровни реализации и начальное назначение

Атрибут Specific Character Set (0008,0005) отсутствует:
- 7-битный код
- Уровень реализации: [ISO/IEC 2022] Уровень 1 — Элементарный 7-битный код (идентификатор уровня кода 1)
- Начальное назначение: ISO-IR 6 (ASCII) как G0.
- Расширение кода не должно использоваться.
Атрибут Specific Character Set (0008,0005) с единственным значением, отличным от «ISO_IR 192», «GB18030» или «GBK»:
- 8-битный код
- Уровень реализации: [ISO/IEC 2022] Уровень 1 — Элементарный 8-битный код (идентификатор уровня кода 11)
- Начальное назначение: Один из определённых наборов символов [ISO/IEC 8859], 8-битная таблица кодов [TIS 620-2533], или 8-битная таблица кодов [JIS X 0201], указанный в Значении 1 атрибута Specific Character Set (0008,0005), как G0 и G1.
- Расширение кода не должно использоваться.
Атрибут Specific Character Set (0008,0005) — многозначный:
- 8-битный код
- Уровень реализации: [ISO/IEC 2022] Уровень 4 — Переназначение наборов графических символов в коде (идентификатор уровня кода 14)
- Начальное назначение: Один из определённых наборов символов [ISO/IEC 8859], 8-битная таблица кодов [TIS 620-2533], или 8-битная таблица кодов [JIS X 0201], указанный в Значении 1 атрибута Specific Character Set (0008,0005), как G0 и G1. Если Значение 1 атрибута Specific Character Set (0008,0005) пустое, в качестве G0 принимается ISO-IR 6 (ASCII), а G1 — неопределён.
- Все наборы символов, указанные в различных значениях атрибута Specific Character Set (0008,0005), включая Значение 1, могут участвовать в расширении кода.
Атрибут Specific Character Set (0008,0005) с единственным значением «ISO_IR 192», «GB18030» или «GBK»:
- код переменной длины
- Уровень реализации: не указан (не совместим с [ISO/IEC 2022])
- Начальное назначение: как указано в Значении 1 атрибута Specific Character Set (0008,0005)
- Расширение кода не должно использоваться.

6.1.3 Управляющие символы

Текстовые данные, которые передаются при обмене, могут требовать некоторой информации о форматировании. Управляющие символы используются для указания форматирования, однако их использование в DICOM сведено к минимуму, поскольку некоторые машины могут обрабатывать их некорректно. [ISO 646] и ISO 6429:1990 определяют управляющие символы. Как показано в Таблице 6.1-1 ниже, только подмножество из пяти управляющих символов из набора C0 должно использоваться в DICOM для кодирования управляющих символов в текстовых строках.

Таблица 6.1-1. Управляющие символы DICOM и их кодирование

Акроним	Название	Кодированное значение
LF	Перевод строки (Line Feed)	00/10
FF	Перевод страницы (Form Feed)	00/12
CR	Возврат каретки (Carriage Return)	00/13
ESC	Escape	01/11
TAB	Горизонтальная табуляция (Horizontal Tab)	00/09

Символ ESC должен использоваться только для управляющих последовательностей набора символов [ISO/IEC 2022] в соответствии с Разделом 6.1.2.5.

В текстовых строках (представление значения ST, LT или UT) новая строка должна быть представлена как CR LF.

Примечание

Некоторые машины (например, машины на базе UNIX) могут интерпретировать LF (00/10) как новую строку. В таких случаях ожидается, что формат DICOM преобразуется в корректное внутреннее представление для данной машины.
В предыдущих редакциях стандарта (см. PS3.5-2015a) символ TAB не был указан как управляющий символ.

6.2 Представление значения (VR)

Представление значения (VR) элемента данных описывает тип данных и формат значения (значений) этого элемента данных. В PS3.6 приведён VR каждого элемента данных по тегу элемента данных.

Значения с VR, состоящими из строк символов, за исключением случая VR UI, должны быть дополнены символами SPACE (20H, в репертуаре символов по умолчанию) при необходимости достижения чётной длины. Значения с VR UI должны быть дополнены одним завершающим символом NULL (00H) при необходимости достижения чётной длины. Значения с VR OB должны быть дополнены одним завершающим нулевым байтом (00H) при необходимости достижения чётной длины.

Все новые VR, определённые в будущих версиях DICOM, должны иметь ту же структуру элемента данных, что определена в Разделе 7.1.2, с зарезервированными байтами после VR и 32-битным целочисленным беззнаковым VL (т.е. следуя формату для таких VR, как OB или UT), и могут как разрешать, так и не разрешать неопределённую длину.

Примечание

Поскольку все новые VR будут определены так, как указано в Разделе 7.1.2, реализация может проигнорировать нераспознанные VR, применив правила, изложенные в Разделе 7.1.2.
При преобразовании набора данных из синтаксиса передачи с явным VR в другой синтаксис передачи реализация может копировать элементы данных с нераспознанными VR следующим образом:
- Если порядок байтов в синтаксисах передачи одинаков, значение элемента данных может быть скопировано без изменений, и если целевой синтаксис передачи использует явный VR, байты VR копируются без изменений. На практике это применимо только к синтаксисам передачи с прямым порядком байтов (Little Endian), поскольку был определён только один синтаксис передачи с обратным порядком байтов (Big Endian).
- Если исходный синтаксис передачи использует прямой порядок байтов (Little Endian), а целевой синтаксис передачи — (устаревший) синтаксис передачи с явным VR и обратным порядком байтов (Big Endian), то значение элемента данных может быть скопировано без изменений, а VR изменён на UN, поскольку в случае нераспознанного VR неизвестно, требуется ли перестановка байтов. Если бы VR был скопирован без изменений, порядок байтов значения мог бы быть как правильным, так и неправильным.
- Если исходный синтаксис передачи — (устаревший) синтаксис передачи с явным VR и обратным порядком байтов (Big Endian), то элемент данных не может быть скопирован, поскольку неизвестно, требуется ли перестановка байтов, и не существует эквивалента VR UN для использования, когда значение представлено в обратном порядке байтов, а не в прямом.
Вопросы о том, может ли элемент данных быть скопирован и какой VR использовать при копировании, не возникают при преобразовании набора данных из синтаксиса передачи с неявным VR и прямым порядком байтов (Implicit VR Little Endian), поскольку VR не присутствует и не может быть нераспознанным, а если VR элемента данных неизвестен из словаря данных, то используется UN.

Отдельное значение, включая дополнение, не должно превышать длину значения, за исключением последнего значения многозначного поля, как указано в Разделе 6.4.

Примечание

Длины представлений значений, для которых репертуар символов может быть расширен или заменён, явно указаны в символах, а не в байтах, в Таблице 6.2-1. Это связано с тем, что сопоставление символа с количеством байтов, используемых для кодирования этого символа, может зависеть от используемого набора символов.

Escape-последовательности, используемые для расширения кода, не должны включаться в подсчёт символов.

Таблица 6.2-1. Представления значений DICOM

Имя VR	Определение	Репертуар символов	Длина значения
AE Application Entity	Строка символов, идентифицирующая прикладной объект (Application Entity), в которой ведущие и завершающие пробелы (20H) не являются значимыми. Значение, состоящее исключительно из пробелов, не должно использоваться.	Репертуар символов по умолчанию, исключая код символа 5CH (обратная косая черта "\" в ISO-IR 6) и все управляющие символы.	максимум 16 байтов
AS Age String	Строка символов в одном из следующих форматов -- nnnD, nnnW, nnnM, nnnY; где nnn должен содержать количество дней для D, недель для W, месяцев для M или лет для Y. Пример: "018M" означает возраст 18 месяцев.	"0"-"9", "D", "W", "M", "Y" репертуара символов по умолчанию	фиксированное 4 байта
AT Attribute Tag	Упорядоченная пара 16-битных беззнаковых целых чисел, являющаяся значением тега элемента данных. Пример: тег элемента данных (0018,00FF) кодируется как последовательность 4 байтов в синтаксисе передачи Little-Endian как 18H,00H,FFH,00H. Примечание Кодирование значения AT в точности совпадает с кодированием тега элемента данных, как определено в Разделе 7.	не применимо	фиксированное 4 байта
CS Code String	Строка символов, идентифицирующая контролируемое понятие. Ведущие или завершающие пробелы (20H) не являются значимыми. Альтернативно, в контексте запроса с сопоставлением пустых значений (см. PS3.4), строка из двух символов кавычек (QUOTATION MARK), представляющая пустое значение ключа.	Прописные буквы, "0"-"9", символ SPACE и знак подчёркивания "_" репертуара символов по умолчанию В контексте запроса с сопоставлением пустых значений (см. PS3.4), символ кавычек (QUOTATION MARK) разрешён.	максимум 16 байтов В контексте запроса с сопоставлением пустых значений (см. PS3.4), длина фиксирована и равна 2 байтам.
DA Date	Строка символов в формате YYYYMMDD; где YYYY должен содержать год, MM должен содержать месяц, а DD должен содержать день, интерпретируемый как дата григорианского календаря. Пример: "19930822" означает 22 августа 1993 г. Примечание Стандарт ACR-NEMA 300 (предшественник DICOM) поддерживал строку символов в формате YYYY.MM.DD для данного VR. Использование этого формата не соответствует стандарту. См. также VR DT в данной таблице. Даты до 1582 года, например, используемые для датирования исторических или археологических предметов, интерпретируются как даты пролептического григорианского календаря, если не указано иное. Альтернативно, в контексте запроса с сопоставлением пустых значений (см. PS3.4), строка из двух символов кавычек (QUOTATION MARK), представляющая пустое значение ключа.	"0"-"9" репертуара символов по умолчанию В контексте запроса с сопоставлением диапазонов (см. PS3.4), символ "-" разрешён, а завершающий символ SPACE разрешён для дополнения. В контексте запроса с сопоставлением пустых значений (см. PS3.4), символ кавычек (QUOTATION MARK) разрешён.	фиксированное 8 байтов В контексте запроса с сопоставлением диапазонов (см. PS3.4), длина — максимум 18 байтов. В контексте запроса с сопоставлением пустых значений (см. PS3.4), длина фиксирована и равна 2 байтам.
DS Decimal String	Строка символов, представляющая либо число с фиксированной запятой, либо число с плавающей запятой. Число с фиксированной запятой должно содержать только символы 0-9 с необязательным ведущим "+" или "-" и необязательной "." для обозначения десятичной точки. Число с плавающей запятой должно передаваться, как определено в ANSI X3.9, с "E" или "e" для указания начала экспоненты. Строки десятичных чисел могут быть дополнены ведущими или завершающими пробелами. Встроенные пробелы не допускаются. Примечание Элементы данных с несколькими значениями, использующие данный VR, могут быть неправильно закодированы, если используется синтаксис передачи с явным VR и VL данного элемента данных превышает 65534 байтов.	"0"-"9", "+", "-", "E", "e", "." и символ SPACE репертуара символов по умолчанию	максимум 16 байтов
DT Date Time	Сцепленная строка символов даты-времени в формате: YYYYMMDDHHMMSS.FFFFFF&ZZXX Компоненты этой строки слева направо: YYYY = Год, MM = Месяц, DD = День, HH = Час (диапазон "00" - "23"), MM = Минута (диапазон "00" - "59"), SS = Секунда (диапазон "00" - "60"). FFFFFF = Дробная часть секунды содержит дробную часть секунды с точностью до одной миллионной доли секунды (диапазон "000000" - "999999"). &ZZXX — необязательный суффикс для смещения от универсального координированного времени (UTC), где & = "+" или "-", ZZ = часы и XX = минуты смещения. Год, месяц и день интерпретируются как дата григорианского календаря. Используется 24-часовой формат времени. Полночь должна представляться только как "0000", поскольку "2400" нарушит диапазон часов. Компонент дробной части секунды, если он присутствует, должен содержать от 1 до 6 цифр. Если дробная часть секунды не указана, предшествующая "." не должна включаться. Суффикс смещения, если он присутствует, должен содержать 4 цифры. Строка может быть дополнена завершающими символами SPACE. Ведущие и встроенные пробелы не допускаются. Компонент, опущенный в строке, называется нулевым компонентом. Завершающие нулевые компоненты даты-времени указывают на то, что значение не является точным до точности этих компонентов. Компонент YYYY не должен быть нулевым. Ненулевые завершающие компоненты запрещены. Необязательный суффикс не рассматривается как компонент. Значение даты-времени без необязательного суффикса интерпретируется как находящееся в местном часовом поясе приложения, создающего элемент данных, если не указано иное атрибутом Timezone Offset From UTC (0008,0201). Смещения UTC вычисляются как "местное время минус UTC". Смещение для значения даты-времени в UTC должно быть +0000. Альтернативно, в контексте запроса с сопоставлением пустых значений (см. PS3.4), строка из двух символов кавычек (QUOTATION MARK), представляющая пустое значение ключа. Примечание Диапазон смещения составляет от -1200 до +1400. Смещение для восточного стандартного времени США составляет -0500. Смещение для стандартного времени Японии составляет +0900. Использование RFC 2822 значения -0000 в качестве смещения для указания местного времени не допускается. Значение даты-времени 195308 означает август 1953 г. без указания конкретного дня. Значение даты-времени 19530827111300.0 означает 27 августа 1953 г., 11:13 с точностью до 1/10 секунды. Компонент секунд может иметь значение 60 только для дополнительной секунды (leap second). Смещение может быть включено независимо от нулевых компонентов; например, 2007-0500 является допустимым значением.	"0"-"9", "+", "-", "." и символ SPACE репертуара символов по умолчанию В контексте запроса с сопоставлением пустых значений (см. PS3.4), символ кавычек (QUOTATION MARK) разрешён.	максимум 26 байтов В контексте запроса с сопоставлением диапазонов (см. PS3.4), длина — максимум 54 байта. В контексте запроса с сопоставлением пустых значений (см. PS3.4), длина фиксирована и равна 2 байтам.
FL Floating Point Single	Значение с плавающей запятой одинарной точности, представленное в формате binary32 стандарта [IEEE 754]. Разрешены все значения [IEEE 754], включая NaN (Not a Number) и значения бесконечности.	не применимо	фиксированное 4 байта
FD Floating Point Double	Значение с плавающей запятой двойной точности, представленное в формате binary64 стандарта [IEEE 754]. Разрешены все значения [IEEE 754], включая NaN (Not a Number) и значения бесконечности.	не применимо	фиксированное 8 байтов
IS Integer String	Строка символов, представляющая целое число в десятичной системе счисления (с основанием 10), должна содержать только символы 0 - 9 с необязательным ведущим "+" или "-". Может быть дополнена ведущими и/или завершающими пробелами. Встроенные пробелы не допускаются. Представляемое целое число n должно находиться в диапазоне: - 2³¹ <= n <= (2³¹-1).	"0"-"9", "+", "-" и символ SPACE репертуара символов по умолчанию	максимум 12 байтов
LO Long String	Символьная строка, которая может быть дополнена ведущими и/или завершающими пробелами. Код символа 5CH (обратная косая черта "\" в ISO-IR 6) не должен присутствовать, так как он используется в качестве разделителя между значениями в многозначных элементах данных. Строка не должна содержать управляющих символов, за исключением ESC.	Репертуар символов по умолчанию и/или как определено в (0008,0005), исключая код символа 5CH (обратную косую черту "\" в ISO-IR 6) и все управляющие символы, кроме ESC при использовании для escape-последовательностей [ISO/IEC 2022].	максимум 64 символа (см. Примечание в Разделе 6.2)
LT Long Text	Символьная строка, которая может содержать один или несколько абзацев. Может содержать набор графических символов и управляющие символы TAB (см. Примечание 3), CR, LF, FF и ESC. Может быть дополнена завершающими пробелами, которые могут игнорироваться, но ведущие пробелы считаются значимыми. Элементы данных с данным VR не должны быть многозначными, и поэтому код символа 5CH (обратная косая черта "\" в ISO-IR 6) может использоваться.	Репертуар символов по умолчанию и/или как определено в (0008,0005), исключая управляющие символы, кроме TAB, LF, FF, CR (и ESC при использовании для escape-последовательностей [ISO/IEC 2022]).	максимум 10240 символов (см. Примечание в Разделе 6.2)
OB Other Byte	Поток октетов, где кодирование содержимого определяется согласованным синтаксисом передачи. OB — это VR, нечувствительный к порядку байтов (см. Раздел 7.3). Поток октетов должен быть дополнен одним завершающим нулевым байтом (00H) при необходимости достижения чётной длины.	не применимо	максимум 2³²-2 байтов, кроме случаев, когда длина значения является неопределённой, если и только если это разрешено синтаксисом передачи для элемента данных (см. Раздел 7.1.1)
OD Other Double	Поток значений binary64 стандарта [IEEE 754]. Разрешены все значения [IEEE 754], включая NaN (Not a Number) и значения бесконечности. OD — это VR, требующий перестановки байтов в пределах каждого 64-битного слова при изменении порядка байтов (см. Раздел 7.3).	не применимо	максимум 2³²-8 байтов
OF Other Float	Поток значений binary32 стандарта [IEEE 754]. Разрешены все значения [IEEE 754], включая NaN (Not a Number) и значения бесконечности. OF — это VR, требующий перестановки байтов в пределах каждого 32-битного слова при изменении порядка байтов (см. Раздел 7.3).	не применимо	максимум 2³²-4 байта
OL Other Long	Поток 32-битных слов, где кодирование содержимого определяется согласованным синтаксисом передачи. OL — это VR, требующий перестановки байтов в пределах каждого слова при изменении порядка байтов (см. Раздел 7.3).	не применимо	максимум 2³²-4 байта
OV Other 64-bit Very Long	Поток 64-битных слов, где кодирование содержимого определяется согласованным синтаксисом передачи. OV — это VR, требующий перестановки байтов в пределах каждого слова при изменении порядка байтов (см. Раздел 7.3).	не применимо	максимум 2³²-8 байтов
OW Other Word	Поток 16-битных слов, где кодирование содержимого определяется согласованным синтаксисом передачи. OW — это VR, требующий перестановки байтов в пределах каждого слова при изменении порядка байтов (см. Раздел 7.3).	не применимо	максимум 2³²-2 байтов
PN Person Name	Символьная строка, закодированная с использованием соглашения о 5 компонентах. Код символа 5CH (обратная косая черта "\" в ISO-IR 6) не должен присутствовать, так как он используется в качестве разделителя между значениями в многозначных элементах данных. Строка может быть дополнена завершающими пробелами. Для использования человеком пять компонентов в порядке их следования: комплекс фамилии, комплекс имени, отчество (middle name), префикс имени, суффикс имени. Примечание HL7 запрещает ведущие пробелы внутри компонента; DICOM допускает ведущие и завершающие пробелы и считает их незначительными. Любой из пяти компонентов может быть пустой строкой. Разделителем компонентов должен быть символ циркумфлекса "^" (5EH). Должно быть не более четырёх разделителей компонентов, т.е. ни одного после последнего компонента, если присутствуют все компоненты. Разделители требуются для внутренних нулевых компонентов. Завершающие нулевые компоненты и их разделители могут быть опущены. В каждом компоненте допускаются несколько записей, которые кодируются как строки естественного текста в формате, предпочитаемом указанным лицом. Для ветеринарного использования первые два из пяти компонентов в порядке их следования: фамилия ответственного лица или название ответственной организации, имя пациента. Остальные компоненты не используются и не должны присутствовать. Эта группа из пяти компонентов называется группой компонентов имени лица (Person Name component group). Для цели написания имен идеографическими символами и фонетическими символами может использоваться до 3 групп компонентов (см. Приложение H, Приложение I и Приложение J). Разделителем групп компонентов должен быть знак равенства "=" (3DH). Должно быть не более двух разделителей групп компонентов, т.е. ни одного после последней группы компонентов, если присутствуют все группы компонентов. Три группы компонентов в порядке их следования: алфавитное представление, идеографическое представление и фонетическое представление. Любая группа компонентов может отсутствовать, включая первую группу компонентов. В этом случае имя лица может начинаться с одного или нескольких разделителей "=". Разделители требуются для внутренних нулевых групп компонентов. Завершающие нулевые группы компонентов и их разделители могут быть опущены. Для каждой группы компонентов определена точная семантика. См. Раздел 6.2.1.2. Примеры и примечания см. в Разделе 6.2.1.1.	Репертуар символов по умолчанию и/или как определено в (0008,0005), исключая код символа 5CH (обратную косую черту "\" в ISO-IR 6) и все управляющие символы, кроме ESC при использовании для escape-последовательностей [ISO/IEC 2022].	максимум 64 символа на группу компонентов (см. Примечание в Разделе 6.2)
SH Short String	Символьная строка, которая может быть дополнена ведущими и/или завершающими пробелами. Код символа 05CH (обратная косая черта "\" в ISO-IR 6) не должен присутствовать, так как он используется в качестве разделителя между значениями для многозначных элементов данных. Строка не должна содержать управляющих символов, кроме ESC.	Репертуар символов по умолчанию и/или как определено в (0008,0005), исключая код символа 5CH (обратную косую черту "\" в ISO-IR 6) и все управляющие символы, кроме ESC при использовании для escape-последовательностей [ISO/IEC 2022].	максимум 16 символов (см. Примечание в Разделе 6.2)
SL Signed Long	Знаковое двоичное целое число длиной 32 бита в форме дополнительного кода до 2. Представляет целое число n в диапазоне: - 2³¹ <= n <= (2³¹-1).	не применимо	фиксированное 4 байта
SQ Sequence of Items	Значением является последовательность из нуля или более элементов (Items), как определено в Разделе 7.5.	не применимо (см. Раздел 7.5)	максимум 2³²-2 байтов (см. Раздел 7.5)
SS Signed Short	Знаковое двоичное целое число длиной 16 бит в форме дополнительного кода до 2. Представляет целое число n в диапазоне: - 2¹⁵ <= n <= (2¹⁵-1).	не применимо	фиксированное 2 байта
ST Short Text	Символьная строка, которая может содержать один или несколько абзацев. Может содержать набор графических символов и управляющие символы TAB (см. Примечание 3), CR, LF, FF и ESC. Может быть дополнена завершающими пробелами, которые могут игнорироваться, но ведущие пробелы считаются значимыми. Элементы данных с данным VR не должны быть многозначными, и поэтому код символа 5CH (обратная косая черта "\" в ISO-IR 6) может использоваться.	Репертуар символов по умолчанию и/или как определено в (0008,0005), исключая управляющие символы, кроме TAB, LF, FF, CR (и ESC при использовании для escape-последовательностей [ISO/IEC 2022]).	максимум 1024 символа (см. Примечание в Разделе 6.2)
SV Signed 64-bit Very Long	Знаковое двоичное целое число длиной 64 бита. Представляет целое число n в диапазоне: - 2⁶³ <= n <= (2⁶³-1).	не применимо	фиксированное 8 байтов
TM Time	Строка символов в формате HHMMSS.FFFFFF; где HH содержит часы (диапазон "00" - "23"), MM содержит минуты (диапазон "00" - "59"), SS содержит секунды (диапазон "00" - "60"), а FFFFFF содержит дробную часть секунды с точностью до одной миллионной доли секунды (диапазон "000000" - "999999"). Используется 24-часовой формат времени. Полночь должна представляться только как "0000", поскольку "2400" нарушит диапазон часов. Строка может быть дополнена завершающими пробелами. Ведущие и встроенные пробелы не допускаются. Один или несколько компонентов MM, SS или FFFFFF могут быть не указаны, при условии, что каждый компонент справа от неуказанного компонента также не указан, что означает, что значение не является точным до точности этих неуказанных компонентов. Компонент FFFFFF, если он присутствует, должен содержать от 1 до 6 цифр. Если FFFFFF не указан, предшествующая "." не должна включаться. Примеры: "070907.0705 " представляет время 7 часов, 9 минут и 7.0705 секунд. "1010" представляет время 10 часов и 10 минут. "021 " — недопустимое значение. Примечание Стандарт ACR-NEMA 300 (предшественник DICOM) поддерживал строку символов в формате HH:MM:SS.frac для данного VR. Использование этого формата не соответствует стандарту. См. также VR DT в данной таблице. Компонент SS может иметь значение 60 только для дополнительной секунды (leap second). Альтернативно, в контексте запроса с сопоставлением пустых значений (см. PS3.4), строка из двух символов кавычек (QUOTATION MARK), представляющая пустое значение ключа.	"0"-"9", "." и символ SPACE репертуара символов по умолчанию В контексте запроса с сопоставлением диапазонов (см. PS3.4), символ "-" разрешён. В контексте запроса с сопоставлением пустых значений (см. PS3.4), символ кавычек (QUOTATION MARK) разрешён.	максимум 14 байтов В контексте запроса с сопоставлением диапазонов (см. PS3.4), длина — максимум 28 байтов. В контексте запроса с сопоставлением пустых значений (см. PS3.4), длина фиксирована и равна 2 байтам.
UC Unlimited Characters	Символьная строка, которая может иметь неограниченную длину и может быть дополнена завершающими пробелами. Код символа 5CH (обратная косая черта "\" в ISO-IR 6) не должен присутствовать, так как он используется в качестве разделителя между значениями в многозначных элементах данных. Строка не должна содержать управляющих символов, кроме ESC.	Репертуар символов по умолчанию и/или как определено в (0008,0005), исключая код символа 5CH (обратную косую черту "\" в ISO-IR 6) и все управляющие символы, кроме ESC при использовании для escape-последовательностей [ISO/IEC 2022].	максимум 2³²-2 байтов См. Примечание 2
UI Unique Identifier (UID)	Символьная строка, содержащая UID, который используется для однозначной идентификации широкого спектра объектов. UID представляет собой серию числовых компонентов, разделённых символом точки ".". Если поле значения, содержащее один или несколько UID, имеет нечётное количество байтов, поле значения должно быть дополнено одним завершающим символом NULL (00H) для обеспечения чётного количества байтов в поле значения. См. Раздел 9 и Приложение B для полной спецификации и примеров.	"0"-"9", "." репертуара символов по умолчанию	максимум 64 байта
UL Unsigned Long	Беззнаковое двоичное целое число длиной 32 бита. Представляет целое число n в диапазоне: 0 <= n <= (2³²-1).	не применимо	фиксированное 4 байта
UN Unknown	Поток октетов, где кодирование содержимого неизвестно (см. Раздел 6.2.2).	не применимо	Любая длина, допустимая для любого другого представления значения DICOM
UR Universal Resource Identifier or Universal Resource Locator (URI/URL)	Строка символов, идентифицирующая URI или URL, как определено в [RFC3986]. Ведущие пробелы не допускаются. Завершающие пробелы должны игнорироваться. Элементы данных с данным VR не должны быть многозначными. Альтернативно, в контексте запроса с сопоставлением пустых значений (см. PS3.4), строка из двух символов кавычек (QUOTATION MARK), представляющая пустое значение ключа. Примечание Разрешены как абсолютные, так и относительные URI. Если URI является относительным, то он отсчитывается от базового URI объекта, в котором он содержится, или от базового URI в другом атрибуте, как указано в определении информационного объекта.	Подмножество репертуара символов по умолчанию, требуемое для URI, как определено в IETF RFC3986 Раздел 2, плюс символ пробела (20H), разрешённый только в качестве завершающего дополнения. Символы вне разрешённого набора символов должны быть "процентно закодированы" ("percent encoded"). Примечание Символ обратной косой черты (BACKSLASH, 5CH) входит в число символов, не разрешённых в URI. В контексте запроса с сопоставлением пустых значений (см. PS3.4), символ кавычек (QUOTATION MARK) разрешён.	максимум 2³²-2 байтов. См. Примечание 2. В контексте запроса с сопоставлением пустых значений (см. PS3.4), длина фиксирована и равна 2 байтам.
US Unsigned Short	Беззнаковое двоичное целое число длиной 16 бит. Представляет целое число n в диапазоне: 0 <= n <= (2¹⁶-1).	не применимо	фиксированное 2 байта
UT Unlimited Text	Символьная строка, которая может содержать один или несколько абзацев. Может содержать набор графических символов и управляющие символы TAB (см. Примечание 3), CR, LF, FF и ESC. Может быть дополнена завершающими пробелами, которые могут игнорироваться, но ведущие пробелы считаются значимыми. Элементы данных с данным VR не должны быть многозначными, и поэтому код символа 5CH (обратная косая черта "\" в ISO-IR 6) может использоваться.	Репертуар символов по умолчанию и/или как определено в (0008,0005), исключая управляющие символы, кроме TAB, LF, FF, CR (и ESC при использовании для escape-последовательностей [ISO/IEC 2022]).	максимум 2³²-2 байтов См. Примечание 2
UV Unsigned 64-bit Very Long	Беззнаковое двоичное целое число длиной 64 бита. Представляет целое число n в диапазоне: 0 <= n <= (2⁶⁴-1).	не применимо	фиксированное 8 байтов

Примечание

Для элементов данных, которые присутствовали в ACR-NEMA 1.0 и 2.0 и были выведены из употребления, спецификации представления значения и кратности значения являются рекомендациями для целей интерпретации их значений в объектах, созданных в соответствии с более ранними версиями настоящего стандарта. Эти рекомендации предлагаются как наиболее подходящие для конкретного элемента данных; однако нет гарантии, что исторические объекты не нарушают некоторые требования или указанные VR и/или VM.
Длина значения VR UC, UR и UT ограничена только размером максимального беззнакового целого числа, представимого в 32-битном поле VL, минус два, поскольку FFFFFFFFH зарезервировано и длины должны быть чётными.
В предыдущих редакциях стандарта (см. PS3.5-2015a) символ TAB не был указан как разрешённый для VR ST, LT и UT. Он был добавлен для удобства форматирования и кодирования текста XML.

6.2.1 Представление значения имени лица (PN)

6.2.1.1 Примеры VR PN и примечания

Примеры:

Rev. John Robert Quincy Adams, B.A. M.Div.

"Adams^John Robert Quincy^^Rev.^B.A. M.Div."

[Одна фамилия; три имени; без отчества; один префикс; два суффикса.]
Susan Morrison-Jones, Ph.D., Chief Executive Officer

"Morrison-Jones^Susan^^^Ph.D., Chief Executive Officer"

[Две фамилии; одно имя; без отчества; без префикса; два суффикса.]
John Doe

"Doe^John"

[Одна фамилия; одно имя; без отчества, префикса или суффикса. Разделители для трёх завершающих нулевых компонентов были опущены.]
(примеры кодирования имён лиц с использованием многобайтовых наборов символов см. в Приложении H)
"Smith^Fluffy"

[Кошка, а не человек, чья фамилия ответственного лица — Смит, а собственное имя — Fluffy]
"ABC Farms^Running on Water"

[Лошадь, чья ответственная организация называется ABC Farms, а имя — "Running On Water"]

Примечание

Аналогичное соглашение о нескольких компонентах также используется типом данных HL7 v2 XPN. Однако тип данных XPN помещает компонент суффикса перед префиксом и имеет шестой компонент "degree" (учёная степень), который DICOM включает в суффикс имени. Существуют также различия в способе идентификации представления имени.
При типичном американском и европейском использовании первое появление "given name" (имени) представляет "first name" (первое имя). Второе и последующие появления "given name" обычно рассматриваются как отчество (middle name). Компонент "middle name" сохранён в целях обратной совместимости с существующими стандартами.
Разработчик должен учитывать более ранние формы использования, в которых "имена" (given names) представлялись как "первое" (first) и "отчество" (middle), и что может потребоваться преобразование из этого прежнего типичного использования и обратно.
В целях обратной совместимости с более ранними версиями настоящего стандарта имена лиц могут рассматриваться как единый комплекс фамилии (один компонент без разделителей "^").

6.2.1.2 Идеографические и фонетические символы в элементах данных с VR PN

Строки символов, представляющие имена лиц, кодируются с использованием соглашения для представления значения PN на основе групп компонентов с 5 компонентами.

Для цели написания имён идеографическими символами и фонетическими символами может использоваться до 3 групп компонентов. Разделителем групп компонентов должен быть знак равенства "=" (3DH). Три группы компонентов в порядке их следования: алфавитное представление, идеографическое представление и фонетическое представление.

Любая группа компонентов может отсутствовать, включая первую группу компонентов. В этом случае имя лица может начинаться с одного или нескольких разделителей "=". Разделители также требуются для внутренних нулевых групп компонентов. Завершающие нулевые группы компонентов и их разделители могут быть опущены.

Первая группа компонентов (обозначаемая в DICOM как "алфавитная") должна быть закодирована с использованием набора символов, заданного атрибутом Specific Character Set (0008,0005), Значение 1. Если атрибут Specific Character Set (0008,0005) отсутствует, должен использоваться репертуар символов по умолчанию ISO-IR 6. Escape-последовательности [ISO/IEC 2022] для расширения кода не должны использоваться в этой группе компонентов. Когда Значение 1 атрибута Specific Character Set (0008,0005) задаёт многобайтовый набор символов без расширения кода (т.е. Unicode в UTF-8, [GB 18030] или [GBK]), символы этой группы компонентов могут быть закодированы несколькими байтами, но должны быть взяты из кодовых точек от U+0020 до U+1FFF стандарта [ISO/IEC 10646] или из следующих кодовых точек [ISO/IEC 10646]:

U+3001, U+3002, U+300C, U+300D, от U+3099 до U+309C и от U+30A0 до U+30FF

Вторая группа должна использоваться для идеографических символов. Используемые наборы символов обычно берутся из атрибута Specific Character Set (0008,0005), Значения от 2 до n, и могут использовать escape-последовательности [ISO/IEC 2022].

Третья группа должна использоваться для фонетических символов. Используемые наборы символов должны быть из атрибута Specific Character Set (0008,0005), Значения от 1 до n, и могут использовать escape-последовательности [ISO/IEC 2022].

Символы-разделители "^" и "=" берутся из набора символов, заданного Значением 1 атрибута Specific Character Set (0008,0005). Если Значение 1 атрибута Specific Character Set (0008,0005) отсутствует, должен использоваться репертуар символов по умолчанию ISO-IR 6.

В начале значения элемента данных имени лица предполагается следующее начальное условие: если Значение 1 атрибута Specific Character Set (0008,0005) отсутствует, вызывается репертуар символов по умолчанию ISO-IR 6, а если Значение 1 атрибута Specific Character Set (0008,0005) присутствует, вызывается набор символов, заданный Значением 1 этого атрибута.

В конце значения элемента данных имени лица и перед разделителями компонентов "^" и "=" набор символов должен быть переключён на репертуар символов по умолчанию ISO-IR 6, если Значение 1 атрибута Specific Character Set (0008,0005) отсутствует. Если Значение 1 атрибута Specific Character Set (0008,0005) присутствует, набор символов должен быть переключён на указанный в Значении 1 этого атрибута.

Длина значения каждой группы компонентов — максимум 64 символа, включая разделитель группы компонентов. Каждый комбинирующий символ (например, диакритические знаки или знаки гласных) должен считаться отдельным символом при подсчёте максимальной длины, независимо от того, как приложение может отображать такие комбинирующие символы (т.е. объединяя их в глиф базового символа или отображая отдельно).

6.2.2 Представление значения Unknown (UN)

VR Unknown (UN) должен использоваться только для частных элементов данных и стандартных элементов данных, ранее закодированных с некоторым VR DICOM, отличным от UN, с использованием кодирования с неявным VR, и для которых представление значения в настоящее время неизвестно, или чьё известное представление значения является одним из тех, которые имеют 16-битное поле длины значения (см. Раздел 7.1.2) при использовании кодирования с явным VR и чья длина значения превышает 65534 (2¹⁶-2). Пока VR неизвестен, поле значения нечувствительно к порядку байтов и не должно подвергаться перестановке байтов (см. Раздел 7.3). В случае последовательностей с неопределённой длиной значение должно оставаться в форме с неявным VR. См. Раздел 7.8 для описания частных элементов данных и Раздел 10 и Приложение A для обсуждения синтаксисов передачи.

VR UN не должен использоваться для элементов данных создателя частных данных (Private Creator Data Elements) (т.е. VR равен LO, см. Раздел 7.8.1).

VR UN не должен использоваться для элементов данных метоинформации файла (File Meta Information Data Elements) (любой тег (0002,xxxx), см. PS3.10).

Примечание

Все остальные (неумалчиваемые) синтаксисы передачи DICOM используют явный VR в своём кодировании, и поэтому любое поле значения частного и/или стандартного элемента данных, закодированное и декодированное с использованием любого синтаксиса передачи, отличного от синтаксиса передачи DICOM по умолчанию Little Endian и не переведённое в синтаксис передачи DICOM по умолчанию Little Endian за это время, будет иметь известный VR.
Если в какой-то момент приложению становится известен фактический VR для элемента данных с VR UN (например, имеется собственный применимый словарь данных), оно может предположить, что поле значения элемента данных закодировано с прямым порядком байтов (Little Endian) с кодированием с неявным VR, независимо от текущего синтаксиса передачи.
Данный VR UN необходим, когда элементу данных, представление значения которого неизвестно, должен быть присвоен явный VR (например, при сохранении и пересылке).
Данный VR UN также необходим для кодирования элементов данных с явным VR, чья длина значения превышает 65534 (2¹⁶-2) (FFFEH, наибольшее чётное 16-битное беззнаковое число), но которые определены как имеющие 16-битное поле длины значения явного VR.
Поле длины значения VR UN может содержать неопределённую длину (FFFFFFFFH), и в этом случае содержимое поля значения может считаться закодированным с неявным VR. См. Раздел 7.5.1 для определения способа разбора элементов данных с неопределённой длиной.
Примером стандартного элемента данных, использующего VR UN, является стандартный атрибут типа 3 (Type 3) или типа U (Type U), добавленный в определение SOP-класса. Существующее приложение, не поддерживающее этот новый атрибут (и столкнувшееся с ним), могло бы преобразовать VR в UN.

6.2.3 Представление значения URI/URL (UR)

VR URI/URL (UR) использует подмножество репертуара символов по умолчанию, как определено в [RFC3986], и не должен использовать методы расширения или замены кода. Компоненты доменного имени URI/URL, которые в исходной форме используют символы вне разрешённого набора символов, должны использовать кодирование Internationalized Domain Names for Applications в соответствии с IETF RFC5890 и RFC5891. Другое содержимое URI/URL, использующее символы вне разрешённого набора символов, должно использовать механизм кодирования Internationalized Resource Identifiers стандарта IETF RFC 3987, представляя строку содержимого в UTF-8 и процентно кодируя символы по мере необходимости.

Примечание

Например, использование имени пациента в строке URI/URL может потребовать применения метода [RFC3987].

6.3 Перечисляемые значения и определённые термины

Значение определённых элементов данных может быть выбрано из набора явных значений, удовлетворяющих его VR. Эти явные значения являются либо перечисляемыми значениями (Enumerated Values), либо определёнными терминами (Defined Terms) и указаны в PS3.3 и PS3.4.

Перечисляемые значения (Enumerated Values) используются, когда указанные явные значения являются единственными разрешёнными значениями для элемента данных. Элемент данных с перечисляемыми значениями, не имеющий значения, эквивалентного одному из значений, указанных в настоящем стандарте, имеет недопустимое значение в рамках конкретного определения информационного объекта/SOP-класса.

Примечание

Patient Sex (0010, 0040) — пример элемента данных с перечисляемыми значениями. Он определён как имеющий значение "M", "F" или "O" (см. PS3.3). Никакое другое значение не должно присваиваться этому элементу данных.
Будущие изменения настоящего стандарта могут добавить к набору разрешённых значений для элементов данных с перечисляемыми значениями. Такие добавления сами по себе могут как требовать, так и не требовать изменения UID SOP-классов, в зависимости от семантики элемента данных.

Определённые термины (Defined Terms) используются, когда указанные явные значения могут быть расширены разработчиками для включения дополнительных новых значений. Эти новые значения должны быть указаны в Заявлении о соответствии (см. PS3.2) и не должны иметь тот же смысл, что и определённые в настоящее время значения в настоящем стандарте. Элемент данных с определёнными терминами, не содержащий значения, эквивалентного одному из значений, указанных в настоящее время в настоящем стандарте, не должен считаться имеющим недопустимое значение. Пустое (нулевой длины) значение не является допустимым новым значением для определённого термина; пустые значения должны считаться недопустимыми, если стандарт специально не разрешает пустые значения. Новые значения не должны иметь смысл "неизвестно", поскольку это понятие, если оно разрешено стандартом, должно передаваться явно — либо путём разрешения элементу данных быть нулевой длины, либо путём предоставления стандартного определённого термина с таким значением.

Примечание

Reporting Priority (0040,1009) — пример элемента данных с определёнными терминами. Он определён как имеющий значение, которое может быть одним из набора стандартных значений: HIGH, ROUTINE, MEDIUM или LOW (см. PS3.3). Поскольку этот элемент данных имеет определённые термины, разработчиком могут быть определены и другие приоритеты отчётности.
Допустимость пустых значений обычно определяется атрибутом как тип 2 (см. Раздел 7.4.3). Однако в контексте обязательного атрибута типа 1 с несколькими значениями некоторые (но не все) значения могут быть разрешены как пустые (см. Раздел 7.4.1); в этом случае стандарт явно указывает допустимость пустых значений в списке определённых терминов для каждого значения. Specific Character Set (0008,0005) — пример элемента данных, для которого стандарт специально разрешает первое значение быть пустым при наличии нескольких значений. Image Type (0008,0008) — пример элемента данных, который в некоторых IOD, определённых в PS3.3, требуется присутствовать с несколькими значениями, но если пустое значение явно не указано в определённых терминах для Значения 3 каким-либо IOD, пустое значение недопустимо.

Представление значения может влиять на интерпретацию определённых терминов и перечисляемых значений для числовых значений. Для двоичных представлений значений текстовое представление значения в стандарте не влияет на интерпретацию. Для строковых представлений значений (IS и DS) должно использоваться значение в стандарте, а не буквальная строка.

Примечание

Например, перечисляемое значение "1", выраженное в тексте стандарта, соответствует значению IS или DS, закодированному как "001", или значению DS, закодированному как "1.0", "1.", "1.0000E+00", или любому другому допустимому кодированию. Ведущие и завершающие пробелы определены в Таблице 6.2-1 как незначительные и, следовательно, не влияют на интерпретацию.

6.4 Кратность значения (VM) и ограничение

Кратность значения (Value Multiplicity) элемента данных указывает количество значений, которые могут быть закодированы в поле значения этого элемента данных. VM каждого элемента данных явно указана в PS3.6. Если количество значений, которые могут быть закодированы в элементе данных, является переменным, оно представляется двумя числами, разделёнными тире; например, "1-10" означает, что в элементе данных может быть от 1 до 10 значений.

Примечание

Элементы, имевшие кратность "S" (означавшую "single", т.е. "одно") в более ранних версиях настоящего стандарта, в данной версии стандарта будут иметь кратность "1".

Когда элемент данных имеет несколько значений, эти значения должны быть разделены следующим образом:

Для строк символов символ 5CH (обратная косая черта "\" в случае репертуара ISO IR-6) должен использоваться в качестве разделителя между значениями.

Примечание

Обратная косая черта ("\") используется в качестве разделителя между строковыми значениями как фиксированной, так и переменной длины.
Несколько бинарных значений фиксированной длины должны представлять собой серию сцепленных значений без какого-либо разделителя.

Каждое строковое значение в многозначной символьной строке может иметь чётную или нечётную длину, но длина всего поля значения (включая разделители "\") должна быть чётной. Если для обеспечения чётной длины поля значения требуется дополнение, один символ дополнения должен быть добавлен в конец поля значения (к последнему значению), и в этом случае длина последнего значения может превышать длину значения на 1.

Примечание

В вышеуказанном случае к строковому значению фиксированной длины может потребоваться добавить символ дополнения.

Только последнее значение UID в многозначном элементе данных с VR UI должно быть дополнено одним завершающим символом NULL (00H) при необходимости обеспечения чётной длины всего поля значения (включая разделители "\").

Каждое строковое значение в многозначной символьной строке может быть пустым, если не указано иное. Наличие только одного или нескольких разделителей (BACKSLASH) без каких-либо значений трактуется как пустое значение элемента данных, даже если длина значения больше нуля. См. Раздел 7.4 для подробностей о требованиях к типу элемента данных.

Элементы данных с VR LT, OB, OD, OF, OL, OV, OW, SQ, ST, UN, UR или UT всегда должны иметь кратность значения, равную одному. См. Таблицу 6.2-1.

7 Набор данных

Набор данных представляет экземпляр реального информационного объекта. Набор данных состоит из элементов данных. Элементы данных содержат закодированные значения атрибутов этого объекта. Конкретное содержание и семантика этих атрибутов определяются в Определениях информационных объектов (см. PS3.3).

Конструкция, характеристики и кодирование набора данных и его элементов данных рассматриваются в этом разделе. Пиксельные данные и оверлеи — это элементы данных, интерпретация которых зависит от других связанных элементов данных.

7.1 Элементы данных

Элемент данных однозначно идентифицируется тегом элемента данных. Элементы данных в наборе данных должны быть упорядочены по возрастанию номера тега элемента данных и должны встречаться в наборе данных не более одного раза.

Примечание

Тег элемента данных может повторяться внутри вложенных наборов данных (см. Раздел 7.5).

Определены два типа элементов данных:

Стандартные элементы данных имеют чётный номер группы, не равный 0000, 0002, 0004 или 0006.

Примечание

Использование этих групп зарезервировано для команд DIMSE (см. PS3.7) и форматов файлов DICOM.
Частные элементы данных имеют нечётный номер группы, не равный 0001, 0003, 0005, 0007 или FFFF. Частные элементы данных более подробно рассматриваются в Разделе 7.8.

Примечание

Хотя похожие или связанные элементы данных часто имеют один и тот же номер группы; группа данных не несёт никакой смысловой нагрузки.

Элемент данных должен иметь одну из трёх структур. Две из этих структур содержат VR элемента данных (явный VR), но различаются способом выражения длины, тогда как третья структура не содержит VR (неявный VR). Все три структуры содержат тег элемента данных, длину значения и значение элемента данных. См. Рисунок 7.1-1.

Элементы данных с явным и неявным VR не должны сосуществовать в наборе данных и во вложенных в него наборах данных (см. Раздел 7.5). Использует ли набор данных явный или неявный VR, среди прочих характеристик, определяется согласованным синтаксисом передачи (см. Раздел 10 и Приложение A).

Примечание

VR не содержатся в элементах данных при использовании синтаксиса передачи DICOM по умолчанию Little Endian (Implicit VR Little Endian).

DICOM Data Set and Data Element Structures

Рисунок 7.1-1. Структуры набора данных и элементов данных DICOM

7.1.1 Поля элемента данных

Элемент данных состоит из полей. Три поля являются общими для всех трёх структур элемента данных; это тег элемента данных, длина значения и поле значения. Четвёртое поле — представление значения — присутствует только в двух структурах элемента данных с явным VR. Структуры элемента данных определены в Разделе 7.1.2 и Разделе 7.1.3. Определения полей:

Data Element Tag

Упорядоченная пара 16-битных целых чисел без знака, представляющая номер группы, за которым следует номер элемента.

Value Representation

Два однобайтовых символа, содержащие VR элемента данных. VR для заданного тега элемента данных должен быть таким, как определено словарём данных, указанным в PS3.6. Двухбайтовый VR должен кодироваться с использованием только заглавных букв из набора символов DICOM по умолчанию.

Value Length

Либо:

16- или 32-битное (в зависимости от VR и от того, является ли VR явным или неявным) целое число без знака, содержащее явную длину поля значения как количество байтов (чётное), составляющих значение. Оно не включает длину полей тега элемента данных, представления значения и длины значения.
32-битное поле длины значения, установленное в неопределённую длину (FFFFFFFFH). Неопределённая длина может использоваться для элементов данных с представлением значения (VR) «Последовательность элементов» (SQ) и «Неизвестно» (UN). Для элементов данных с представлением значения OB неопределённая длина может использоваться в зависимости от согласованного синтаксиса передачи (см. Раздел 10 и Приложение A).

Примечание

Декодер набора данных должен поддерживать как явную, так и неопределённую длину для VR SQ и UN и, при необходимости, в зависимости от синтаксиса передачи (как определено в Разделе A.4 «Синтаксисы передачи для инкапсуляции закодированных пиксельных данных»), для VR OB для элемента данных «Пиксельные данные» (7FE0,0010).
32-битное поле длины значения ограничивает максимальный размер больших полей значения данных, таких как пиксельные данные, передаваемые в собственном формате (кодируемые в синтаксисах передачи, использующих только неинкапсулированную форму).

Value Field

Чётное количество байтов, содержащее значение (значения) элемента данных.

Тип данных значений, хранящихся в этом поле, определяется VR элемента данных. VR для заданного тега элемента данных может быть определён с использованием словаря данных в PS3.6 или с использованием поля VR, если оно явно содержится в элементе данных. VR стандартных элементов данных должен соответствовать указанным в словаре данных.

Кратность значения указывает, сколько значений с этим VR может быть помещено в поле значения. Если VM больше одного, несколько значений должны разделяться в поле значения, как определено ранее в Разделе 6.4. Кратности значений стандартных элементов данных указаны в словаре данных в PS3.6.

Поля значения с неопределённой длиной кодируются с использованием элементов ограничения последовательности, элементов явной или неопределённой длины и элементов данных ограничения элементов, которые более подробно описаны в Разделе 7.5 и Разделе A.4.

7.1.2 Структура элемента данных с явным VR

При использовании структур с явным VR элемент данных должен состоять из четырёх последовательных полей: тег элемента данных, VR, длина значения и значение. В зависимости от VR элемента данных он будет структурирован одним из двух способов:

для VR AE, AS, AT, CS, DA, DS, DT, FL, FD, IS, LO, LT, PN, SH, SL, SS, ST, TM, UI, UL и US поле длины значения является 16-битным целым числом без знака, следующим за двухбайтовым полем VR (Таблица 7.1-2). Значение поля длины значения должно быть равно длине поля значения.
для всех остальных VR 16 бит, следующие за двухбайтовым полем VR, зарезервированы для использования последующими версиями стандарта DICOM. Эти зарезервированные байты должны быть установлены в 0000H и не должны использоваться или декодироваться (Таблица 7.1-1). Поле длины значения является 32-битным целым числом без знака.
- для VR OB, SQ и UN, если поле значения имеет явную длину, то поле длины значения должно содержать значение, равное длине (в байтах) поля значения, в противном случае поле значения имеет неопределённую длину, поле значения будет состоять из элементов Item, а элемент ограничения последовательности будет присутствовать в конце поля значения.
- для всех остальных VR с 32-битным полем длины значения поле длины значения должно содержать значение, равное длине (в байтах) поля значения.
Примечание

Декодеру набора данных потребуется анализировать поле значения, обрабатывая элементы Item, чтобы определить конец поля значения. Он не может выполнять поиск элемента ограничения последовательности, поскольку последовательность байтов, из которой он состоит, может быть допустимым значением в поле значения, и механизм экранирования отсутствует.

Таблица 7.1-1. Элемент данных с явным VR, отличным от приведённого в Таблице 7.1-2

Тег	VR	Длина значения	Значение
Group Number (16-битное целое число без знака)	Element Number (16-битное целое число без знака)	VR (2 однобайтовых символа)	Зарезервировано (2 байта), установлено в значение 0000H	32-битное целое число без знака	Чётное количество байтов, содержащее значение (значения) элемента данных, закодированное в соответствии с VR и согласованным синтаксисом передачи. Ограничивается элементом ограничения последовательности, если имеет неопределённую длину.
2 байта	2 байта	2 байта	2 байта	4 байта	байты «Длина значения», если явная длина

Тег

Длина значения

Значение

Group Number

(16-битное целое число без знака)

Element Number

(16-битное целое число без знака)

(2 однобайтовых символа)

Зарезервировано (2 байта), установлено в значение 0000H

32-битное целое число без знака

Чётное количество байтов, содержащее значение (значения) элемента данных, закодированное в соответствии с VR и согласованным синтаксисом передачи. Ограничивается элементом ограничения последовательности, если имеет неопределённую длину.

2 байта

4 байта

байты «Длина значения», если явная длина

Таблица 7.1-2. Элемент данных с явным VR AE, AS, AT, CS, DA, DS, DT, FL, FD, IS, LO, LT, PN, SH, SL, SS, ST, TM, UI, UL и US

Тег	VR	Длина значения	Значение
Group Number (16-битное целое число без знака)	Element Number (16-битное целое число без знака)	VR (2 однобайтовых символа)	(16-битное целое число без знака)	Чётное количество байтов, содержащее значение (значения) элемента данных, закодированное в соответствии с VR и согласованным синтаксисом передачи.
2 байта	2 байта	2 байта	2 байта	байты «Длина значения»

Тег

Длина значения

Значение

Group Number

(16-битное целое число без знака)

Element Number

(16-битное целое число без знака)

(2 однобайтовых символа)

(16-битное целое число без знака)

Чётное количество байтов, содержащее значение (значения) элемента данных, закодированное в соответствии с VR и согласованным синтаксисом передачи.

2 байта

байты «Длина значения»

7.1.3 Структура элемента данных с неявным VR

При использовании структуры с неявным VR элемент данных должен состоять из трёх последовательных полей: тег элемента данных, длина значения и значение (см. Таблицу 7.1-3). Если поле значения имеет явную длину, то поле длины значения должно содержать значение, равное длине (в байтах) поля значения. В противном случае, для VR OB и SQ, поле значения имеет неопределённую длину, поле значения будет состоять из элементов Item, а элемент ограничения последовательности будет присутствовать в конце поля значения.

Примечание

Декодеру набора данных потребуется анализировать поле значения, обрабатывая элементы Item, чтобы определить конец поля значения. Он не может выполнять поиск элемента ограничения последовательности, поскольку последовательность байтов, из которой он состоит, может быть допустимым значением в поле значения, и механизм экранирования отсутствует.
VR UN не встречается при неявном VR; см. Раздел 6.2.2.

Таблица 7.1-3. Элемент данных с неявным VR

Тег	Длина значения	Значение
Group Number (16-битное целое число без знака)	Element Number (16-битное целое число без знака)	32-битное целое число без знака	Чётное количество байтов, содержащее значение элемента данных, закодированное в соответствии с VR, указанным в PS3.6, и согласованным синтаксисом передачи. Ограничивается элементом ограничения последовательности, если имеет неопределённую длину.
2 байта	2 байта	4 байта	байты «Длина значения» или неопределённая длина

Тег

Длина значения

Значение

Group Number

(16-битное целое число без знака)

Element Number

(16-битное целое число без знака)

32-битное целое число без знака

Чётное количество байтов, содержащее значение элемента данных, закодированное в соответствии с VR, указанным в PS3.6, и согласованным синтаксисом передачи. Ограничивается элементом ограничения последовательности, если имеет неопределённую длину.

2 байта

4 байта

байты «Длина значения» или неопределённая длина

7.2 Длина группы

Элементы данных «Длина группы» (gggg,0000) были неявно определены для групп стандартных и частных элементов данных с представлением значения UL и кратностью значения 1, но были изъяты. См. PS3.5-2007.

Все реализации должны быть способны анализировать элементы данных «Длина группы» и могут отбрасывать их, а также не вставлять или повторно вставлять их; если они присутствуют, они должны быть согласованы с кодированием набора данных, даже если синтаксис передачи изменён, что приводит к изменению фактической длины группы элементов данных. Ни одна реализация не должна требовать наличия элементов данных «Длина группы».

Примечание

Элементы в группах 0, 2, 4 и 6 не являются стандартными элементами данных. Обязательные требования к длине группы для групп 0 и 2 указаны в другом месте стандарта.
Рекомендуется удалять элементы данных «Длина группы» во время хранения или передачи, чтобы избежать риска возникновения несоответствий при принудительном изменении значений элементов данных и изменениях синтаксиса передачи.

7.3 Порядок байтов Little Endian

Все неизъятые синтаксисы передачи в DICOM требуют использования порядка байтов Little Endian.

Порядок байтов Little Endian определяется следующим образом:

В двоичном числе, состоящем из нескольких байтов (например, 32-битном целом числе без знака, номере группы, номере элемента и т. д.), младший значащий байт должен кодироваться первым; остальные байты кодируются в порядке возрастания значимости.
В строке символов, состоящей из нескольких 8-битных однобайтовых кодов, символы кодируются в порядке их следования в строке (слева направо).

Порядок байтов Big Endian ранее описывался, но был изъят. См. PS3.5 2016b.

Примечание

Упаковка битов в значениях с представлением значения OB или OW для пиксельных данных и данных оверлея описана в Разделе 8. Представления значений OL и OV не используются для пиксельных данных или данных оверлея.

Порядок байтов является компонентом согласованного синтаксиса передачи (см. Раздел 10). Синтаксис передачи DICOM по умолчанию, который должен поддерживаться всеми AE, использует кодирование Little Endian и указан в Разделе A.1. Альтернативные синтаксисы передачи Little Endian также указаны в Приложении A.

Примечание

Структура набора команд, указанная в PS3.7, кодируется с использованием синтаксиса передачи Implicit VR Little Endian.

В случае кодирования Little Endian, машины Big Endian, интерпретирующие наборы данных, должны выполнять «перестановку байтов» перед интерпретацией или обработкой определённых элементов данных. Затронутые элементы данных — это все те, которые имеют VR с многобайтовыми значениями и не являются строкой символов из 8-битных однобайтовых кодов. VR, состоящие из строки символов из 8-битных однобайтовых кодов, фактически состоят из строки отдельных байтов и поэтому не зависят от порядка байтов. VR, не являющиеся строкой символов и состоящие из нескольких байтов:

2-byte US, SS, OW and each component of AT
4-byte OF, OL, UL, SL, and FL
8-byte OD, OV, FD, SV and UV

Примечание

Для вышеуказанных VR несколько байтов представлены в порядке возрастания значимости в формате Little Endian. Например, 8-байтовый элемент данных с VR FD может быть записан в шестнадцатеричном виде как 68AF4B2CH, но в кодировке Little Endian будет 2C4BAF68H.

7.4 Тип элемента данных

Атрибут, закодированный как элемент данных, может требоваться или не требоваться в наборе данных в зависимости от типа элемента данных этого атрибута.

Тип элемента данных атрибута определения информационного объекта или атрибута определения класса SOP используется для указания того, является ли этот атрибут обязательным или необязательным. Тип элемента данных также указывает, является ли атрибут условным (обязательным только при определённых условиях). Типы элементов данных атрибутов составных IOD указаны в PS3.3. Типы элементов данных атрибутов нормализованных IOD указаны как атрибуты классов SOP в PS3.4.

7.4.1 Обязательные элементы данных типа 1

IOD и классы SOP определяют элементы данных типа 1, которые должны быть включены и являются обязательными элементами данных. Поле значения должно содержать допустимые данные, как определено VR и VM элемента данных, указанными в PS3.6. Длина поля значения не должна быть равна нулю. Отсутствие допустимого значения в элементе данных типа 1 является нарушением протокола.

Примечание

Для элементов данных со строковым, а не двоичным, текстовым представлением значения или представлением последовательности, и для которых допускается несколько значений, наличие одного значения достаточно для удовлетворения требования типа 1, если не указано иное в описании атрибута, а другие значения могут быть пустыми, если IOD не указано иное. Наличие только одного или нескольких разделителей (BACKSLASH) без каких-либо значений недостаточно для удовлетворения требования типа 1, поскольку, хотя длина значения больше нуля, допустимое значение элемента данных отсутствует. Аналогично, для элементов данных с VR PN наличие только разделителей компонентов («^») или групп компонентов («=») недостаточно для удовлетворения требований непустого значения.
Элемент данных последовательности типа 1 будет содержать один или несколько элементов, как определено IOD (независимо от VM последовательности, которая всегда равна единице (Раздел 7.5)). Могут ли эти элементы быть пустыми (не содержать элементов данных), зависит от определения IOD набора данных для каждого элемента.

7.4.2 Условные элементы данных типа 1C

IOD и классы SOP определяют элементы данных, которые должны быть включены при определённых заданных условиях. Элементы данных типа 1C имеют те же требования, что и элементы данных типа 1 при этих условиях. Нарушением протокола является случай, когда заданные условия выполнены, а элемент данных не включён.

Если заданные условия не выполнены, элементы данных типа 1C не должны включаться в набор данных, если не указано, что они могут присутствовать в иных случаях.

7.4.3 Обязательные элементы данных типа 2

IOD и классы SOP определяют элементы данных типа 2, которые должны быть включены и являются обязательными элементами данных. Однако допустимо, что если значение элемента данных типа 2 неизвестно, он может быть закодирован с нулевой длиной значения и без значения. Если значение известно, поле значения должно содержать это значение, как определено VR и VM элемента данных, указанными в PS3.6. Эти элементы данных должны быть включены в набор данных, и их отсутствие является нарушением протокола.

Примечание

Назначение элементов данных типа 2 — позволить передавать нулевую длину, когда оператор или приложение не знает его значения или имеет конкретную причину не указывать его значение. Предполагается, что устройство должно поддерживать эти элементы данных.
Элемент данных последовательности типа 2 будет содержать ноль или более элементов, как определено IOD (независимо от VM последовательности, которая всегда равна единице (Раздел 7.5)). Пустая последовательность типа 2 — это последовательность без элементов, в отличие от элемента, который присутствует, но пуст. Могут ли элементы быть пустыми (не содержать элементов данных), зависит от определения IOD набора данных для каждого элемента, а не от типа охватывающего элемента данных последовательности.

7.4.4 Условные элементы данных типа 2C

IOD и классы SOP определяют элементы данных типа 2C, которые имеют те же требования, что и элементы данных типа 2 при определённых заданных условиях. Нарушением протокола является случай, когда заданные условия выполнены, а элемент данных не включён.

Если заданные условия не выполнены, элементы данных типа 2C не должны включаться в набор данных, если не указано, что они могут присутствовать в иных случаях.

Примечание

Примером элемента данных типа 2C является «Время инверсии» (Inversion Time) (0018,0082). Для нескольких определений классов SOP этот элемент данных требуется только в том случае, если «Последовательность сканирования» (Scanning Sequence) (0018,0020) имеет значение «IR». В остальных случаях он не требуется. См. PS3.3.

7.4.5 Необязательные элементы данных типа 3

IOD и классы SOP определяют элементы данных типа 3, которые являются необязательными элементами данных. Отсутствие элемента данных типа 3 в наборе данных не несёт никакой значимости и не является нарушением протокола. Элементы данных типа 3 также могут быть закодированы с нулевой длиной и без значения. Значение элемента данных типа 3 с нулевой длиной должно быть в точности таким же, как отсутствие этого элемента данных в наборе данных.

7.4.6 Типы элементов данных в последовательности

Когда IOD определяет элемент данных последовательности (см. Раздел 7.5), тип атрибута последовательности определяет, должен ли сам атрибут последовательности присутствовать, а описание атрибута последовательности может определять, должны ли присутствовать элементы в последовательности и в каком количестве. Типы атрибутов набора данных, включённого в последовательность, включая любую условность, указываются в рамках каждого набора данных, т. е. для каждого элемента, присутствующего в последовательности.

Примечание

Тип и описание атрибута последовательности определяют, присутствуют ли элементы; условные ограничения на элементы данных элементов не могут заставить элемент присутствовать.
Исторически многие IOD объявляли элементы данных типа 1 и типа 2 последовательности как тип 1C и тип 2C соответственно, при условии, что элемент присутствует. Это то же самое, что просто определить их как тип 1 и тип 2.
В частности, условное ограничение «Обязателен, если последовательность передана» для элементов данных типа 1C или 2C, подчинённых атрибуту последовательности типа 2 или 3, не означает, что элемент должен присутствовать в последовательности. Эти условия должны быть эквивалентны «Обязателен, если присутствует элемент последовательности», и условность не является строго необходимой. Любой атрибут последовательности типа 2 или 3 может быть передан с нулевой длиной.
В частности, условное ограничение «Обязателен, если передан <имя-родительского-атрибута-последовательности>» для элементов данных типа 1C или 2C, подчинённых атрибуту последовательности типа 2 или 3, не означает, что элемент должен присутствовать в последовательности. Эти условия должны быть эквивалентны «Обязателен, если присутствует элемент последовательности», и условность не является строго необходимой. Любой атрибут последовательности типа 2 или 3 может быть передан с нулевой длиной.

7.5 Вложение наборов данных

VR, обозначенный «SQ», должен использоваться для элементов данных со значением, состоящим из последовательности нуля или более элементов, где каждый элемент содержит набор элементов данных. SQ обеспечивает гибкую схему кодирования, которая может использоваться для простых структур повторяющихся наборов элементов данных или для кодирования более сложных определений информационных объектов, часто называемых папками. Элементы данных SQ также могут использоваться рекурсивно для создания многоуровневых вложенных структур.

Элементы, присутствующие в элементе данных SQ, должны представлять собой упорядоченный набор, где каждый элемент может быть указан по его порядковой позиции. Каждому элементу неявно присваивается порядковая позиция, начиная со значения 1 для первого элемента в последовательности и увеличиваясь на 1 для каждого последующего элемента. Последний элемент в последовательности должен иметь порядковую позицию, равную количеству элементов в последовательности.

Примечание

Этот пункт подразумевает, что упорядочивание элементов сохраняется во время передачи и хранения.
Определение IOD или модуля может отказаться от использования этого свойства упорядочивания элемента данных с VR SQ. Это делается просто путём неуказания какой-либо конкретной семантики для упорядочивания элементов или путём неуказания использования ссылки на элементы по позиции упорядочивания.

Определение элементов данных, инкапсулированных в каждом элементе, предоставляется спецификацией элемента данных (или связанного атрибута) с представлением значения SQ. Элементы в последовательности элементов могут как содержать, так и не содержать один и тот же набор элементов данных. Элементы данных с VR SQ могут содержать несколько элементов, но всегда должны иметь кратность значения, равную единице (т. е. одну последовательность).

Существуют три специальных элемента данных, связанных с SQ, на которые не распространяются правила кодирования VR, передаваемые синтаксисом передачи. Они должны кодироваться как неявный VR. Этими специальными элементами данных являются Item (FFFE,E000), Item Delimitation Item (FFFE,E00D) и Sequence Delimitation Item (FFFE,E0DD). Однако набор данных в поле значения элемента данных Item (FFFE,E000) должен кодироваться в соответствии с правилами, передаваемыми синтаксисом передачи.

7.5.1 Правила кодирования элементов

Каждый элемент элемента данных с представлением значения SQ должен кодироваться как стандартный элемент данных DICOM с конкретным тегом элемента данных со значением (FFFE,E000). За тегом элемента следует 4-байтовое поле длины значения (элемента), кодируемое одним из следующих двух способов:

Явная длина: количество байтов (чётное), содержащихся в значении элемента последовательности (после поля длины значения (элемента), но не включая его), кодируется как 32-битное целое число без знака (см. Раздел 7.1). Эта длина должна включать общую длину всех элементов данных, передаваемых этим элементом. Это поле длины значения (элемента) должно быть равно 00000000H, если элемент не содержит набор данных.
Неопределённая длина: поле длины значения (элемента) должно содержать значение FFFFFFFFH для указания неопределённой длины. Оно должно использоваться вместе с элементом данных ограничения элемента. Этот элемент данных ограничения элемента имеет тег элемента данных (FFFE,E00D) и должен следовать за элементами данных, инкапсулированными в элементе. В элементе данных ограничения элемента не должно быть значения, а его длина значения (элемента) должна быть 00000000H. Элемент, не содержащий набор данных, кодируется только элементом данных ограничения элемента.

Кодировщик набора данных может выбрать любой из двух способов кодирования. Оба способа кодирования должны поддерживаться декодерами наборов данных. Теги элементов данных (FFFF,eeee) зарезервированы этим стандартом и не должны использоваться.

Значение каждого элемента должно содержать набор данных DICOM, состоящий из элементов данных. В контексте каждого элемента эти элементы данных должны быть упорядочены по возрастанию значения тега элемента данных и встречаться только один раз (как набор данных определён в Разделе 7.1). Нет никакой связи между упорядочиванием элементов данных, содержащихся в элементе, и упорядочиванием тега элемента данных с представлением значения SQ, который содержит этот элемент. Один или несколько элементов данных в элементе могут иметь представление значения SQ, что допускает рекурсию.

Элементы данных с группой 0000, 0002 и 0006 не должны присутствовать в элементах последовательности.

Примечание

Использование Transfer Syntax UID (0002,0010), в частности, запрещено, поскольку, если бы оно отличалось от синтаксиса передачи охватывающего набора данных, это подразумевало бы изменение кодирования, что не допускается.

Раздел 7.8 определяет правила включения частных элементов данных в элементы последовательности.

7.5.2 Ограничение последовательности элементов

Ограничение последнего элемента последовательности элементов, инкапсулированной в элемент данных с представлением значения SQ, должно осуществляться одним из двух следующих способов:

Явная длина: количество байтов (чётное), содержащихся в значении элемента данных (после поля длины значения (последовательности), но не включая его), кодируется как 32-битное целое число без знака (см. Раздел 7.1). Эта длина должна включать общую длину, полученную из последовательности нуля или более элементов, передаваемых этим элементом данных. Эта длина элемента данных должна быть равна 00000000H, если последовательность элементов содержит ноль элементов.
Неопределённая длина: поле длины значения (последовательности) должно содержать значение FFFFFFFFH для указания последовательности неопределённой длины. Оно должно использоваться вместе с элементом ограничения последовательности. Элемент ограничения последовательности должен быть включён после последнего элемента в последовательности. Его тег элемента должен быть (FFFE,E0DD) с полем длины значения (элемента) 00000000H. Значение не должно присутствовать. Последовательность, содержащая ноль элементов, кодируется только элементом ограничения последовательности.

Кодировщик последовательности элементов может выбрать любой из двух способов кодирования. Оба способа кодирования должны поддерживаться декодерами последовательности элементов.

Примечание

Тег элемента ограничения последовательности (FFFE,E0DD) отличается от тега ограничения элемента (FFFE,E00D), введённого выше, тем, что он указывает конец последовательности элементов, длина которой была оставлена неопределённой. Если элемент неопределённой длины является последним элементом последовательности элементов неопределённой длины, то за тегом ограничения элемента будет следовать тег ограничения последовательности.

Пример элемента данных SQ явной длины, инкапсулирующего элементы явной длины, см. в Таблице 7.5-1.

Пример элемента данных SQ неопределённой длины, инкапсулирующего элементы явной длины, см. в Таблице 7.5-2.

Пример элемента данных SQ неопределённой длины, инкапсулирующего элементы как явной, так и неопределённой длины, см. в Таблице 7.5-3.

Таблица 7.5-1. Пример элемента данных с неявным VR, определённого как последовательность элементов (VR = SQ) с тремя элементами явной длины

Data Element Tag	Длина элемента данных	Data Element Value
(gggg, eeee) с VR SQ	0000 0F00H	Первый элемент			Второй элемент			Третий элемент
(gggg, eeee) с VR SQ	0000 0F00H	Тег элемента (FFFE, E000)	Длина элемента 0000 04F8H	Набор данных значения элемента	Тег элемента (FFFE, E000)	Длина элемента 0000 04F8H	Набор данных значения элемента	Тег элемента (FFFE, E000)	Длина элемента 0000 04F8H	Набор данных значения элемента
4 байта	4 байта	4 байта	4 байта	04F8H bytes	4 байта	4 байта	04F8H bytes	4 байта	4 байта	04F8H bytes

Таблица 7.5-2. Пример элемента данных с явным VR, определённого как последовательность элементов (VR = SQ) неопределённой длины, содержащая два элемента явной длины

Data Element Tag	Представление значения		Длина элемента данных	Data Element Value
(gggg, eeee) с VR SQ	SQ	0000H Зарезервировано	FFFF FFFFH Неопределённая длина	Первый элемент			Второй элемент			Элемент ограничения последовательности
(gggg, eeee) с VR SQ	SQ	0000H Зарезервировано	FFFF FFFFH Неопределённая длина	Тег элемента (FFFE, E000)	Длина элемента 98A5 2C68H	Набор данных значения элемента	Тег элемента (FFFE, E000)	Длина элемента B321 762CH	Набор данных значения элемента	Тег элемента ограничения последовательности (FFFE, E0DD)	Длина элемента 0000 0000H
4 байта	2 байта	2 байта	4 байта	4 байта	4 байта	98A5 2C68H bytes	4 байта	4 байта	B321 762CH bytes	4 байта	4 байта

Примечание

Наборы данных в значениях элементов в Таблице 7.5-2 имеют явно определённые VR.

Таблица 7.5-3. Пример элемента данных с неявным VR, определённого как последовательность элементов (VR = SQ) неопределённой длины, содержащая два элемента, где один элемент имеет явную длину, а другой — неопределённую длину

Data Element Tag	Длина элемента данных	Значение элемента данных
(gggg, eeee) с VR SQ	FFFF FFFFH Неопределённая длина	Первый элемент			Второй элемент					Элемент ограничения последовательности
(gggg, eeee) с VR SQ	FFFF FFFFH Неопределённая длина	Тег элемента (FFFE, E000)	Длина элемента 0000 17B6H	Набор данных значения элемента	Тег элемента (FFFE, E000)	Длина элемента FFFF FFFFH Неопределённая длина	Набор данных значения элемента	Тег ограничения элемента (FFFE, E00D)	Длина 0000 0000H	Тег элемента ограничения последовательности (FFFE, E0DD)	Длина элемента 0000 0000H
4 байта	4 байта	4 байта	4 байта	17B6H bytes	4 байта	4 байта	Неопределённая длина	4 байта	4 байта	4 байта	4 байта

7.5.3 Наследование последовательности

Инкапсулированный набор данных должен включать элемент данных «Специфический набор символов» (Specific Character Set) (0008,0005), только если «Специфический набор символов» (0008,0005) определён в IOD для этой последовательности элементов.

Примечание

Инкапсулированный набор данных не включает элемент данных «Специфический набор символов» (0008,0005), если «Специфический набор символов» (0008,0005) не определён как часть IOD для этой последовательности.

Если инкапсулированный набор данных включает «Специфический набор символов» (0008,0005), он должен применяться только к инкапсулированному набору данных. Если «Специфический набор символов» (0008,0005) явно не включён в инкапсулированный набор данных, то применяется значение «Специфического набора символов» (0008,0005) инкапсулирующего набора данных.

7.6 Повторяющиеся группы

С одним изображением может быть связано несколько плоскостей оверлея (см. PS3.3). Стандартные элементы данных с чётными номерами групп 6000-601E представляют плоскости оверлея. Этот диапазон номеров групп известен как повторяющаяся группа. Такое использование номеров групп является пережитком более старых версий этого стандарта, которые связывали семантическое значение с конкретными группами.

В этом диапазоне номеров групп стандартные элементы данных с одинаковыми номерами элементов имеют одинаковое значение в каждой группе (и одинаковые VR, VM и тип элемента данных). Обозначение 60xx используется для номера группы в тегах элементов данных при ссылке на общий элемент данных в этих группах (см. PS3.6). Группы 60xx называются повторяющимися группами из-за этих характеристик.

Повторяющиеся группы должны быть разрешены только в чётных группах 6000-601E. В будущем элементы данных с VR SQ будут использоваться для аналогичных целей.

Примечание

Кодирование кривых в чётных номерах групп 50xx ранее было определено, но было изъято. См. PS3.5-2004
Частные группы в нечётных номерах групп 6001-601F могут по-прежнему использоваться, но это не подразумевает повторяющейся семантики или какого-либо подразумеваемого затенения стандартных повторяющихся групп.

7.7 Изъятые элементы данных

Некоторые элементы данных больше не поддерживаются в текущем стандарте. Эти элементы данных изъяты и обозначены как таковые (RET) в столбце VR в PS3.6. Реализации могут продолжать поддерживать эти элементы данных в целях обратной совместимости с более старыми версиями этого стандарта, но это не является требованием текущего стандарта. Если изъятый элемент данных используется, он должен содержать допустимые данные, как указано в более старых версиях этого стандарта. Любое другое использование изъятого элемента данных и его связанного тега элемента данных зарезервировано этим стандартом. Теги изъятых элементов данных не должны быть переопределены в последующих версиях этого стандарта.

7.8 Частные элементы данных

Реализациям может требоваться обмен информацией, которая не может быть помещена в стандартные элементы данных. Частные элементы данных предназначены для использования с целью хранения такой информации. Такие частные элементы данных не должны изменять семантику определения информационного объекта (Information Object Definition) или определения класса SOP (SOP Class Definition).

Частные элементы данных имеют ту же структуру, что и стандартные элементы данных, описанные ранее в Разделе 7.1 (т.е. поле тега элемента данных, необязательное поле VR, поле длины значения и поле значения). Номер группы (Group Number), используемый в теге элемента частных элементов данных, должен быть нечётным числом. Частные элементы данных должны содержаться в наборе данных (Data Set) в порядке возрастания числового значения тега элемента данных. Поле значения частного элемента данных должно иметь одно из значений представления (VR), заданных настоящим стандартом в Разделе 6.2.

Для каждого определения информационного объекта (Information Object Definition) или определения класса SOP (SOP Class Definition) определённые элементы данных являются обязательными (тип элемента данных 1, 1C, 2 или 2C), как указано в PS3.3 и PS3.4. Частные элементы данных не должны использоваться вместо обязательных стандартных элементов данных.

7.8.1 Теги частных элементов данных

Возможно, что несколько разработчиков определят частные элементы с одинаковым (нечётным) номером группы. Во избежание конфликтов частным элементам должны назначаться теги частных элементов данных согласно следующим правилам.

Элементы данных частного создателя (Private Creator Data Elements) с номерами (gggg,0010-00FF) (gggg — нечётное) должны использоваться для резервирования блока элементов с номером группы gggg для использования отдельным разработчиком. Разработчик должен вставить код идентификации в неиспользуемый (неназначенный) элемент этой серии, чтобы зарезервировать блок частных элементов. VR кода частной идентификации должен быть LO (Long String), а VM должен быть равен 1. Идентификатор частного создателя (Private Creator) может быть использован только один раз в пределах группы; резервирование нескольких блоков элементов в одной и той же группе с одним и тем же идентификатором не допускается. Элементы данных частного создателя должны содержать только символы из репертуара символов по умолчанию (Default Character Repertoire), а не из расширенного (Extended) или замещающего (Replacement) репертуара символов, даже несмотря на то, что VR LO подвержен влиянию атрибута Specific Character Set (0008,0005).
Примечание
1. Если разработчику требуются повторения частного элемента данных, частный элемент данных последовательности (см. Раздел 7.5) может использоваться для размещения каждого из повторяемых частных элементов данных в отдельных элементах (items). Каждый элемент должен заявить о соответствующем частном блоке элементов, как описано ниже.
2. Разработчик может использовать один и тот же идентификатор частного создателя для нескольких групп.
3. Первый элемент данных частного создателя не обязательно должен быть (gggg,0010), так же как они не обязаны назначаться последовательно. В частности, если блок частных элементов данных полностью удалён вместе с его элементом данных частного создателя, например, в процессе деидентификации, другие частные блоки не требуют перенумерации.
4. Элемент данных частного создателя может присутствовать, даже если соответствующие частные элементы данных не используются. В частности, если блок частных элементов данных полностью удалён, например, в процессе деидентификации, соответствующий элемент данных частного создателя не обязательно удалять, хотя это допустимо.
5. Несмотря на то, что элемент данных частного создателя может содержать только символы из репертуара символов по умолчанию (Default Character Repertoire) независимо от фактических значений атрибута Specific Character Set (0008,0005), рекомендуется использовать только те значения из репертуара символов по умолчанию, которые представляют графические символы (Graphic Characters), и избегать определённых значений, чтобы повысить вероятность надёжного распознавания. В частности, в [JIS X 0201] не только значение байта для разделителя между значениями (05/12) представляет другой символ (ЗНАК ЙЕНЫ (YEN SIGN) (‘¥’) в отличие от ОБРАТНОЙ КОСОЙ ЧЕРТЫ (BACKSLASH) (‘\`)), но и значение 07/14 (НАДЧЁРКИВАНИЕ (OVERLINE) (‘‾’) в отличие от ТИЛЬДЫ (TILDE) (‘~’)), поэтому следует избегать как 05/12, так и 07/14.
Элемент данных частного создателя (gggg,0010) требуется для идентификации элементов данных (gggg,1000-10FF), если они присутствуют; элемент данных частного создателя (gggg,0011) требуется для идентификации элементов данных (gggg,1100-11FF), если они присутствуют; и так далее до элемента данных частного создателя (gggg,00FF), который идентифицирует элементы данных (gggg,FF00-FFFF), если они присутствуют.
Кодировщики частных элементов данных должны иметь возможность динамически назначать частные данные в любой доступный (незарезервированный) блок(и) в пределах частной группы и указывать это назначение через соответствующий(ие) элемент(ы) данных частного создателя этого блока. Декодировщики частных данных должны иметь возможность принимать зарезервированные блоки с заданным кодом идентификации частного создателя в любой позиции в пределах частной группы, указанной соответствующим элементом данных частного создателя этого блока.
Примечание
1. Более ранние версии настоящего стандарта описывали теневые группы (shadow groups). Это были группы с номером группы, на единицу большим, чем у стандартных групп. Устранение конфликтов в тегах частных элементов данных сделало это различие устаревшим, и данная терминология была изъята.
2. Более ранние версии настоящего стандарта указывали номера элементов данных в частных группах (gggg,10FF-7FFF), зарезервированные для производителей, и номера элементов данных в частных группах (gggg, 8100-FFFF), зарезервированные для пользователей. Устранение конфликтов в тегах частных элементов данных сделало это различие устаревшим, и данное требование было изъято.
3. Требования настоящего раздела не допускают какого-либо использования элементов данных в диапазонах (gggg,0001-000F) и (gggg,0100-0FFF), где gggg — нечётное.
Элементы с тегами (0001,xxxx), (0003,xxxx), (0005,xxxx), (0007,xxxx) и (FFFF,xxxx) не должны использоваться.
То, содержат ли частные элементы данных идентификационную информацию, связанную с деидентификацией, определяется последовательностью характеристик частных элементов данных (Private Data Element Characteristics Sequence) (0008,0300). См. PS3.3 Раздел C.12.1.
Элементы данных с номером (gggg,0000), где gggg — нечётное, были элементами длины группы (Group Length Elements), которые были изъяты. См. Раздел 7.2.

Элементы (Items) внутри последовательности являются самодостаточными наборами данных (см. Раздел 7.5 о вложении наборов данных через последовательности элементов (Sequences of Items)); любой элемент в последовательности, который содержит частные элементы данных, должен также иметь элемент данных частного создателя, резервирующий блок элементов для этих частных элементов данных. Область действия резервирования ограничена пределами элемента. Элементы не наследуют резервирования частных элементов данных, сделанные элементами данных частного создателя в наборе данных, в который вложен данный элемент.

Пример:

Тег атрибута	Значение атрибута	Назначение атрибута
(0029,0010)	"Acme_CT_Parameters"	Резервирование блока для параметров Acme CT
(0029,0011)	"Acme_General_Parameters"	Резервирование блока для общих параметров Acme
(0029,1101)		Последовательность, содержащая повторяющиеся атрибуты
%item
>(0029,0010)	"Acme_CT_Parameters"	Резервирование блока для параметров Acme CT
>(0029,0011)	"Acme_General_Parameters"	Резервирование блока для общих параметров Acme
>(0029,1001)	985	Параметр Acme CT 1
>...
%enditem
%item
>(0029,0010)	"Acme_CT_Parameters"	Резервирование блока для параметров Acme CT
>(0029,0011)	"Acme_General_Parameters"	Резервирование блока для общих параметров Acme
>(0029,1001)	986	Параметр Acme CT 1
>...
%enditem
%endseq

Примечание

Если сама последовательность является частным элементом данных, а элементы внутри последовательности также содержат частные элементы данных, то элементы данных частного создателя будут присутствовать как вне последовательности, так и внутри элементов последовательности.
Различные элементы могут резервировать один и тот же блок частных элементов данных для разных частных создателей. Это необходимо для обеспечения возможности вложения наборов данных, собранных из нескольких источников, в папки.
Рекомендуемое соглашение для ссылки на частный элемент данных — (gggg,xxee,"pcde"), где gggg — номер группы, xx — строка «xx», ee — номер элемента в пределах зарезервированного блока, а pcde — заключённое в кавычки значение элемента данных частного создателя, зарезервировавшего блок, например (0029,xx43,"Acme_CT_Parameters"). Кроме того, при описании блока частных элементов данных можно вынести описание значения элемента данных частного создателя отдельно, например: элемент данных частного создателя (0029,00xx) = "Acme_CT_Parameters", и (0029,xx43), (0029,xx44) и т.д.

7.8.2 Кодирование частных элементов

Значения представлений (VR), используемые для частных элементов данных, должны быть теми же, что и VR, заданные для стандартных элементов данных в Разделе 6.2. Кодирование должно соответствовать требованиям для этих VR и должно осуществляться в соответствии с согласованным синтаксисом передачи (Transfer Syntax). Частный элемент данных с VR SQ (частная последовательность данных — Private Data Sequence) может включать элементы как со стандартными, так и с частными элементами данных. Стандартные элементы данных, используемые внутри частной последовательности данных, должны использовать VR, определённые в PS3.6 для этих элементов данных.

Семантика стандартных элементов данных внутри частной последовательности данных и определение значений атрибутов зависят от реализации.

Для стандартного расширенного класса SOP (Standard Extended SOP Class) атрибуты Pixel Data (7FE0,0010), Float Pixel Data (7FE0,0008), Double Float Pixel Data (7FE0,0009), Waveform Data (5400,1010) и Overlay Data (60xx,3000) не должны включаться в элемент частной последовательности (Private Sequence Item) или в элемент стандартной последовательности (Standard Sequence Item), вложенный прямо или косвенно в элемент частной последовательности.

8 Кодирование данных пикселей, оверлея и сигналов

8.1 Данные пикселей и оверлея и связанные элементы данных

Pixel Data (7FE0,0010), Float Pixel Data (7FE0,0008), Double Float Pixel Data (7FE0,0009) и Overlay Data (60xx,3000) должны использоваться для обмена кодированными графическими данными изображения. Эти элементы данных наряду с дополнительными элементами данных, определёнными как атрибуты сущностей графической информации (Image Information Entities) в PS3.3, должны использоваться для описания способа кодирования и интерпретации Pixel Data и Overlay Data. Наконец, в зависимости от согласованного синтаксиса передачи (см. Раздел 10 и Приложение A), Pixel Data может быть сжата.

Pixel Data (7FE0,0010) и Overlay Data (60xx,3000) имеют VR OW или OB в зависимости от согласованного синтаксиса передачи (см. Приложение A). Единственное различие между OW и OB заключается в том, что OB — октетный поток (octet-stream) — не подвержен влиянию порядка байтов (см. Раздел 7.3).

Float Pixel Data (7FE0,0008) имеет значение представления (Value Representation) OF.

Double Float Pixel Data (7FE0,0009) имеет значение представления (Value Representation) OD.

Для значений Pixel Data, закодированных в OF и OD, может использоваться любое значение, допустимое [IEEE 754], включая NaN, плюс бесконечность (Positive Infinity) и минус бесконечность (Negative Infinity). См. Таблицу 6.2-1

Примечание

Значения Pixel Data в формате binary32 и binary64 с плавающей запятой не ограничиваются произвольным образом конечными числами, поскольку для приложения может быть важно сообщить, что результат вычисления, в котором получено значение пикселя, является бесконечным значением или не является числом.

8.1.1 Кодирование данных пикселей связанных элементов данных

Должна обеспечиваться поддержка закодированных Pixel Data с различной битовой глубиной. Следующие три элемента данных определяют структуру пикселей:

Bits Allocated (0028,0100)
Bits Stored (0028,0101)
High Bit (0028,0102)

Каждый Pixel Cell должен содержать одно значение Pixel Sample Value. Размер Pixel Cell задаётся атрибутом Bits Allocated (0028,0100). Bits Stored (0028,0101) определяет общее количество этих выделенных битов, которые будут использованы для представления значения Pixel Sample Value. Bits Stored (0028,0101) никогда не должен превышать Bits Allocated (0028,0100). High Bit (0028,0102) указывает, куда должен быть помещён старший бит из Bits Stored (0028,0101) относительно спецификации Bits Allocated (0028,0100). Bits Allocated (0028,0100) должен быть равен 1 либо быть кратным 8. High Bit (0028,0102) должен быть на единицу меньше Bits Stored (0028,0101).

Примечание

Например, в Pixel Data с 16 выделенными битами (2 байтами), 12 хранимыми битами и битом 11, заданным в качестве старшего бита, один образец пикселя кодируется в каждом 16-битном слове, причём 4 старших бита каждого слова не содержат Pixel Data. Другие примеры базовых схем кодирования см. в Приложении D.
Ранее биты, не используемые для значений Pixel Sample Values, описывались как пригодные для плоскостей оверлея (overlay planes), но это использование было изъято. См. PS3.5-2004.
Ранее High Bit (0028,0102) не был ограничен значением на единицу меньше Bits Stored (0028,0101) в настоящей части или в общем случае, хотя почти все определения информационных объектов (Information Object Definitions) в PS3.3 налагали такое ограничение. См. PS3.5 2014c.
Принимающие приложения не должны делать каких-либо предположений о содержимом неиспользуемых битов и, в частности, не должны предполагать, что они равны нулю или что содержат биты расширения знака (sign extension).

Дополнительные ограничения, налагаемые на допустимые значения для Bits Allocated (0028,0100), Bits Stored (0028,0101) и High Bit (0028,0102) для Pixel Data (7FE0,0010), указаны в определениях информационных объектов (Information Object Definitions) в PS3.3.

На допустимые значения Bits Allocated (0028,0100) для Float Pixel Data (7FE0,0008) и Double Float Pixel Data (7FE0,0009) налагаются ограничения таким образом, что только единичный Pixel Cell полностью занимает выделенные биты, заданные Bits Allocated (0028,0100), поэтому Bits Stored (0028,0101) и High Bit (0028,0102) не передаются.

Кроме того, поле значения (Value Field), содержащее Pixel Data, как и все другие поля значений в DICOM, должно иметь чётную длину в байтах. Это означает, что поле значения может потребоваться дополнить данными, не являющимися частью изображения, которые не должны считаться значимыми. При необходимости биты дополнения должны быть добавлены в конец поля значения и должны использоваться только для расширения данных до следующего чётного приращения байта длины.

Примечание

32-битное поле длины значения (Value Length Field) ограничивает максимальный размер полей значения больших данных, таких как Pixel Data, передаваемых в собственном формате (Native Format) (в кодировке с использованием синтаксисов передачи, в которых применяется только неинкапсулированная форма).

В многокадровом изображении (Multi-frame Image), передаваемом в собственном формате (Native Format), отдельные кадры (Frames) не дополняются. Отдельные кадры должны быть объединены (конкатенированы), а биты дополнения (при необходимости) применяются ко всему полю значения целиком. Должен присутствовать хотя бы один кадр.

Примечание

Принимающие приложения должны учитывать, что некоторые старые приложения могут передавать Pixel Data с избыточным дополнением, что не было явно запрещено в более ранних версиях стандарта. Приложения должны быть готовы принимать такие элементы данных Pixel Data, но могут удалить избыточное дополнение. Ни при каких обстоятельствах передающее приложение не должно помещать частные данные в данные дополнения.
В многокадровом изображении (Multi-frame Image) со значением Bits Allocated (0028,0100), равным 1, передаваемом в собственном формате (Native Format), отдельные кадры не дополняются; поэтому последовательные биты упаковываются в байты или слова, как описано в 8.2. Т.е. кадр, отличный от первого, может начинаться в середине байта или слова. Это согласуется с историческим кодированием многокадровых оверлеев (Multi-frame Overlays), описанным в 8.1.

Поле битов, представляющее значение пикселя (Pixel Sample), должно быть двоичным целым числом в дополнительном коде до 2 (2's complement) или беззнаковым целым числом, как указано элементом данных Pixel Representation (0028,0103). Знаковым битом должен быть High Bit в значении Pixel Sample Value, представляющем целое число в дополнительном коде до 2. Минимальное фактическое значение Pixel Sample Value, встречающееся в Pixel Data, задаётся атрибутом Smallest Image Pixel Value (0028,0106), а максимальное значение — атрибутом Largest Image Pixel Value (0028,0107).

8.1.2 Кодирование данных оверлея связанных элементов данных

Закодированные плоскости оверлея (Overlay Planes) всегда имеют битовую глубину, равную 1, и кодируются отдельно от Pixel Data в Overlay Data (60xx,3000). Следующие два элемента данных определяют структуру плоскости оверлея:

Overlay Bits Allocated (60xx,0100)
Overlay Bit Position (60xx,0102)

Примечание

Не существует элемента данных, аналогичного Bits Stored (0028,0101), поскольку плоскости оверлея всегда имеют битовую глубину, равную 1.
Ограничения на допустимые значения для этих элементов данных определены в PS3.3. Ранее описывались данные оверлея, хранимые в неиспользуемых битах Pixel Data (7FE0,0010), и эти атрибуты имели осмысленные значения, однако такое использование было изъято. См. PS3.5-2004. Для оверлеев, закодированных в Overlay Data (60xx,3000), Overlay Bits Allocated (60xx,0100) всегда равно 1, а Overlay Bit Position (60xx,0102) всегда равно 0.

Для Overlay Data (60xx,3000) чаще всего требуется значение представления OW. Значение представления OB также может использоваться для Overlay Data в случаях, когда значение представления явно передаётся (см. Приложение A).

Примечание

DICOM Default Little Endian Transfer Syntax (Implicit VR Little Endian) не передаёт явно значение представления (Value Representation), поэтому VR OB не может использоваться для Overlay Data при использовании синтаксиса передачи по умолчанию (Default Transfer Syntax).

Overlay Data кодируется путём непосредственной конкатенации битов одной плоскости оверлея (Overlay Plane), при этом первый бит плоскости оверлея кодируется в наименее значимом бите, за которым непосредственно следует следующий бит плоскости оверлея в следующем наиболее значимом бите. Для многокадрового оверлея (Multi-frame Overlay) отдельные кадры не дополняются. Отдельные кадры должны быть объединены (конкатенированы), а биты дополнения (при необходимости) применяются ко всему полю значения целиком. Когда Overlay Data пересекает границу слова в случае OW или границу байта в случае OB, кодирование должно продолжаться от наименее значимого бита к наиболее значимому биту в следующем слове или байте соответственно (см. Приложение D). Для Overlay Data, закодированной со значением представления OW, порядок байтов результирующих 2-байтовых слов определяется Little Endian Transfer Syntaxes, согласованными при установлении ассоциации (Association Establishment) (см. Приложение A).

Примечание

Для Overlay Data, закодированной со значением представления OB, кодирование Overlay Data не подвержено влиянию порядка байтов.

8.2 Кодирование в собственном или инкапсулированном формате

Пиксельные данные, передаваемые в элементе данных Pixel Data (7FE0,0010), могут быть отправлены либо в собственном (несжатом) формате, либо в инкапсулированном формате (например, сжатом).

Если Pixel Data (7FE0,0010) отправляется в собственном формате, то Photometric Interpretation (0028,0004) не должен быть:

YBR_RCT
YBR_ICT
YBR_PARTIAL_420

Примечание

Эти значения не допускаются, поскольку они не могут быть закодированы в несжатой форме.

Пиксельные данные, передаваемые в элементах данных Float Pixel Data (7FE0,0008) или Double Float Pixel Data (7FE0,0009), должны быть в собственном (несжатом) формате, если они закодированы в стандартном синтаксисе передачи.

Примечание

В будущем, если для сжатия Float Pixel Data (7FE0,0008) или Double Float Pixel Data (7FE0,0009) будут определены стандартные синтаксисы передачи, это ограничение может быть смягчено, и инкапсулированный формат может быть разрешён.
Это ограничение не применяется к частным синтаксисам передачи.

Если Pixel Data (7FE0,0010) отправляется в собственном формате, чаще всего требуется представление значений OW. Представление значений OB также может использоваться для Pixel Data (7FE0,0010) в случаях, когда Bits Allocated имеет значение 8 или менее, но только с синтаксисами передачи, в которых представление значений передаётся явно (см. Приложение A).

Примечание

Синтаксис передачи DICOM Default Little Endian (Implicit VR Little Endian) не передаёт представление значений явно, и поэтому VR OB не может использоваться для Pixel Data (7FE0,0010) при использовании синтаксиса передачи по умолчанию.
32-битное поле длины значения ограничивает максимальный размер больших полей значений данных, таких как Pixel Data, отправляемых в собственном формате.

Float Pixel Data (7FE0,0008) отправляется в собственном формате; представление значений должно быть OF, Bits Allocated (0028,0100) должно быть 32, Bits Stored (0028,0101), High Bit (0028,0102) и Pixel Representation (0028,0103) не должны присутствовать.

Double Float Pixel Data (7FE0,0009) отправляется в собственном формате; представление значений должно быть OD, Bits Allocated (0028,0100) должно быть 64, Bits Stored (0028,0101) и High Bit (0028,0102), а также Pixel Representation (0028,0103) не должны присутствовать.

Не допускается наличие более чем одного из следующих элементов в наборе данных верхнего уровня: Pixel Data Provider URL (0028,7FE0), Pixel Data (7FE0,0010), Float Pixel Data (7FE0,0008) или Double Float Pixel Data (7FE0,0009).

Примечание

Пиксельные данные, закодированные в Float Pixel Data (7FE0,0008) или Double Float Pixel Data (7FE0,0009), могут рассматриваться как состоящие из пиксельных ячеек, полностью занимающих распределённые биты, и, следовательно, не пересекающих границы слов.

В собственном формате пиксельные ячейки кодируются как прямое объединение битов каждой пиксельной ячейки: младший значащий бит каждой пиксельной ячейки кодируется в младший значащий бит кодируемого слова или байта, за которым непосредственно следует следующий по значимости бит каждой пиксельной ячейки в следующий по значимости бит кодируемого слова или байта, и так далее, пока все биты пиксельной ячейки не будут закодированы, затем непосредственно следует младший значащий бит следующей пиксельной ячейки в следующий по значимости бит кодируемого слова или байта. Количество битов каждой пиксельной ячейки определяется значением элемента данных Bits Allocated (0028,0100). Когда пиксельная ячейка пересекает границу слова в случае OW или границу байта в случае OB, она должна продолжать кодироваться от младшего значащего бита к старшему в следующем слове или байте соответственно (см. Приложение D). Для Pixel Data (7FE0,0010), закодированных с представлением значений OW, порядок байтов результирующих двухбайтовых слов определяется синтаксисами передачи Little Endian, согласованными при установлении ассоциации (см. Приложение A).

Примечание

Для Pixel Data (7FE0,0010), закодированных с представлением значений OB, кодирование Pixel Data (7FE0,0010) не зависит от порядка байтов.
При кодировании Pixel Data (7FE0,0010) со значением Bits Allocated (0028,0100), не равным 16, обязательно прочитайте и поймите Приложение D.

Если данные отправляются в инкапсулированном формате (т.е. не в собственном формате), используется представление значений OB. Пиксельные ячейки кодируются в соответствии с процессом кодирования, определённым одним из согласованных синтаксисов передачи (см. Приложение A).

Каждый фрагмент передаёт свою собственную явную чётную длину (см. Раздел A.4).

Последовательность фрагментов инкапсулированного потока завершается элементом разграничения последовательности (Sequence Delimitation Item), что позволяет поддерживать процессы кодирования, в которых результирующая длина всего потока неизвестна до тех пор, пока он не будет полностью закодирован. Инкапсулированные форматы поддерживают как однокадровые, так и многокадровые изображения (как определено в PS3.3). Должен присутствовать по крайней мере один кадр, и, следовательно, по крайней мере один фрагмент.

Примечание

В зависимости от фрагментируемого инкапсулированного синтаксиса передачи кадр может полностью содержаться в одном фрагменте или может занимать несколько фрагментов для поддержки буферизации при сжатии или чтобы избежать превышения максимального размера фрагмента фиксированной длины. Получатель может обнаружить фрагментацию кадров, сравнивая количество фрагментов (число элементов минус один для Basic Offset Table) с количеством кадров. Получателю могут быть доступны некоторые оптимизации производительности при отсутствии фрагментации кадров, однако реализация, не поддерживающая такую фрагментацию, не соответствует стандарту.
Общий размер инкапсулированного потока, не включая завершающее заполнение в последнем фрагменте, если он известен, может быть закодирован в Encapsulated Pixel Data Value Total Length (7FE0,0003); см. PS3.3 Раздел C.7.6.6 «Multi-frame Module» и PS3.3 Раздел C.7.6.16 «Multi-frame Functional Groups Module».

8.2.1 Сжатие изображений JPEG

DICOM обеспечивает механизм поддержки использования сжатия изображений JPEG посредством инкапсулированного формата. Приложение A определяет ряд синтаксисов передачи, ссылающихся на стандарт JPEG и обеспечивающих ряд схем сжатия без потерь (с сохранением битов) и с потерями.

Примечание

Контекст, в котором использование сжатия медицинских изображений с потерями является клинически приемлемым, выходит за рамки стандарта DICOM. Политики, связанные с выбором соответствующих параметров сжатия (например, коэффициента сжатия) для сжатия JPEG с потерями, также выходят за рамки данного стандарта.

Для облегчения взаимодействия реализаций, соответствующих стандарту DICOM и выбравших использование одного или нескольких синтаксисов передачи для сжатия изображений JPEG, устанавливается следующая политика:

Любая реализация, соответствующая стандарту DICOM и выбравшая поддержку любого из синтаксисов передачи для сжатия изображений JPEG без потерь, должна поддерживать следующее сжатие без потерь: подмножество (горизонтальное предсказание первого порядка [Selection Value 1]) процесса JPEG 14 (DPCM, неиерархический с кодированием Хаффмана) (см. Приложение F).
Любая реализация, соответствующая стандарту DICOM и выбравшая поддержку любого из синтаксисов передачи для 8-битного сжатия изображений JPEG с потерями, должна поддерживать базовое сжатие JPEG (процесс кодирования 1).
Любая реализация, соответствующая стандарту DICOM и выбравшая поддержку любого из синтаксисов передачи для 12-битного сжатия изображений JPEG с потерями, должна поддерживать процесс сжатия JPEG 4.

Примечание

Заявление о соответствии DICOM должно различать, способна ли реализация только принимать или принимать и обрабатывать изображения, закодированные в JPEG (см. PS3.2).

Использование инкапсулированного формата DICOM для поддержки сжатых пиксельных данных JPEG требует, чтобы элементы данных, связанные с кодированием пиксельных данных (например, Photometric Interpretation, Samples per Pixel, Planar Configuration, Bits Allocated, Bits Stored, High Bit, Pixel Representation, Rows, Columns и т.д.), содержали значения, согласованные с характеристиками сжатого потока данных.

Требования при использовании стандартной Photometric Interpretation (т.е. определённого термина из Раздела C.7.6.3.1.2 в PS3.3 ) указаны в Таблице 8.2.1-1 и Таблице 8.2.1-2. Никакие другие значения стандартной Photometric Interpretation не должны использоваться.

Таблица 8.2.1-1. Допустимые значения связанных с данными пикселей атрибутов для синтаксисов передачи JPEG с потерями со стандартными фотометрическими интерпретациями

Photometric Interpretation	Синтаксис передачи	Transfer Syntax UID	Samples per Pixel	Planar Configuration	Bits Allocated	Bits Stored	High Bit
MONOCHROME1 MONOCHROME2	JPEG Baseline	1.2.840.10008.1.2.4.50	1	отсутствует	8	8	7
MONOCHROME1 MONOCHROME2	JPEG Extended	1.2.840.10008.1.2.4.51	1	отсутствует	8	8	7
MONOCHROME1 MONOCHROME2	JPEG Extended	1.2.840.10008.1.2.4.51	1	отсутствует	16	12	11
YBR_FULL_422 RGB	JPEG Baseline	1.2.840.10008.1.2.4.50	3	0	8	8	7

Таблица 8.2.1-2. Допустимые значения связанных с данными пикселей атрибутов для синтаксисов передачи JPEG без потерь со стандартными фотометрическими интерпретациями

Photometric Interpretation	Синтаксис передачи	Transfer Syntax UID	Samples per Pixel	Planar Configuration	Pixel Representation	Bits Allocated	Bits Stored	High Bit
MONOCHROME1 MONOCHROME2	JPEG Lossless, Non-Hierarchical	1.2.840.10008.1.2.4.57	1	отсутствует	0 or 1	8 or 16	1-16	0-15
MONOCHROME1 MONOCHROME2	JPEG Lossless, Non-Hierarchical, SV1	1.2.840.10008.1.2.4.70	1	отсутствует	0 or 1	8 or 16	1-16	0-15
PALETTE COLOR	JPEG Lossless, Non-Hierarchical	1.2.840.10008.1.2.4.57	1	отсутствует	0	8 or 16	1-16	0-15
PALETTE COLOR	JPEG Lossless, Non-Hierarchical, SV1	1.2.840.10008.1.2.4.70	1	отсутствует	0	8 or 16	1-16	0-15
YBR_FULL RGB	JPEG Lossless, Non-Hierarchical	1.2.840.10008.1.2.4.57	3	0	0	8 or 16	1-16	0-15
YBR_FULL RGB	JPEG Lossless, Non-Hierarchical, SV1	1.2.840.10008.1.2.4.70	3	0	0	8 or 16	1-16	0-15

Характеристики пиксельных данных, включённые в JPEG Interchange Format, должны использоваться для декодирования сжатого потока данных.

Если в сжатом потоке данных присутствуют сегменты маркеров APP2 с идентификатором "ICC_PROFILE" (как определено в Приложении B [ISO 15076-1]), их объединённое значение должно быть идентично значению атрибута ICC Profile (0028,2000), если он присутствует, за исключением заполнения.

Примечание

Ранее эти требования формулировались в терминах «несжатых Pixel Data, из которых был получен сжатый поток данных». Однако, поскольку форма «исходного» несжатого потока данных могла отличаться в разных реализациях, теперь это требование сформулировано в терминах согласованности с тем, что инкапсулировано.

При декомпрессии, если характеристики, явно указанные в сжатом потоке данных (например, пространственная субдискретизация, количество компонентов или планарная конфигурация), не согласуются с характеристиками, указанными в элементах данных DICOM, для управления декомпрессией должны использоваться характеристики, явно указанные в сжатом потоке данных. Элементы данных DICOM, в случае несогласованности, могут рассматриваться как рекомендации относительно формы, в которой мог бы быть закодирован несжатый Data Set, с учётом общих и специфичных для IOD правил для несжатых Photometric Interpretation и Planar Configuration, которые могут потребовать преобразования декомпрессированных данных в одну из допустимых форм.
Те характеристики, которые явно не указаны в сжатом потоке данных (например, цветовое пространство сжатых компонентов, которое не указано в JPEG Interchange Format) или не подразумеваются определением схемы сжатия (например, в JPEG всегда используется формат без знака), могут быть определены из элемента данных DICOM во включающем наборе данных. Например, Photometric Interpretation "YBR_FULL_422" описывает цветовое пространство, обычно используемое для сжатия изображений с потерями с помощью JPEG. Использование цветового пространства RGB для сжатия с потерями является необычным, поскольку не используется преимущество корреляции между красным, зелёным и синим компонентами (например, яркости), и достигается плохое сжатие; однако для некоторых приложений это разрешено, например, для изображений микроскопии всего препарата (Whole Slide Microscopy Images), чтобы обеспечить преобразование в DICOM из проприетарных форматов без потерь из-за преобразования цветового пространства.
JPEG Interchange Format отличается от JPEG File Interchange Format (JFIF). JPEG Interchange Format определён в [ISO/IEC 10918-1] раздел 4.9.1 и относится к включению таблиц декодирования, в отличие от "сокращённого формата" (abbreviated format), в котором эти таблицы не передаются (и предполагается, что декодер уже имеет их). JPEG Interchange Format НЕ определяет цветовое пространство. JPEG File Interchange Format, не являющийся частью исходного стандарта JPEG, но определённый в [ECMA TR-098] и [ISO/IEC 10918-5], часто используется для хранения битовых потоков JPEG в потребительских форматах файлов и включает возможность указания цветового пространства компонентов. Сегмент маркера JFIF APP0 НЕ обязательно должен присутствовать в инкапсулированных битовых потоках JPEG в DICOM, и на него не следует полагаться для распознавания цветового пространства. Его присутствие не запрещено (в отличие от информации JP2 для синтаксисов передачи JPEG 2000), однако рекомендуется, чтобы он отсутствовал.
Если процесс сжатия не способен закодировать определённую форму представления пиксельных данных (например, JPEG не может кодировать числа со знаком, только беззнаковые целые), то в идеале в процесс сжатия должна поступать только соответствующая форма. Однако для определённых характеристик, описанных в элементах данных DICOM, но не описанных явно в сжатом потоке данных (таких как Pixel Representation), элемент данных DICOM следует считать описывающим то, что было сжато (например, пиксельные данные действительно следует интерпретировать как знаковые, если это указано в Pixel Representation).
Элементы данных DICOM не должны описывать характеристики, выходящие за пределы возможностей используемой схемы сжатия. Например, процессы JPEG с потерями ограничены 12 битами, следовательно, значение Bits Stored должно быть 12 или менее. Bits Allocated не имеет значения и, вероятно, ограничивается Information Object Definition в PS3.3 значениями 8 или 16. Кроме того, сжатые потоки данных JPEG всегда используют формат color-by-pixel и должны быть указаны как таковые (однако декодер может по существу игнорировать этот элемент данных, так как значение для сжатых данных JPEG уже известно).
Если сжатые пиксельные данные JPEG распаковываются и перекодируются в собственном (несжатом) виде, то элементы данных, связанные с кодированием пиксельных данных, обновляются соответствующим образом. Если цветовые компоненты преобразуются из YBR_FULL_422 в RGB во время распаковки и перекодирования в собственный формат, Photometric Interpretation будет изменена на RGB в наборе данных с собственным кодированием.

8.2.2 Сжатие изображений с кодированием длин серий (RLE)

DICOM обеспечивает механизм поддержки использования сжатия изображений с кодированием длин серий (RLE), которое представляет собой побайтовую схему сжатия без потерь через инкапсулированный формат (см. PS3.3 данного стандарта). Приложение G определяет сжатие изображений RLE и его синтаксис передачи.

Примечание

Алгоритм сжатия изображений RLE, описанный в Приложении G, представляет собой сжатие, используемое в спецификации TIFF 6.0, известное как схема "PackBits".

Использование инкапсулированного формата DICOM для поддержки сжатых пиксельных данных RLE требует, чтобы элементы данных, связанные с кодированием пиксельных данных (например, Photometric Interpretation, Samples per Pixel, Planar Configuration, Bits Allocated, Bits Stored, High Bit, Pixel Representation, Rows, Columns и т.д.), содержали значения, согласованные со сжатыми данными.

Требования при использовании стандартной Photometric Interpretation (т.е. определённого термина из PS3.3 C.7.6.3.1.2) указаны в Таблице 8.2.2-1. Никакие другие значения стандартной Photometric Interpretation не должны использоваться.

Таблица 8.2.2-1. Допустимые значения связанных с данными пикселей атрибутов для сжатия RLE со стандартными фотометрическими интерпретациями

Photometric Interpretation	Samples per Pixel	Planar Configuration	Pixel Representation	Bits Allocated	Bits Stored	High Bit
MONOCHROME1 MONOCHROME2	1	отсутствует	0 or 1	1, 8 or 16	1-16	0-15
PALETTE COLOR	1	отсутствует	0	8 or 16	1-16	0-15
YBR_FULL	3	0 or 1	0	8 or 16	1-16	0-15
RGB	3	0 or 1	0	8 or 16	1-16	0-15

Примечание

Эти требования ранее были сформулированы в терминах "несжатых пиксельных данных, из которых были получены сжатые данные". Однако, поскольку форма "исходного" несжатого потока данных может различаться между разными реализациями, это требование теперь формулируется в терминах согласованности с тем, что инкапсулировано.
Те характеристики, которые не подразумеваются определением схемы сжатия (например, в RLE всегда используется формат color-by-plane), могут быть определены из элемента данных DICOM во включающем наборе данных. Например, Photometric Interpretation "YBR_FULL" описывает цветовое пространство, обычно используемое для сжатия изображений без потерь с помощью RLE. Использование цветового пространства RGB для сжатия RLE является необычным, поскольку не используется преимущество корреляции между красным, зелёным и синим компонентами (например, яркости), и достигается плохое сжатие (однако следует отметить, что преобразование из RGB в YBR_FULL само по себе является сжатием с потерями. В будущем может быть предложена новая фотометрическая интерпретация, которая позволяет сжатие без потерь при преобразовании из RGB, а также приводит к лучшим коэффициентам сжатия RLE).
Элементы данных DICOM не должны описывать характеристики, выходящие за пределы возможностей используемой схемы сжатия. Например, сжатые потоки данных RLE (с использованием алгоритма, предписанного стандартом DICOM) всегда используют формат color-by-plane.
Если сжатые пиксельные данные RLE распаковываются и перекодируются в собственном (несжатом) виде, то элементы данных, связанные с кодированием пиксельных данных, обновляются соответствующим образом. Если цветовые компоненты преобразуются из YBR_FULL в RGB во время распаковки и перекодирования в собственный формат, Photometric Interpretation будет изменена на RGB в наборе данных с собственным кодированием. Однако разрешается оставить цветовые компоненты YBR_FULL непреобразованными, но распакованными в собственном формате; в этом случае Photometric Interpretation в наборе данных с собственным кодированием будет YBR_FULL.
Bits Allocated (0028,0100), равное 1 для монохромных изображений, поддерживает сжатие пиксельных данных IOD сегментации с Segmentation Type (0062,0001), равным BINARY.

8.2.3 Сжатие изображений JPEG-LS

DICOM обеспечивает механизм поддержки использования сжатия изображений JPEG-LS посредством инкапсулированного формата. Приложение A определяет ряд синтаксисов передачи, ссылающихся на стандарт JPEG-LS и обеспечивающих ряд схем сжатия без потерь (с сохранением битов) и с потерями (почти без потерь).

Примечание

Контекст, в котором использование сжатия медицинских изображений с потерями (почти без потерь) является клинически приемлемым, выходит за рамки стандарта DICOM. Политики, связанные с выбором соответствующих параметров сжатия (например, коэффициента сжатия) для сжатия JPEG-LS с потерями (почти без потерь), также выходят за рамки данного стандарта.

Использование инкапсулированного формата DICOM для поддержки сжатых пиксельных данных JPEG-LS требует, чтобы элементы данных, связанные с кодированием пиксельных данных (например, Photometric Interpretation, Samples per Pixel, Planar Configuration, Bits Allocated, Bits Stored, High Bit, Pixel Representation, Rows, Columns и т.д.), содержали значения, согласованные с характеристиками сжатого потока данных. Характеристики пиксельных данных, включённые в JPEG-LS Interchange Format, должны использоваться для декодирования сжатого потока данных.

Требования при использовании стандартной Photometric Interpretation (т.е. определённого термина из PS3.3 C.7.6.3.1.2) указаны в Таблице 8.2.3-1. Никакие другие значения стандартной Photometric Interpretation не должны использоваться.

Таблица 8.2.3-1. Допустимые значения связанных с данными пикселей атрибутов для сжатия JPEG-LS со стандартными фотометрическими интерпретациями

Photometric Interpretation	Синтаксис передачи	Transfer Syntax UID	Samples per Pixel	Planar Configuration	Pixel Representation	Bits Allocated	Bits Stored	High Bit
MONOCHROME1 MONOCHROME2	JPEG-LS Lossless	1.2.840.10008.1.2.4.80	1	отсутствует	0 or 1	8 or 16	2-16	1-15
MONOCHROME1 MONOCHROME2	JPEG-LS Lossy (Near-Lossless)	1.2.840.10008.1.2.4.81	1	отсутствует	0 or 1	8 or 16	2-16	1-15
PALETTE COLOR	JPEG-LS Lossless	1.2.840.10008.1.2.4.80	1	отсутствует	0	8 or 16	2-16	1-15
YBR_FULL	JPEG-LS Lossless	1.2.840.10008.1.2.4.80	3	0	0	8 or 16	2-16	1-15
YBR_FULL	JPEG-LS Lossy (Near-Lossless)	1.2.840.10008.1.2.4.81	3	0	0	8 or 16	2-16	1-15
RGB	JPEG-LS Lossless	1.2.840.10008.1.2.4.80	3	0	0	8 or 16	2-16	1-15
RGB	JPEG-LS Lossy (Near-Lossless)	1.2.840.10008.1.2.4.81	3	0	0	8 or 16	2-16	1-15

Примечание

См. также примечания в Разделе 8.2.1.
В настоящее время в DICOM не определена Photometric Interpretation преобразования цвета, специфичная для JPEG-LS. Приложение F стандарта ISO 14495-2 описывает "Sample transformation for inverse colour transform" и сегмент маркера для кодирования его параметров, однако неизвестно о его реализации. Общей практикой является сжатие компонентов RGB без преобразования, что снижает эффективность сжатия, и передача Photometric Interpretation как RGB. Хотя Photometric Interpretation YBR_RCT и преобразование компонентов могли бы теоретически использоваться, при отсутствии DC-сдвига это приводит к необходимости кодирования знаковых значений, которые не поддерживаются JPEG-LS.
Если сжатые пиксельные данные JPEG-LS распаковываются и перекодируются в собственном (несжатом) виде, то элементы данных, связанные с кодированием пиксельных данных, обновляются соответствующим образом. Если цветовые компоненты преобразуются из любой другой Photometric Interpretation в RGB во время распаковки и перекодирования в собственный формат, Photometric Interpretation будет изменена на RGB в наборе данных с собственным кодированием.
Нижний предел 2 для Bits Stored (0028,0101) отражает минимальную точность выборки JPEG-LS, равную 2.

Значение Planar Configuration (0028,0006) не имеет значения, поскольку способ кодирования компонентов указан в битовом потоке JPEG-LS как покомпонентное, построчное или по выборке чередование, поэтому оно должно быть установлено в 0.

8.2.4 Сжатие изображений JPEG 2000

DICOM обеспечивает механизм поддержки использования сжатия изображений JPEG 2000 посредством инкапсулированного формата. Приложение A определяет ряд синтаксисов передачи, ссылающихся на стандарт JPEG 2000 и обеспечивающих схемы сжатия без потерь (с сохранением битов) и с потерями.

Примечание

Контекст, в котором использование сжатия медицинских изображений с потерями является клинически приемлемым, выходит за рамки стандарта DICOM. Политики, связанные с выбором соответствующих параметров сжатия (например, коэффициента сжатия) для сжатия JPEG 2000 с потерями, также выходят за рамки данного стандарта.

Использование инкапсулированного формата DICOM для поддержки сжатых пиксельных данных JPEG 2000 требует, чтобы элементы данных, связанные с кодированием пиксельных данных (например, Photometric Interpretation, Samples per Pixel, Planar Configuration, Bits Allocated, Bits Stored, High Bit, Pixel Representation, Rows, Columns и т.д.), содержали значения, согласованные с характеристиками сжатого потока данных. Характеристики пиксельных данных, включённые в битовый поток JPEG 2000, должны использоваться для декодирования сжатого потока данных.

Требования при использовании стандартной Photometric Interpretation (т.е. определённого термина из PS3.3 C.7.6.3.1.2) указаны в Таблице 8.2.4-1. Никакие другие значения стандартной Photometric Interpretation не должны использоваться.

Таблица 8.2.4-1. Допустимые значения связанных с данными пикселей атрибутов для синтаксисов передачи JPEG 2000 со стандартными фотометрическими интерпретациями

Photometric Interpretation	Синтаксис передачи	Transfer Syntax UID	Samples per Pixel	Planar Configuration	Pixel Representation	Bits Allocated	Bits Stored	High Bit
MONOCHROME1 MONOCHROME2	JPEG 2000 (Lossless Only)	1.2.840.10008.1.2.4.90	1	отсутствует	0 or 1	1, 8, 16, 24, 32 or 40	1-38	0-37
MONOCHROME1 MONOCHROME2	JPEG 2000	1.2.840.10008.1.2.4.91	1	отсутствует	0 or 1	1, 8, 16, 24, 32 or 40	1-38	0-37
PALETTE COLOR	JPEG 2000 (Lossless Only)	1.2.840.10008.1.2.4.90	1	отсутствует	0	8 or 16	1-16	0-15
YBR_RCT	JPEG 2000 (Lossless Only)	1.2.840.10008.1.2.4.90	3	0	0	8, 16, 24, 32 or 40	1-38	0-37
YBR_RCT	JPEG 2000	1.2.840.10008.1.2.4.91	3	0	0	8, 16, 24, 32 or 40	1-38	0-37
YBR_ICT	JPEG 2000	1.2.840.10008.1.2.4.91	3	0	0	8, 16, 24, 32 or 40	1-38	0-37
RGB	JPEG 2000 (Lossless Only)	1.2.840.10008.1.2.4.90	3	0	0	8, 16, 24, 32 or 40	1-38	0-37
RGB	JPEG 2000	1.2.840.10008.1.2.4.91	3	0	0	8, 16, 24, 32 or 40	1-38	0-37
YBR_FULL	JPEG 2000 (Lossless Only)	1.2.840.10008.1.2.4.90	3	0	0	8, 16, 24, 32 or 40	1-38	0-37
YBR_FULL	JPEG 2000	1.2.840.10008.1.2.4.91	3	0	0	8, 16, 24, 32 or 40	1-38	0-37

Примечание

Эти требования сформулированы в терминах согласованности с тем, что инкапсулировано, а не в терминах несжатых пиксельных данных, из которых мог быть получен сжатый поток данных.

При распаковке, если характеристики, явно указанные в сжатом потоке данных, не согласуются с характеристиками, указанными в элементах данных DICOM, для управления распаковкой должны использоваться характеристики, явно указанные в сжатом потоке данных. Элементы данных DICOM, если они не согласуются, могут рассматриваться как предложения о форме, в которой может быть закодирован несжатый набор данных, с учётом общих и специфичных для IOD правил для несжатой Photometric Interpretation и Planar Configuration, которые могут требовать преобразования распакованных данных в одну из разрешённых форм.

Битовый поток JPEG 2000 указывает, было ли применено обратимое или необратимое многокомпонентное (цветовое) преобразование ([ISO/IEC 15444-1] Приложение G), если таковое было. Если многокомпонентное преобразование не применялось, то компоненты должны соответствовать указанным в атрибуте DICOM Photometric Interpretation (0028,0004). Если было применено обратимое многокомпонентное преобразование JPEG 2000 Part 1, то атрибут DICOM Photometric Interpretation (0028,0004) должен быть YBR_RCT. Если было применено необратимое многокомпонентное преобразование JPEG 2000 Part 1, то атрибут DICOM Photometric Interpretation (0028,0004) должен быть YBR_ICT.

Примечание

Например, может присутствовать один компонент, и Photometric Interpretation (0028,0004) может быть MONOCHROME2.
Применение обратимого многокомпонентного преобразования JPEG 2000 Part 1 сигнализируется в битовом потоке JPEG 2000 значением 1 вместо 0 в поле SGcod Multiple component transformation type сегмента маркера COD ([ISO/IEC 15444-1] Таблица A.17). Никакое другое значение Photometric Interpretation, кроме YBR_RCT или YBR_ICT, не допускается, когда SGcod Multiple component transformation type равно 1.
Хотя это было бы необычно, не использовало бы преимущество корреляции между красным, зелёным и синим компонентами и не достигло бы эффективного сжатия, Photometric Interpretation RGB может быть указана при условии, что многокомпонентное преобразование ([ISO/IEC 15444-1] Приложение G) не указано битовым потоком JPEG 2000. Для некоторых приложений использование RGB разрешено, например, для изображений микроскопии всего препарата (Whole Slide Microscopy Images), чтобы обеспечить преобразование в DICOM из проприетарных форматов без потерь из-за преобразования цветового пространства. Альтернативные методы декорреляции цветовых компонентов, помимо указанных в ([ISO/IEC 15444-1] Приложение G), разрешены, как определено в PS3.3, такие как Photometric Interpretation YBR_FULL; это может быть полезно при преобразовании существующих пиксельных данных YBR_FULL (например, в другом синтаксисе передачи) без дополнительных потерь.

В любом случае (Photometric Interpretation RGB или YBR_FULL) значение SGcod Multiple component transformation type будет равно 0.

PS3.3 может ограничивать значения Photometric Interpretation для конкретных IOD.
Несмотря на применение многокомпонентного цветового преобразования и его отражение в атрибуте Photometric Interpretation, "цветовое пространство" остаётся неопределённым. В настоящее время не существует способа передачи "стандартных цветовых пространств" ни через фиксированные значения (например, sRGB), ни через ICC-профили. В частности, обратите внимание, что заголовок файла JPP не передаётся в битовом потоке JPEG 2000, инкапсулированном в DICOM.
Если сжатые пиксельные данные JPEG 2000 распаковываются и перекодируются в собственном (несжатом) виде, то элементы данных, связанные с кодированием пиксельных данных, обновляются соответствующим образом. Если цветовые компоненты преобразуются из YBR_ICT или YBR_RCT в RGB во время распаковки и перекодирования в собственный формат, Photometric Interpretation будет изменена на RGB в наборе данных с собственным кодированием.
Верхний предел 40 для Bits Allocated (0028,0100) и 38 для Bits Stored (0028,0101) отражает максимальную точность выборки JPEG 2000, равную 38, и требование DICOM описывать Bits Allocated (0028,0100) как кратные байтам (октетам).
Bits Allocated (0028,0100), равное 1 для монохромных изображений, поддерживает сжатие пиксельных данных IOD сегментации с Segmentation Type (0062,0001), равным BINARY.

Битовый поток JPEG 2000 способен кодировать как знаковые, так и беззнаковые пиксельные значения, поэтому значение Pixel Representation (0028,0103) может быть 0 или 1 для монохромных Photometric Interpretation в зависимости от того, что было закодировано (как указано в сегменте маркера SIZ в параметре precision and sign of component).

Значение Planar Configuration (0028,0006) не имеет значения, поскольку способ кодирования компонентов указан в стандарте JPEG 2000, поэтому оно должно быть установлено в 0.

8.2.5 Сжатие видео MPEG2 Main Profile / Main Level

DICOM обеспечивает механизм поддержки использования сжатия видео MPEG2 Main Profile / Main Level посредством инкапсулированного формата. Приложение A определяет нефрагментируемые и фрагментируемые инкапсулированные синтаксисы передачи, ссылающиеся на стандарт MPEG2 Main Profile / Main Level.

Примечание

Сжатие MPEG2 по своей природе является сжатием с потерями. Контекст, в котором использование сжатия медицинских изображений с потерями является клинически приемлемым, выходит за рамки стандарта DICOM. Политики, связанные с выбором соответствующих параметров сжатия (например, коэффициента сжатия) для MPEG2 Main Profile / Main Level, также выходят за рамки данного стандарта.

Использование инкапсулированного формата DICOM для поддержки сжатых пиксельных данных MPEG2 Main Profile / Main Level требует, чтобы элементы данных, связанные с кодированием пиксельных данных (например, Photometric Interpretation, Samples per Pixel, Planar Configuration, Bits Allocated, Bits Stored, High Bit, Pixel Representation, Rows, Columns и т.д.), содержали значения, согласованные с характеристиками сжатого потока данных, с некоторыми конкретными исключениями, отмеченными ниже. Характеристики пиксельных данных, включённые в битовый поток MPEG2 Main Profile / Main Level, должны использоваться для декодирования сжатого потока данных.

Примечание

Битовый поток MPEG2 Main Profile / Main Level указывает, было ли применено обратимое или необратимое многокомпонентное (цветовое) преобразование, если таковое было. Если многокомпонентное преобразование не применялось, то компоненты должны соответствовать указанным в атрибуте DICOM Photometric Interpretation (0028,0004). MPEG2 Main Profile / Main Level применяет необратимое многокомпонентное преобразование, поэтому атрибут DICOM Photometric Interpretation (0028,0004) должен быть YBR_PARTIAL_420 в случае многокомпонентных данных и MONOCHROME2 в случае однокомпонентных данных (хотя сам битовый поток MPEG2 всегда кодируется как три компонента: один сигнал яркости и два сигнала цветности).

Примечание

Если сжатые пиксельные данные MPEG2 распаковываются и перекодируются в собственном (несжатом) виде, то элементы данных, связанные с кодированием пиксельных данных, обновляются соответствующим образом. Если цветовые компоненты преобразуются из YBR_PARTIAL_420 в RGB во время распаковки и перекодирования в собственный формат, Photometric Interpretation будет изменена на RGB в наборе данных с собственным кодированием.
MPEG2 предлагает некоторые видеоформаты. Каждый из указанных стандартов используется на разных рынках, включая: ITU-R BT.470-2 System M для SD NTSC и ITU-R BT.470-2 System B/G для SD PAL/SECAM. Система на основе PAL, следовательно, должна основываться на ITU-BT.470 System B для каждого из следующих параметров: Color Primaries, Transfer Characteristic (гамма) и матричные коэффициенты, и должна принимать значение 5, как определено в [ISO/IEC 13818-2].

Значение Planar Configuration (0028,0006) не имеет значения, поскольку способ кодирования компонентов указан в стандарте MPEG2 Main Profile / Main Level, поэтому оно должно быть установлено в 0.

В сводке:

Samples per Pixel (0028,0002) должен быть 3
Photometric Interpretation (0028,0004) должен быть YBR_PARTIAL_420
Bits Allocated (0028,0100) должен быть 8
Bits Stored (0028,0101) должен быть 8
High Bit (0028,0102) должен быть 7
Pixel Representation (0028,0103) должен быть 0
Planar Configuration (0028,0006) должен быть 0
Rows (0028,0010), Columns (0028,0011), Cine Rate (0018,0040) и Frame Time (0018,1063) или Frame Time Vector (0018,1065) должны быть согласованы с ограничениями Main Profile / Main Level, как указано в Таблице 8-1.

Таблица 8-1. Атрибуты строк и столбцов синтаксиса передачи изображений MPEG2 Main Profile / Main Level

Тип видео	Пространственное разрешение	Частота кадров (см. Примечание 4)	Время кадра (см. Примечание 5)	Максимум строк	Максимум столбцов
525-line NTSC	Полное	30	33.33 мс	480	720
625-line PAL	Полное	25	40.0 мс	576	720

Тип видео

Пространственное разрешение

Частота кадров

(см. Примечание 4)

Время кадра

(см. Примечание 5)

Максимум строк

Максимум столбцов

525-line NTSC

Полное

33.33 мс

480

720

625-line PAL

Полное

40.0 мс

576

720

Примечание

Хотя возможны различные комбинации значений Rows и Columns при соблюдении указанных выше максимальных значений, рекомендуется сохранять типичное соотношение ширины изображения к высоте 4:3, чтобы избежать деформации изображения декодерами MPEG2. Распространённым способом сохранения соотношения ширины к высоте является заполнение изображения чёрными областями с обеих сторон.
«Половинное» определение изображений (240x352 и 288x352 для NTSC и PAL соответственно) всегда поддерживается декодерами.
Main Profile / Main Level допускает различные соотношения сторон дисплея и пикселей, включая использование квадратных пикселей, а также использование неквадратных пикселей с соотношениями сторон дисплея 4:3 и 16:9. DICOM не устанавливает дополнительных ограничений помимо предусмотренных в Main Profile / Main Level. Все комбинации, разрешённые Main Profile / Main Level, являются допустимыми и должны поддерживаться всеми декодерами DICOM.
Фактическая частота кадров для NTSC MPEG2 составляет приблизительно 29.97 кадров/сек.
Номинальное время кадра приводится для включения в атрибуты DICOM Cine Module и должно рассчитываться на основе фактической частоты кадров.

Для нефрагментируемого инкапсулированного синтаксиса передачи один фрагмент должен содержать весь поток MPEG2.

Для фрагментируемого инкапсулированного синтаксиса передачи поток может быть разделён на несколько фрагментов.

Примечание

Если видеопоток превышает максимальную длину одного фрагмента (2^32-2 байта), он может быть отправлен с использованием фрагментируемого инкапсулированного синтаксиса передачи. В качестве альтернативы он может быть отправлен с использованием нефрагментируемого инкапсулированного синтаксиса передачи в виде нескольких экземпляров SOP, но каждый экземпляр SOP будет содержать независимый и воспроизводимый битовый поток и не будет зависеть от закодированного битового потока в других (предыдущих) экземплярах. Способ связи таких отдельных экземпляров не указан в стандарте, но могут использоваться такие механизмы, как группировка в одну серию и ссылки на предыдущие экземпляры с использованием Referenced Image Sequence.
Фрагментируемые инкапсулированные синтаксисы передачи позволяют создавать потоки практически неограниченной длины; единственным налагаемым ограничением является максимальное Number of Frames (0028,0008), равное 2^31-1 кадров (наибольшее положительное значение в VR Integer String).

Basic Offset Table должен быть пустым (присутствовать, но иметь нулевую длину).

Примечание

Basic Offset Table не используется, поскольку MPEG2 содержит собственный механизм описания навигации по кадрам. Для обеспечения декодирования только части последовательности MPEG2 управляет заголовком в любой группе изображений (GOP), содержащим time_code — 25-битное целое число, содержащее следующие поля: drop_frame_flag, time_code_hours, time_code_minutes, marker_bit, time_code_seconds и time_code_pictures.

Формат контейнера для видеопотока не ограничен. Например, это может быть 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) (см. [ISO/IEC 13818-1]) или контейнер MPEG-4 (MP4) (см. [ISO/IEC 14496-12] и [ISO/IEC 14496-14]).

Любые аудиокомпоненты, присутствующие в потоке MPEG, должны соответствовать следующим ограничениям:

Стандарт аудио CBR MPEG-1 LAYER III (MP3)
до 24 бит
32 кГц, 44.1 кГц или 48 кГц для основного канала (дополнительные каналы могут оцифровываться с половинной частотой, как определено в стандарте)
один основной моно- или стереоканал и, дополнительно, один или несколько дополнительных каналов

Примечание

MPEG-1 Layer III стандартизирован в части 3 стандарта MPEG-1 (см. [ISO/IEC 11172-3]).
Хотя MPEG описывает каждый канал как включающий до 5 сигналов (например, для эффектов объёмного звучания), рекомендуется ограничить каждый из двух каналов до 2 сигналов (стерео).

8.2.6 Сжатие видео MPEG2 Main Profile / High Level

MPEG2 Main Profile / High Level соответствует тому, что широко известно как HDTV («High Definition Television», телевидение высокой чёткости). DICOM обеспечивает механизм поддержки использования сжатия видео MPEG2 Main Profile / High Level посредством инкапсулированного формата. Приложение A определяет нефрагментируемые и фрагментируемые инкапсулированные синтаксисы передачи, ссылающиеся на стандарт MPEG2 Main Profile / High Level.

Примечание

Сжатие MPEG2 по своей природе является сжатием с потерями. Контекст, в котором использование сжатия медицинских изображений с потерями является клинически приемлемым, выходит за рамки стандарта DICOM. Политики, связанные с выбором соответствующих параметров сжатия (например, коэффициента сжатия) для MPEG2 Main Profile / High Level, также выходят за рамки данного стандарта.

Использование инкапсулированного формата DICOM для поддержки сжатых пиксельных данных MPEG2 Main Profile / High Level требует, чтобы элементы данных, связанные с кодированием пиксельных данных (например, Photometric Interpretation, Samples per Pixel, Planar Configuration, Bits Allocated, Bits Stored, High Bit, Pixel Representation, Rows, Columns и т.д.), содержали значения, согласованные с характеристиками сжатого потока данных, с некоторыми конкретными исключениями, отмеченными ниже. Характеристики пиксельных данных, включённые в битовый поток MPEG2 Main Profile / High Level, должны использоваться для декодирования сжатого потока данных.

Примечание

Если сжатые пиксельные данные MPEG2 распаковываются и перекодируются в собственном (несжатом) виде, то элементы данных, связанные с кодированием пиксельных данных, обновляются соответствующим образом. Если цветовые компоненты преобразуются из YBR_PARTIAL_420 в RGB во время распаковки и перекодирования в собственный формат, Photometric Interpretation будет изменена на RGB в наборе данных с собственным кодированием.

Требования:

Planar Configuration (0028,0006) должен быть 0

Примечание

Значение Planar Configuration (0028,0006) не имеет значения, поскольку способ кодирования компонентов указан в стандарте MPEG2, поэтому оно установлено в 0.
Samples per Pixel (0028,0002) должен быть 3
Photometric Interpretation (0028,0004) должен быть YBR_PARTIAL_420 или MONOCHROME2
Bits Allocated (0028,0100) должен быть 8
Bits Stored (0028,0101) должен быть 8
High Bit (0028,0102) должен быть 7
Pixel Representation (0028,0103) должен быть 0
Rows (0028,0010) должен быть либо 720, либо 1080
Columns (0028,0011) должен быть 1280, если Rows равно 720, или 1920, если Rows равно 1080.
Значение MPEG2 aspect_ratio_information должно быть 0011 в инкапсулированном потоке данных MPEG2, что соответствует «Display Aspect Ratio» (DAR) 16:9.
Атрибут DICOM Pixel Aspect Ratio (0028,0034) должен отсутствовать. Это соответствует «Sampling Aspect Ratio» (SAR) 1:1.
Cine Rate (0018,0040) и Frame Time (0018,1063) или Frame Time Vector (0018,1065) должны быть согласованы с ограничениями Main Profile / High Level, как указано в Таблице 8-2.

Таблица 8-2. Атрибуты частоты кадров синтаксиса передачи изображений MPEG2 Main Profile / High Level

Тип видео	Слой пространственного разрешения	Частота кадров (см. Примечание 2)	Время кадра (см. Примечание 3)
30 Hz HD	Одиночный уровень, улучшение	30	33.33 мс
25 Hz HD	Одиночный уровень, улучшение	25	40.0 мс
60 Hz HD	Одиночный уровень, улучшение	60	16.67 мс
50 Hz HD	Одиночный уровень, улучшение	50	20.00 мс

Примечание

Требования к строкам и столбцам направлены на максимизацию совместимости между программными средами и широко доступными аппаратными реализациями кодеров/декодеров MPEG2. Если исходное изображение имеет меньшее значение, оно должно быть переформатировано соответствующим образом путём масштабирования и/или заполнения пикселей перед кодированием MPEG2.
Частота кадров записывающей камеры для '30 Hz HD' MPEG2 может быть либо 30, либо 30/1.001 (приблизительно 29.97) кадров/сек. Аналогично, частота кадров в случае 60 Hz может быть либо 60, либо 60/1.001 (приблизительно 59.94) кадров/сек. Это может привести к небольшим несоответствиям между временной шкалой видео и реальным временем.
Frame Time (0018,1063) может быть рассчитан на основе частоты кадров записывающей камеры. Время кадра 33.367 мс соответствует 29.97 кадрам в секунду.
Значение chroma_format для этого профиля и уровня определено MPEG как 4:2:0.
Примеры разрешений экрана, поддерживаемых MPEG2 Main Profile / High Level, показаны в Таблице 8-3. Частоты кадров 50 Hz и 60 Hz (прогрессивная развёртка) при максимальном разрешении 1080 на 1920 не поддерживаются Main Profile / High Level. Чересстрочная развёртка при максимальном разрешении поддерживается при частоте полей 50 Hz или 60 Hz, что соответствует частоте кадров 25 Hz или 30 Hz соответственно, как описано в Таблице 8-2.
Декодер MPEG2 Main Profile / High Level способен декодировать битовые потоки, соответствующие более низким уровням. Они включают битовые потоки 1080 на 1440 стандарта MP@H-14 и битовые потоки Main Level, используемые в существующем синтаксисе передачи MPEG2 Main Profile / Main Level в IOD Visible Light.
MP@H-14 не поддерживается данным синтаксисом передачи.
Ограничение DAR до 16:9 требуется для обеспечения совместимости из-за ограничений в широко доступных аппаратных реализациях чипсетов для MPEG2 Main Profile / High Level.

Таблица 8-3. Примеры разрешения экрана MPEG2 Main Profile / High Level

Строки	Столбцы	Частота кадров	Тип видео	Progressive or Interlace
1080	1920	25	25 Hz HD	P
1080	1920	29.97, 30	30 Hz HD	P
1080	1920	25	25 Hz HD	I
1080	1920	29.97, 30	30 Hz HD	I
720	1280	25	25 Hz HD	P
720	1280	29.97, 30,	30 Hz HD	P
720	1280	50	50 Hz HD	P
720	1280	59.94, 60	60 Hz HD	P

Для нефрагментируемого инкапсулированного синтаксиса передачи один фрагмент должен содержать весь битовый поток MPEG2.

Примечание

Если видеопоток превышает максимальную длину одного фрагмента (2^32-2 байта), он может быть отправлен с использованием фрагментируемого инкапсулированного синтаксиса передачи. В качестве альтернативы он может быть отправлен с использованием нефрагментируемого инкапсулированного синтаксиса передачи в виде нескольких экземпляров SOP, но каждый экземпляр SOP будет содержать независимый и воспроизводимый битовый поток и не будет зависеть от закодированного битового потока в других (предыдущих) экземплярах. Способ связи таких отдельных экземпляров не указан в стандарте, но могут использоваться такие механизмы, как группировка в одну серию и ссылки на предыдущие экземпляры с использованием Referenced Image Sequence.
Фрагментируемые инкапсулированные синтаксисы передачи позволяют создавать потоки практически неограниченной длины; единственным налагаемым ограничением является максимальное Number of Frames (0028,0008), равное 2^31-1 кадров (наибольшее положительное значение в VR Integer String).

Basic Offset Table в Pixel Data (7FE0,0010) должен быть пустым (присутствовать, но иметь нулевую длину).

Примечание

Любые аудиокомпоненты, присутствующие в битовом потоке MPEG2 Main Profile / High Level, должны соответствовать ограничениям, указанным для MPEG2 Main Profile / Main Level в Разделе 8.2.5.

8.2.7 Сжатие видео MPEG-4 AVC/H.264 High Profile / Level 4.1

MPEG-4 AVC/H.264 High Profile / Level 4.1 соответствует тому, что широко известно как HDTV («High Definition Television», телевидение высокой чёткости). DICOM обеспечивает механизм поддержки использования сжатия изображений MPEG-4 AVC/H.264 посредством инкапсулированного формата. Приложение A определяет нефрагментируемые и фрагментируемые инкапсулированные синтаксисы передачи, ссылающиеся на стандарт MPEG-4 AVC/H.264.

Примечание

Сжатие MPEG-4 AVC/H.264 / High Profile по своей природе является сжатием с потерями. Контекст, в котором использование сжатия медицинских изображений с потерями является клинически приемлемым, выходит за рамки стандарта DICOM. Политики, связанные с выбором соответствующих параметров сжатия (например, коэффициента сжатия) для MPEG-4 AVC/H.264 High Profile / Level 4.1, также выходят за рамки данного стандарта.

Использование инкапсулированного формата DICOM для поддержки сжатых пиксельных данных MPEG-4 AVC/H.264 требует, чтобы элементы данных, связанные с кодированием пиксельных данных (например, Photometric Interpretation, Samples per Pixel, Planar Configuration, Bits Allocated, Bits Stored, High Bit, Pixel Representation, Rows, Columns и т.д.), содержали значения, согласованные с характеристиками сжатого потока данных, с некоторыми конкретными исключениями, отмеченными ниже. Характеристики пиксельных данных, включённые в битовый поток MPEG-4 AVC/H.264, должны использоваться для декодирования сжатого потока данных.

Примечание

Если сжатые пиксельные данные MPEG-4 распаковываются и перекодируются в собственном (несжатом) виде, то элементы данных, связанные с кодированием пиксельных данных, обновляются соответствующим образом. Если цветовые компоненты преобразуются из YBR_PARTIAL_420 в RGB во время распаковки и перекодирования в собственный формат, Photometric Interpretation будет изменена на RGB в наборе данных с собственным кодированием.

Требования:

Planar Configuration (0028,0006) должен быть 0
Samples per Pixel (0028,0002) должен быть 3
Photometric Interpretation (0028,0004) должен быть YBR_PARTIAL_420
Bits Allocated (0028,0100) должен быть 8
Bits Stored (0028,0101) должен быть 8
High Bit (0028,0102) должен быть 7
Pixel Representation (0028,0103) должен быть 0
Значение MPEG-4 AVC/H.264 sample aspect_ratio_idc должно быть 1 в инкапсулированном битовом потоке MPEG-4 AVC/H.264, если aspect_ratio_info_present_flag равен 1.
Pixel Aspect Ratio (0028,0034) должен отсутствовать. Это соответствует «Sampling Aspect Ratio» (SAR) 1:1.
Возможные значения Rows (0028,0010), Columns (0028,0011), Cine Rate (0018,0040) и Frame Time (0018,1063) или Frame Time Vector (0018,1065) зависят от используемого синтаксиса передачи.
- Для синтаксиса передачи MPEG-4 AVC/H.264 High Profile / Level 4.1 значения этих элементов данных должны соответствовать High Profile / Level 4.1 стандарта MPEG-4 AVC/H.264 ([ISO/IEC 14496-10]) и быть ограничены квадратным соотношением сторон пикселя.
- Для синтаксиса передачи MPEG-4 AVC/H.264 BD-compatible High Profile / Level 4.1 значения этих элементов данных должны быть указаны в Таблице 8-4.

Таблица 8-4. Значения, разрешённые для MPEG-4 AVC/H.264 BD-compatible High Profile / Level 4.1

Строки	Столбцы	Частота кадров	Тип видео	Прогрессивная или чересстрочная
1080	1920	25	25 Hz HD	I
1080	1920	29.97	30 Hz HD	I
1080	1920	24	24 Hz HD	P
1080	1920	23.976	24 Hz HD	P
720	1280	50	50 Hz HD	P
720	1280	59.94	60 Hz HD	P
720	1280	24	24 Hz HD	P
720	1280	23.976	24 Hz HD	P

Примечание

Значение Planar Configuration (0028,0006) не имеет значения, поскольку способ кодирования компонентов указан в стандарте MPEG-4 AVC/H.264, поэтому оно установлено в 0.
Ограничения на строки и столбцы направлены на максимизацию совместимости между программными средами и широко доступными аппаратными реализациями кодеров/декодеров MPEG-4 AVC/H.264. Исходные изображения с меньшими значениями должны быть переформатированы путём масштабирования и/или заполнения пикселей перед кодированием MPEG-4 AVC/H.264.
Частота кадров записывающей камеры для '30 Hz HD' MPEG-4 AVC/H.264 может быть либо 30, либо 30/1.001 (приблизительно 29.97) кадров/сек. Аналогично, частота кадров в случае 60 Hz может быть либо 60, либо 60/1.001 (приблизительно 59.94) кадров/сек. Это может привести к небольшим несоответствиям между временной шкалой видео и реальным временем. Связь между частотой кадров и временем кадра показана в Таблице 8-5.
Frame Time (0018,1063) может быть рассчитан на основе частоты кадров записывающей камеры. Частота кадров 29.97 кадров в секунду соответствует времени кадра 33.367 мс.
Значение chroma_format для этого профиля и уровня определено MPEG как 4:2:0.
Примеры разрешений экрана, поддерживаемых MPEG-4 AVC/H.264 High Profile / Level 4.1, можно взять из Таблицы 8-4. Частоты кадров 50 Hz и 60 Hz (прогрессивная развёртка) при максимальном разрешении 1080 на 1920 не поддерживаются MPEG-4 AVC/H.264 High Profile / Level 4.1. Чересстрочная развёртка при максимальном разрешении поддерживается при частоте полей 50 Hz или 60 Hz, что соответствует частоте кадров 25 Hz или 30 Hz соответственно. Меньшие разрешения могут использоваться при условии соответствия квадратному соотношению сторон пикселя. Примером является разрешение XGA с разрешением изображения 768 на 1024 пикселей. Для меньших разрешений возможны более высокие частоты кадров. Например, для XGA частота может достигать 80 Hz.
Соотношение сторон дисплея неявно определяется пиксельным разрешением видеокартинки. Разрешено только квадратное соотношение сторон пикселя. MPEG-4 AVC/H.264 BD-compatible High Profile / Level 4.1 поддерживает только разрешения, дающие соотношение сторон дисплея 16:9.
Разрешённые разрешения экрана для MPEG-4 AVC/H.264 BD-compatible High Profile / Level 4.1 перечислены в Таблице 8-4. Поддерживаются только HD-разрешения, и не поддерживаются прогрессивные частоты кадров для 25 или 29.97 кадров в секунду. Частоты кадров 50 Hz и 60 Hz (прогрессивная развёртка) при максимальном разрешении 1080 на 1920 не поддерживаются.

Таблица 8-5. Атрибуты частоты кадров синтаксиса передачи изображений MPEG-4 AVC/H.264 High Profile / Level 4.1

Тип видео	Слой пространственного разрешения	Частота кадров (см. Примечание 2)	Время кадра (см. Примечание 3)
30 Hz HD	Одиночный уровень, улучшение	30	33.33 мс
25 Hz HD	Одиночный уровень, улучшение	25	40.0 мс
60 Hz HD	Одиночный уровень, улучшение	60	16.67 мс
50 Hz HD	Одиночный уровень, улучшение	50	20.00 мс

Для нефрагментируемого инкапсулированного синтаксиса передачи один фрагмент должен содержать весь битовый поток MPEG-4 AVC/H.264.

Примечание

Если видеопоток превышает максимальную длину одного фрагмента (2^32-2 байта), он может быть отправлен с использованием фрагментируемого инкапсулированного синтаксиса передачи. В качестве альтернативы он может быть отправлен с использованием нефрагментируемого инкапсулированного синтаксиса передачи в виде нескольких экземпляров SOP, но каждый экземпляр SOP будет содержать независимый и воспроизводимый битовый поток и не будет зависеть от закодированного битового потока в других (предыдущих) экземплярах. Способ связи таких отдельных экземпляров не указан в стандарте, но могут использоваться такие механизмы, как группировка в одну серию и ссылки на предыдущие экземпляры с использованием Referenced Image Sequence.
Фрагментируемые инкапсулированные синтаксисы передачи позволяют создавать потоки практически неограниченной длины; единственным налагаемым ограничением является максимальное Number of Frames (0028,0008), равное 2^31-1 кадров (наибольшее положительное значение в VR Integer String).

Форматом контейнера для видеопотока должен быть MPEG-2 Transport Stream, также известный как MPEG-TS (см. [ISO/IEC 13818-1]), или MPEG-4, также известный как контейнер MP4 (см. [ISO/IEC 14496-12] и [ISO/IEC 14496-14]). PTS/DTS транспортного потока должны использоваться в кодировании MPEG.

Любые аудиокомпоненты, включённые в контейнер данных, должны соответствовать ограничениям, подробно описанным в Разделе 8.2.12 «Ограничения для интеграции аудиоданных в сжатые битовые потоки AVC и HEVC».

8.2.8 Сжатие видео MPEG-4 AVC/H.264 High Profile / Level 4.2

DICOM обеспечивает механизм поддержки использования сжатия изображений MPEG-4 AVC/H.264 посредством инкапсулированного формата. Приложение A определяет синтаксисы передачи, ссылающиеся на стандарт MPEG-4 AVC/H.264.

Примечание

Сжатие MPEG-4 AVC/H.264 / High Profile по своей природе является сжатием с потерями. Контекст, в котором использование сжатия медицинских изображений с потерями является клинически приемлемым, выходит за рамки стандарта DICOM. Политики, связанные с выбором соответствующих параметров сжатия (например, коэффициента сжатия) для MPEG-4 AVC/H.264 High Profile / Level 4.2, также выходят за рамки данного стандарта.

Примечание

Требования:

Planar Configuration (0028,0006) должен быть 0
Samples per Pixel (0028,0002) должен быть 3
Photometric Interpretation (0028,0004) должен быть YBR_PARTIAL_420
Bits Allocated (0028,0100) должен быть 8
Bits Stored (0028,0101) должен быть 8
High Bit (0028,0102) должен быть 7
Pixel Representation (0028,0103) должен быть 0
Значение MPEG-4 AVC/H.264 sample aspect_ratio_idc должно быть 1 в инкапсулированном битовом потоке MPEG-4 AVC/H.264, если aspect_ratio_info_present_flag равен 1.
Pixel Aspect Ratio (0028,0034) должен отсутствовать. Это соответствует «Sampling Aspect Ratio» (SAR) 1:1.
Значения Rows (0028,0010), Columns (0028,0011), Cine Rate (0018,0040) и Frame Time (0018,1063) или Frame Time Vector (0018,1065) должны соответствовать High Profile / Level 4.2 стандарта MPEG-4 AVC/H.264 ([ISO/IEC 14496-10]) и быть ограничены квадратным соотношением сторон пикселя.

Примечание

Значение Planar Configuration (0028,0006) не имеет значения, поскольку способ кодирования компонентов указан в стандарте MPEG-4 AVC/H.264, поэтому оно установлено в 0.
Частота кадров записывающей камеры для '30 Hz HD' MPEG-4 AVC/H.264 может быть либо 30, либо 30/1.001 (приблизительно 29.97) кадров/сек. Аналогично, частота кадров в случае 60 Hz может быть либо 60, либо 60/1.001 (приблизительно 59.94) кадров/сек. Это может привести к небольшим несоответствиям между временной шкалой видео и реальным временем. Связь между частотой кадров и временем кадра показана в Таблице 8-7.
Frame Time (0018,1063) может быть рассчитан на основе частоты кадров записывающей камеры. Частота кадров 29.97 кадров в секунду соответствует времени кадра 33.367 мс.
Значение chroma_format для этого профиля и уровня определено MPEG как 4:2:0.

Таблица 8-7. Атрибуты частоты кадров синтаксиса передачи изображений MPEG-4 AVC/H.264 High Profile / Level 4.2

Тип видео	Частота кадров (см. Примечание 2)	Время кадра (см. Примечание 3)
30 Hz HD	30	33.33 мс
25 Hz HD	25	40.0 мс
60 Hz HD	60	16.67 мс
50 Hz HD	50	20.00 мс

Stereo Pairs Present (0022,0028) должен быть YES, если присутствуют стереоскопические пары, в противном случае — NO или отсутствовать.

Таблица 8-8. Стереоскопические атрибуты синтаксиса передачи изображений MPEG-4 AVC/H.264 High Profile / Level 4.2

Синтаксис передачи	Stereo Pairs Present	Stereo Frame Packing Format
MPEG-4 AVC/H.264 High Profile / Level 4.2 for 2D Image Compression	NO или отсутствует	отсутствует
MPEG-4 AVC/H.264 High Profile / Level 4.2 for 3D Image Compression	YES	присутствует

Примечание

Если видеопоток превышает максимальную длину одного фрагмента (2^32-2 байта), он может быть отправлен с использованием фрагментируемого инкапсулированного синтаксиса передачи. В качестве альтернативы он может быть отправлен с использованием нефрагментируемого инкапсулированного синтаксиса передачи в виде нескольких экземпляров SOP, но каждый экземпляр SOP будет содержать независимый и воспроизводимый битовый поток и не будет зависеть от закодированного битового потока в других (предыдущих) экземплярах. Способ связи таких отдельных экземпляров не указан в стандарте, но могут использоваться такие механизмы, как группировка в одну серию и ссылки на предыдущие экземпляры с использованием Referenced Image Sequence.
Фрагментируемые инкапсулированные синтаксисы передачи позволяют создавать потоки практически неограниченной длины; единственным налагаемым ограничением является максимальное Number of Frames (0028,0008), равное 2^31-1 кадров (наибольшее положительное значение в VR Integer String).

8.2.9 Сжатие видео MPEG-4 AVC/H.264 Stereo High Profile / Level 4.2

DICOM обеспечивает механизм поддержки использования сжатия изображений MPEG-4 AVC/H.264 посредством инкапсулированного формата. Приложение A определяет нефрагментируемые и фрагментируемые инкапсулированные синтаксисы передачи, ссылающиеся на стандарт MPEG-4 AVC/H.264.

MPEG-4 AVC/H.264 Stereo High Profile может достичь лучшего сжатия за счёт дополнительного использования предсказания между базовым и зависимым стереоскопическими видами. Кадры базового вида используют внутрикадровое и межкадровое предсказание, как в MPEG-4 AVC/H.264 High Profile. Это позволяет декодерам, не поддерживающим декодирование стереоскопических данных, декодировать только базовый вид. Зависимый вид кодируется с использованием избыточности за счёт предсказания на основе сходства между базовым и зависимым видами.

MPEG-4 AVC/H.264 Stereo High Profile использует таблицу Level A-1 спецификации MPEG-4 для установки ограничений пропускной способности. Свойства, требуемые для сжатия MPEG-4 AVC/H.264 Stereo High Profile, идентичны свойствам, определённым в Разделе 8.2.8, за исключением того, что Stereo Pairs Present (0022,0028) всегда должен быть YES.

8.2.10 Сжатие видео HEVC/H.265 Main Profile / Level 5.1

HEVC/H.265 Main Profile / Level 5.1 Main tier предназначен для сжатия видеоформатов 4:2:0 с разрешением до 4K при 60 кадрах в секунду с разрядностью 8 бит. DICOM обеспечивает механизм поддержки использования сжатия изображений HEVC/H.265 посредством инкапсулированного формата. Приложение A определяет фрагментируемый инкапсулированный синтаксис передачи, ссылающийся на стандарт HEVC/H.265.

Использование инкапсулированного формата DICOM для поддержки сжатых пиксельных данных HEVC/H.265 требует, чтобы элементы данных, связанные с кодированием пиксельных данных (например, Photometric Interpretation, Samples per Pixel, Planar Configuration, Bits Allocated, Bits Stored, High Bit, Pixel Representation, Rows, Columns и т.д.), содержали значения, согласованные с характеристиками сжатого потока данных, с некоторыми конкретными исключениями, отмеченными ниже. Характеристики пиксельных данных, включённые в битовый поток HEVC/H.265, должны использоваться для декодирования сжатого потока данных.

Примечание

Эти требования сформулированы в терминах согласованности с тем, что инкапсулировано, а не в терминах несжатых пиксельных данных, из которых мог быть получен сжатый поток данных.
При распаковке, если характеристики, явно указанные в сжатом потоке данных, не согласуются с характеристиками, указанными в элементах данных DICOM, для управления распаковкой должны использоваться характеристики, явно указанные в сжатом потоке данных. Элементы данных DICOM, если они не согласуются, могут рассматриваться как предложения о форме, в которой может быть закодирован несжатый набор данных, с учётом общих и специфичных для IOD правил для несжатой Photometric Interpretation и Planar Configuration, которые могут требовать преобразования распакованных данных в одну из разрешённых форм.

Требования:

Planar Configuration (0028,0006) должен быть 0
Samples per Pixel (0028,0002) должен быть 3
Photometric Interpretation (0028,0004) должен быть YBR_PARTIAL_420
Bits Allocated (0028,0100) должен быть 8
Bits Stored (0028,0101) должен быть 8
High Bit (0028,0102) должен быть 7
Pixel Representation (0028,0103) должен быть 0
Значение HEVC/H.265 sample aspect_ratio_idc должно быть 1 в инкапсулированном битовом потоке HEVC/H.265, если aspect_ratio_info_present_flag равен 1.
Pixel Aspect Ratio (0028,0034) должен отсутствовать. Это соответствует «Sampling Aspect Ratio» (SAR) 1:1.
Значения Rows (0028,0010), Columns (0028,0011), Cine Rate (0018,0040) и Frame Time (0018,1063) или Frame Time Vector (0018,1065) должны соответствовать Main Profile / Level 5.1 стандарта HEVC/H.265 [ISO/IEC 23008-2] и быть ограничены квадратным соотношением сторон пикселя.

Примечание

Значение Planar Configuration (0028,0006) не имеет значения, поскольку способ кодирования компонентов указан в стандарте HEVC/H.265, поэтому оно установлено в 0.
Ограничения на строки и столбцы направлены на максимизацию совместимости между программными средами и широко доступными аппаратными реализациями кодеров/декодеров HEVC/H.265. Исходные изображения с меньшими значениями должны быть переформатированы путём масштабирования и/или заполнения пикселей перед кодированием HEVC/H.265.
Frame Time (0018,1063) может быть рассчитан на основе частоты кадров записывающей камеры. Частота кадров 29.97 кадров в секунду соответствует времени кадра 33.367 мс.
Значение chroma_format_idc для этого профиля и уровня равно 1, что указывает на использование содержимого 4:2:0.

Инкапсулированный поток пиксельных данных может быть разделён на несколько фрагментов.

Примечание

Ожидается, что получатель объединит фрагменты при их декодировании. Это позволяет создавать потоки практически неограниченной длины; единственным налагаемым ограничением является максимальное значение Number of Frames (0028,0008), равное 2^31-1 кадров (наибольшее положительное значение в VR Integer String).

8.2.11 Сжатие видео HEVC/H.265 Main 10 Profile / Level 5.1

HEVC/H.265 Main 10 Profile / Level 5.1 Main tier предназначен для сжатия видеоформатов 4:2:0 с разрешением до 4K при 60 кадрах в секунду с разрядностью 10 бит. DICOM обеспечивает механизм поддержки использования сжатия изображений HEVC/H.265 посредством инкапсулированного формата. Приложение A определяет фрагментируемый инкапсулированный синтаксис передачи, ссылающийся на стандарт HEVC/H.265.

Примечание

Эти требования сформулированы в терминах согласованности с тем, что инкапсулировано, а не в терминах несжатых пиксельных данных, из которых мог быть получен сжатый поток данных.
При распаковке, если характеристики, явно указанные в сжатом потоке данных, не согласуются с характеристиками, указанными в элементах данных DICOM, для управления распаковкой должны использоваться характеристики, явно указанные в сжатом потоке данных. Элементы данных DICOM, если они не согласуются, могут рассматриваться как предложения о форме, в которой может быть закодирован несжатый набор данных, с учётом общих и специфичных для IOD правил для несжатой Photometric Interpretation и Planar Configuration, которые могут требовать преобразования распакованных данных в одну из разрешённых форм.

Требования:

Planar Configuration (0028,0006) должен быть 0
Samples per Pixel (0028,0002) должен быть 3
Photometric Interpretation (0028,0004) должен быть YBR_PARTIAL_420
Bits Allocated (0028,0100) должен быть 16
Bits Stored (0028,0101) должен быть 10
High Bit (0028,0102) должен быть 9
Pixel Representation (0028,0103) должен быть 0
Значение HEVC/H.265 sample aspect_ratio_idc должно быть 1 в инкапсулированном битовом потоке HEVC/H.265, если aspect_ratio_info_present_flag равен 1.
Pixel Aspect Ratio (0028,0034) должен отсутствовать. Это соответствует «Sampling Aspect Ratio» (SAR) 1:1.
Значения Rows (0028,0010), Columns (0028,0011), Cine Rate (0018,0040) и Frame Time (0018,1063) или Frame Time Vector (0018,1065) должны соответствовать Main 10 Profile / Level 5.1 стандарта HEVC/H.265 [ISO/IEC 23008-2] и быть ограничены квадратным соотношением сторон пикселя.

Примечание

Значение Planar Configuration (0028,0006) не имеет значения, поскольку способ кодирования компонентов указан в стандарте HEVC/H.265, поэтому оно установлено в 0.
Ограничения на строки и столбцы направлены на максимизацию совместимости между программными средами и широко доступными аппаратными реализациями кодеров/декодеров HEVC/H.265. Исходные изображения с меньшими значениями должны быть переформатированы путём масштабирования и/или заполнения пикселей перед кодированием HEVC/H.265.
Frame Time (0018,1063) может быть рассчитан на основе частоты кадров записывающей камеры. Частота кадров 29.97 кадров в секунду соответствует времени кадра 33.367 мс.
Значение chroma_format_idc для этого профиля и уровня равно 1, что указывает на использование содержимого 4:2:0.

Инкапсулированный поток пиксельных данных может быть разделён на несколько фрагментов.

Примечание

8.2.12 Ограничения для интеграции аудиоданных в сжатые битовые потоки AVC и HEVC

В этом разделе описаны ограничения, относящиеся к присутствию аудиоданных наряду с пиксельными данными в объектах DICOM. Это затрагивает следующие синтаксисы передачи инкапсуляции пиксельных данных:

MPEG-4 AVC/H.264 High Profile / Level 4.1
MPEG-4 AVC/H.264 BD-compatible High Profile / Level 4.1
MPEG-4 AVC/H.264 High Profile / Level 4.2 For 2D Video
MPEG-4 AVC/H.264 High Profile / Level 4.2 For 3D Video
MPEG-4 AVC/H.264 Stereo High Profile / Level 4.2
HEVC/H.265 Main Profile / Level 5.1
HEVC/H.265 Main 10 Profile / Level 5.1

Любые аудиокомпоненты, присутствующие в битовом потоке, синтаксис передачи которого входит в число перечисленных выше, должны быть чередуемыми в формате LPCM, AC-3, AAC, MP3 или MPEG-1 Layer II и должны соответствовать следующим ограничениям:

Таблица 8.2.12-1. Разрешённые аудиоформаты

Аудиоформат	Контейнер MPEG-2 TS	Контейнер MP4
LPCM	Разрешено	-
AC3	Разрешено	-
AAC	Разрешено	Разрешено
MP3	Разрешено	Разрешено
MPEG-1 Audio Layer II	Разрешено	Разрешено

LPCM
- Максимальная скорость потока: 4.608 Мбит/с
- Частота дискретизации: 48, 96 кГц
- Бит на выборку: 16, 20 или 24 бит
- Количество каналов: 2 канала
Примечание

Если для аудиокомпонентов используется LPCM, форматом контейнера должен быть MPEG-2 TS.
AC-3
- Максимальная скорость потока: 640 кбит/с
- Частота дискретизации: 48 кГц
- Бит на выборку: 16 бит
- Количество каналов: 2 или 5.1 канала
Примечание
1. AC-3 стандартизирован в [ETSI TS 102 366]
2. Если для аудиокомпонентов используется AC-3, форматом контейнера должен быть MPEG-2 TS.
AAC
- Максимальная скорость потока: 640 кбит/с
- Частота дискретизации: 48 кГц
- Бит на выборку: 16, 20 или 24 бит
- Количество каналов: 2 или 5.1 канала
Примечание

AAC стандартизирован в части 7 стандарта MPEG-2 (см. [ISO/IEC 13818-7]) и в подразделе 4 части 3 стандарта MPEG-4 (см. [ISO/IEC 14496-3]).
CBR MPEG-1 LAYER III (MP3) Audio Standard
- Максимальная скорость потока: 320 кбит/с
- Частота дискретизации: 32 кГц, 44.1 кГц или 48 кГц для основного канала (дополнительные каналы могут оцифровываться с половинной частотой, как определено в стандарте)
- Бит на выборку: до 24 бит
- Количество каналов: один основной моно- или стереоканал и, дополнительно, один или несколько дополнительных каналов
Примечание
1. MPEG-1 Layer III стандартизирован в части 3 стандарта MPEG-1 (см. [ISO/IEC 11172-3]).
2. Хотя MPEG описывает каждый канал как включающий до 5 сигналов (например, для эффектов объёмного звучания), рекомендуется ограничить каждый из двух каналов до 2 сигналов (стерео).
MPEG-1 LAYER II (MP2)
- Максимальная скорость потока: 384 кбит/с
- Частота дискретизации: 32 кГц, 44.1 кГц или 48 кГц
- Бит на выборку: до 24 бит
- Количество каналов: 2
Примечание

MPEG-1 Layer II стандартизирован в части 3 стандарта MPEG-1 (см. [ISO/IEC 11172-3]).

8.2.13 Ограничения для несжатого активного видео SMPTE ST 2110-20 для DICOM-RTV

В этом разделе описаны ограничения, применяемые к пиксельным данным, передаваемым в потоке DICOM-RTV (отдельно от потока метаданных DICOM-RTV) и полностью описанным в [SMPTE ST 2110-20] .

Следующая таблица описывает ограничения видеопотока [SMPTE ST 2110-20] в терминах допустимых значений соответствующих атрибутов DICOM в потоке метаданных DICOM-RTV:

Samples per Pixel
Bits Allocated
Bits Stored
High Bit

Таблица 8.2.13-1. Ограничения, применимые к атрибутам, описывающим пиксельные данные

Samples per Pixel (0028,0002)	Bits Allocated (0028,0100)	Bits Stored (0028,0101)	High Bit (0028,0102)
3	8, 16, 16, 16	8, 10, 12, 16	7, 9, 11, 15

DICOM Photometric Interpretation основано на CCIR 601 (также известном как ITU-R BT.601), поэтому некоторые ограничения применяются к возможным комбинациям параметров системы дискретизации и колориметрии, как указано в [SMPTE ST 2110-20] .

Таблица 8.2.13-2. Перечень поддерживаемых комбинаций параметров SMPTE ST 2110-20

SMPTE ST 2110-20		DICOM Photometric Interpretation (0028,0004)
Система дискретизации	Колориметрия	DICOM Photometric Interpretation (0028,0004)
RGB	BT601	RGB
YCbCr-4:4:4	BT601	YBR_FULL
YCbCr-4:2:2	BT601	YBR_FULL_422
YCbCr-4:2:0	BT601	YBR_PARTIAL_420

Некоторые другие комбинации параметров [SMPTE ST 2110-20] не соответствуют существующим DICOM Photometric Interpretation, поэтому их использование в настоящее время не разрешено. Таблица 8.2.13-3 содержит перечень неподдерживаемых комбинаций.

Таблица 8.2.13-3. Перечень неподдерживаемых комбинаций параметров SMPTE ST 2110-20

SMPTE ST 2110-20
Система дискретизации	Колориметрия
RGB	BT2020, BT709, BT2100, ST2065-1, ST2065-3
YCbCr-4:4:4	BT2020, BT709, BT2100
YCbCr-4:2:2	BT2020, BT709, BT2100
YCbCr-4:2:0	BT2020, BT709, BT2100
CLYCbCr-4:4:4	BT2020
CLYCbCr-4:2:2	BT2020
CLYCbCr-4:2:0	BT2020
ICtCp-4:4:4	BT2100
ICtCp-4:2:2	BT2100
XYZ	XYZ
KEY

8.2.14 Сжатие изображений High-Throughput JPEG 2000

DICOM обеспечивает механизм поддержки использования сжатия изображений High-Throughput JPEG 2000 (HTJ2K) через инкапсулированный формат. Приложение A определяет три синтаксиса передачи, которые ссылаются на стандарт HTJ2K и обеспечивают одну схему сжатия с потерями и две схемы сжатия без потерь, вторая из которых оптимизирована для отображения прогрессивных битовых потоков.

Примечание

Контекст, в котором использование сжатия медицинских изображений с потерями является клинически приемлемым, выходит за рамки стандарта DICOM. Политики, связанные с выбором подходящих параметров сжатия (например, коэффициента сжатия) для сжатия HTJ2K с потерями, также выходят за рамки данного стандарта.

Использование инкапсулированного формата DICOM для поддержки сжатых пиксельных данных HTJ2K требует, чтобы элементы данных, связанные с кодированием пиксельных данных (например, Photometric Interpretation, Samples per Pixel, Planar Configuration, Bits Allocated, Bits Stored, High Bit, Pixel Representation, Rows, Columns и т. д.), содержали значения, согласованные с характеристиками сжатого потока данных. Характеристики пиксельных данных, включённые в битовый поток HTJ2K, должны использоваться для декодирования сжатого потока данных.

Требования при использовании стандартного Photometric Interpretation (т. е. определённого термина из PS.3. C.7.6.3.1.2) указаны в Таблице 8.2.14-1. Никакие другие значения стандартного Photometric Interpretation не должны использоваться.

Таблица 8.2.14-1. Допустимые значения атрибутов, связанных с пиксельными данными, для синтаксисов передачи HTJ2K с использованием стандартных Photometric Interpretation

Photometric Interpretation	Синтаксис передачи	Transfer Syntax UID	Samples per Pixel	Planar Configuration	Pixel Representation	Bits Allocated	Bits Stored	High Bit
MONOCHROME1 MONOCHROME2	HTJ2K (Lossless Only)	1.2.840.10008.1.2.4.201	1	отсутствует	0 or 1	8, 16, 24, 32 or 40	1-38	0-37
	HTJ2K (Lossless RPCL)	1.2.840.10008.1.2.4.202
	HTJ2K	1.2.840.10008.1.2.4.203
PALETTE COLOR	HTJ2K (Lossless Only)	1.2.840.10008.1.2.4.201	1	отсутствует	0	8 or 16	1-16	0-15
PALETTE COLOR	HTJ2K (Lossless RPCL)	1.2.840.10008.1.2.4.202	1	отсутствует	0	8 or 16	1-16	0-15
YBR_RCT	HTJ2K (Lossless Only)	1.2.840.10008.1.2.4.201	3	0	0	8, 16, 24, 32 or 40	1-38	0-37
	HTJ2K (Lossless RPCL)	1.2.840.10008.1.2.4.202
	HTJ2K	1.2.840.10008.1.2.4.203
YBR_ICT	HTJ2K	1.2.840.10008.1.2.4.203	3	0	0	8, 16, 24, 32 or 40	1-38	0-37
RGB	HTJ2K (Lossless Only)	1.2.840.10008.1.2.4.201	3	0	0	8, 16, 24, 32 or 40	1-38	0-37
	HTJ2K (Lossless RPCL)	1.2.840.10008.1.2.4.202
	HTJ2K	1.2.840.10008.1.2.4.203
YBR_FULL	HTJ2K (Lossless Only)	1.2.840.10008.1.2.4.201	3	0	0	8, 16, 24, 32 or 40	1-38	0-37
	HTJ2K (Lossless RPCL)	1.2.840.10008.1.2.4.202
	HTJ2K	1.2.840.10008.1.2.4.203

Примечание

Битовый поток HTJ2K указывает, была ли применена обратимая или необратимая многокомпонентная (цветовая) трансформация ([ISO/IEC 15444-1] Приложение G), если таковая имеется. Если многокомпонентная трансформация не применялась, то компоненты должны соответствовать указанным в атрибуте DICOM Photometric Interpretation (0028,0004). Если применена обратимая многокомпонентная трансформация JPEG 2000 Part 1, то атрибут DICOM Photometric Interpretation (0028,0004) должен быть YBR_RCT. Если применена необратимая многокомпонентная трансформация JPEG 2000 Part 1, то атрибут DICOM Photometric Interpretation (0028,0004) должен быть YBR_ICT.

Примечание

Например, может присутствовать один компонент, а Photometric Interpretation (0028,0004) может быть MONOCHROME2.
Применение обратимой многокомпонентной трансформации JPEG 2000 Part 1 сигнализируется в битовом потоке JPEG 2000 значением 1 вместо 0 в поле SGcod Multiple component transformation type сегмента маркера COD ([ISO/IEC 15444-1] Таблица A.17). Никакое другое значение Photometric Interpretation, кроме YBR_RCT или YBR_ICT, не допускается, когда SGcod Multiple component transformation type равно 1.
Хотя это было бы необычно, не использовало бы корреляцию между красным, зелёным и синим компонентами и не достигало бы эффективного сжатия, Photometric Interpretation RGB может быть указано, при условии что многокомпонентная трансформация ([ISO/IEC 15444-1] Приложение G) не указана битовым потоком JPEG 2000. Для некоторых применений использование RGB разрешено, например, для изображений полной слайдовой микроскопии (Whole Slide Microscopy Images), чтобы обеспечить преобразование в DICOM из проприетарных форматов без потерь из-за преобразования цветового пространства. Альтернативные методы декорреляции цветовых компонентов, отличные от указанных в ([ISO/IEC 15444-1] Приложение G), разрешены, как определено в PS3.3, например Photometric Interpretation YBR_FULL; это может быть полезно при преобразовании существующих пиксельных данных YBR_FULL (например, в другом синтаксисе передачи) без дальнейших потерь.

В любом из этих случаев (Photometric Interpretation RGB или YBR_FULL) значение SGcod Multiple component transformation type будет равно 0.

PS3.3 может ограничивать значения Photometric Interpretation для конкретных IOD.
Несмотря на применение многокомпонентного цветового преобразования и его отражение в атрибуте Photometric Interpretation, «цветовое пространство» остаётся неопределённым. В настоящее время нет средств передачи «стандартных цветовых пространств» ни через фиксированные значения (например, sRGB), ни через ICC-профили. Следует особо отметить, что заголовок файла JP2 не передаётся в битовом потоке HTJ2K, инкапсулированном в DICOM.
Если сжатые пиксельные данные HTJ2K распаковываются и повторно кодируются в собственном (несжатом) виде, то элементы данных, связанные с кодированием пиксельных данных, обновляются соответствующим образом. Если цветовые компоненты преобразуются из YBR_ICT или YBR_RCT в RGB во время распаковки и собственного повторного кодирования, Photometric Interpretation будет изменено на RGB в наборе данных с собственным кодированием.
Верхний предел 40 для Bits Allocated (0028,0100) и 38 для Bits Stored (0028,0101) отражает максимальную точность выборки HTJ2K, равную 38, и требование DICOM описывать Bits Allocated (0028,0100) как кратные байтам (октетам).

Битовый поток HTJ2K способен кодировать как знаковые, так и беззнаковые значения пикселей, поэтому значение Pixel Representation (0028,0103) может быть 0 или 1 для монохромных Photometric Interpretation в зависимости от того, что было закодировано (как указано в сегменте маркера SIZ в параметре точности и знака компонента).

Значение Planar Configuration (0028,0006) не имеет значения, поскольку способ кодирования компонентов определён в стандарте JPEG 2000, поэтому оно должно быть установлено в 0.

8.2.15 Сжатие изображений JPEG XL

DICOM обеспечивает механизм поддержки использования сжатия изображений JPEG XL через инкапсулированный формат. Приложение A определяет ряд синтаксисов передачи, ссылающихся на стандарт JPEG XL. Синтаксис передачи JPEG XL Lossless обеспечивает схему сжатия, сохраняющую биты исходного изображения, т. е. сжатие без потерь. Синтаксис передачи JPEG XL JPEG Recompression сохраняет биты (сжатого с потерями) JPEG-кодирования. Синтаксис передачи JPEG XL представляет собой потенциально сжатое с потерями кодирование исходного изображения.

Примечание

Контекст, в котором использование сжатия медицинских изображений с потерями является клинически приемлемым, выходит за рамки стандарта DICOM. Политики, связанные с выбором подходящих параметров сжатия (например, коэффициента сжатия) для сжатия JPEG XL с потерями, также выходят за рамки данного стандарта.

Использование инкапсулированного формата DICOM для поддержки сжатых пиксельных данных JPEG XL требует, чтобы элементы данных, связанные с кодированием пиксельных данных (например, Photometric Interpretation, Samples per Pixel, Planar Configuration, Bits Allocated, Bits Stored, High Bit, Pixel Representation, Rows, Columns и т. д.), содержали значения, согласованные с характеристиками сжатого потока данных. Характеристики пиксельных данных, включённые в битовый поток JPEG XL, должны использоваться для декодирования сжатого потока данных.

Требования при использовании стандартного Photometric Interpretation (т. е. определённого термина из Раздела C.7.6.3.1.2 в PS3.3 ) указаны в Таблице 8.2.15-1. Никакие другие значения стандартного Photometric Interpretation не должны использоваться.

Таблица 8.2.15-1. Допустимые значения атрибутов, связанных с пиксельными данными, для синтаксисов передачи JPEG XL с использованием стандартных Photometric Interpretation

Photometric Interpretation	Синтаксис передачи	Transfer Syntax UID	Samples per Pixel	Planar Configuration	Pixel Representation	Bits Allocated	Bits Stored	High Bit
MONOCHROME1 MONOCHROME2	JPEG XL Lossless	1.2.840.10008.1.2.4.110	1	отсутствует	0 or 1	1,8,16,24	1-24	0-23
MONOCHROME1 MONOCHROME2	JPEG XL	1.2.840.10008.1.2.4.112	1	отсутствует	0 or 1	1,8,16,24	1-24	0-23
MONOCHROME2	JPEG XL JPEG Recompression	1.2.840.10008.1.2.4.111	1	отсутствует	0	8	8	7
XYB YBR_RCT RGB	JPEG XL Lossless	1.2.840.10008.1.2.4.110	3	0	0	8,16,24	8-24	7-23
XYB YBR_RCT RGB	JPEG XL	1.2.840.10008.1.2.4.112	3	0	0	8,16,24	8-24	7-23
YBR_FULL_422 XYB RGB	JPEG XL JPEG Recompression	1.2.840.10008.1.2.4.111	3	0	0	8	8	7

Примечание

PS3.3 может ограничивать значения Photometric Interpretation для конкретных IOD.

Битовый поток JPEG XL способен кодировать как знаковые, так и беззнаковые значения пикселей, поэтому значение Pixel Representation (0028,0103) может быть 0 или 1 для монохромных Photometric Interpretation в зависимости от того, что было закодировано.

Значение Planar Configuration (0028,0006) не имеет значения, поскольку способ кодирования компонентов определён в стандарте JPEG XL, поэтому оно должно быть установлено в 0.

8.2.16 Сжатие кадров изображений алгоритмом Deflate

DICOM обеспечивает механизм поддержки использования сжатия Deflate для каждого отдельного кадра изображения с использованием инкапсулированного формата. Deflate — это ориентированная на байты схема сжатия без потерь, используемая с инкапсулированным форматом.

Раздел A.4.13 определяет синтаксис передачи, использующий алгоритм Deflate, определённый в [RFC1951], для сжатия пиксельных данных каждого кадра изображения как отдельного сжатого битового потока.

Примечание

Сжатие кадров изображений алгоритмом Deflate применимо только к пиксельным данным, передаваемым в элементе данных Pixel Data (7FE0,0010).
Хотя он использует ту же схему сжатия, синтаксис передачи сжатия кадров изображений алгоритмом Deflate отличается от синтаксиса передачи DICOM Deflated Explicit VR Little Endian, определённого в Разделе A.5, который сжимает весь набор данных как единый сжатый битовый поток.

Поскольку алгоритм Deflate сжимает байтовые потоки независимо от их содержимого, ограничений на значения атрибутов, связанных с пиксельными данными, не существует.

Примечание

Одним из применений сжатия кадров изображений алгоритмом Deflate является сжатие без потерь однобитных (двухуровневых, Bits Allocated (0028,0100) == 1) изображений сегментации, однако этот механизм является универсальным и не ограничен какими-либо конкретными характеристиками расположения или значений пиксельных данных.

8.3 Данные сигналов и связанные с ними элементы данных

Протокол DICOM предусматривает обмен закодированными сигналами, зависящими от времени, или сигналами (waveform), закодированными в Waveform Data (5400,1010).

Примечание

Согласно Разделу 7.6, IOD, поддерживающий несколько наборов Waveform Data, будет инкапсулировать Waveform Data (5400,1010) внутри Sequence.

Кодированные данные сигналов (Waveform Data) различной битовой глубины поддерживаются через элемент данных Waveform Bits Allocated (5400,1004). Этот элемент данных определяет размер каждой выборки данных сигнала в Waveform Data (5400,1010). Допускаются значения 8, 16, 32 и 64 бит.

Value Representation элемента Waveform Data (5400,1010) должен быть OW; OB должен использоваться в случаях, когда Waveform Bits Allocated имеет значение 8, но только с синтаксисами передачи, в которых Value Representation передаётся явно.

Примечание

При синтаксисе передачи по умолчанию VR OB и OW имеют одинаковый порядок передачи байтов.
Преобразование экземпляра SOP из синтаксиса передачи по умолчанию в синтаксис передачи с явным VR (без сжатия) требует интерпретации элемента данных Waveform Bits Allocated (5400,1004) для определения правильного VR данных сигнала.

Следующие элементы данных, связанные с Waveform Data, должны быть закодированы с тем же VR, что и Waveform Data: Channel Minimum Value (5400,0110), Channel Maximum Value (5400,0112) и Waveform Padding Value (5400,100A).

8.4 Служба поставщика пиксельных данных

Определённые синтаксисы передачи допускают замену пиксельных данных сообщения ссылкой на службу поставщика пиксельных данных. Служба поставщика пиксельных данных, на которую делается ссылка, поставляет пиксельные данные с использованием сетевого протокола, определённого вне DICOM.

Примечание

Служба поставщика пиксельных данных неприменима к пиксельным данным, закодированным как Float Pixel Data (7FE0,0008) или Double Float Pixel Data (7FE0,0009).

8.4.1 Пиксельные данные по ссылке JPIP

DICOM обеспечивает механизм поддержки использования интерактивного протокола JPEG 2000 (JPIP) путём включения URL-ссылки на службу поставщика пиксельных данных. Приложение A определяет два синтаксиса передачи, использующих URL-ссылки на службу поставщика пиксельных данных JPIP.

Использование этих синтаксисов передачи требует, чтобы Pixel Data Provider URL указывал URL, представляющий запрос JPIP, включая конкретную целевую информацию. Дополнительные параметры, необходимые приложению, могут быть добавлены к URL при обращении к поставщику пиксельных данных.

Примечание

Например, запрос JPIP для получения 200 на 200 пикселей изображения всего изображения может быть построен из Pixel Data Provider URL следующим образом:

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

URL, сформированный приложением = http://server.xxx/jpipserver.cgi?target=imgxyz.jp2&fsiz=200,200

Клиент JPIP должен запрашивать только битовый поток JPEG 2000 или HTJ2K в зависимости от согласованного синтаксиса передачи.

Сервер JPIP должен возвращать Content-type image/jp2, image/jpp-stream, image/jpt-stream, image/jph или image/jphc, все из которых должны поддерживаться клиентом JPIP, в зависимости от поддерживаемых синтаксисов передачи.

Атрибут Number of Frames (0028,0008), если он присутствует в наборе данных, идентифицирует количество кадров, доступных для данного изображения. Каждый кадр доступен как отдельный кодовый поток JPIP. Кодовые потоки, на которые ссылается URL Target, должны быть пронумерованы последовательно, начиная с потока 1.

Примечание

Например, запрос JPIP для получения версии кадра 17 размером 200 на 200 пикселей из много кадрового изображения может быть сформирован из Pixel Data Provider URL следующим образом:

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

Допустимое значение параметра запроса stream всегда меньше или равно значению Number of Frames (0028,0008).

Синтаксис Pixel Data Provider URL (0028,7FE0) определён в Приложении C (Client Request) стандарта [ISO/IEC 15444-9]. Этот стандарт следует рекомендациям URI [RFC3986]. Транспортным протоколом должен быть HTTP или HTTPS.

Примечание

Согласно [ISO/IEC 15444-9], «Каждый запрос JPIP направлен к конкретному представлению конкретного исходного именованного ресурса или конкретной части этого ресурса. Этот ресурс может быть физически хранимым файлом или объектом, либо может быть чем-то, что создаётся сервером виртуально по запросу».

«Поле запроса Target указывает исходный именованный ресурс, к которому направлен запрос. Оно задаётся с помощью PATH, которым может быть простая строка или URI. Если поле Target не указано, а запрос передаётся по HTTP, то запрос JPIP должен быть направлен к ресурсу, указанному в компоненте пути (path) URL запроса JPIP».
Передача по UDP или другим протоколам не поддерживается.

8.5 Вопросы безопасности при кодировании пиксельных данных, данных оверлеев и сигналов (Информативное)

Инкапсулированные форматы соответствуют другим стандартам, например JPEG. Многие из этих форматов имеют собственные проблемы безопасности, как связанные с самим форматом, так и с распространёнными реализациями для обработки формата.

Реализации, поддерживающие кодирование в инкапсулированном формате, могут потребовать:

Выполнения проверки и очистки входных данных для обнаружения и, возможно, удаления недопустимого или вредоносного содержимого.
Выполнения проверки выходных данных для обеспечения безопасного соответствия спецификации формата.
Отслеживания сообщений об уязвимостях в реализациях библиотек, обновлений и наличия процесса управления этими обновлениями.

Отслеживание, уведомление и устранение этих проблем безопасности обычно осуществляется в контексте инкапсулированного формата, а не в контексте DICOM. Это означает, что те, кто реализует и развёртывает инкапсулированный формат, должны учитывать проблемы безопасности из этих других контекстов.

9 Уникальные идентификаторы (UID)

Уникальные идентификаторы (UID) предоставляют возможность однозначно идентифицировать самые разнообразные объекты. Они гарантируют уникальность в нескольких странах, на различных площадках, у разных производителей и оборудования. Различные классы объектов, экземпляры объектов и информационные сущности могут быть отличены друг от друга в DICOM-вселенной независимо от любого семантического контекста.

Примечание

Например, один и тот же UID не может использоваться для идентификации как экземпляра исследования (Study Instance UID), так и экземпляра серии (Series Instance UID) в пределах этого исследования или другого исследования. Разработчиков также следует предупредить о недопустимости создания новых UID путём вывода (например, путём добавления суффикса) из UID, назначенного другой реализацией.

Схема идентификации UID основана на OSI Object Identification (числовая форма), как определено в стандарте [ISO/IEC 8824]. Все уникальные идентификаторы, используемые в контексте стандарта DICOM, являются зарегистрированными значениями, как определено в [ISO/IEC 9834-1], для обеспечения глобальной уникальности. Использование таких UID определено в различных частях стандарта DICOM.

Каждый UID состоит из двух частей: <корня организации> и <суффикса>:

UID = <корень организации>.<суффикс>

Часть UID <корень организации> однозначно идентифицирует организацию (т.е. производителя, исследовательскую организацию, NEMA и т.д.) и состоит из ряда числовых компонентов, как определено в [ISO/IEC 8824]. Часть UID <суффикс> также состоит из ряда числовых компонентов и должен быть уникальным в пределах области действия <корня организации>. Это означает, что организация, указанная в <корне организации>, несёт ответственность за обеспечение уникальности <суффикса> путём разработки политик регистрации. Эти политики должны гарантировать уникальность <суффикса> для всех UID, созданных этой организацией. В отличие от <корня организации>, который может быть общим для UID в организации, <суффикс> должен принимать различные уникальные значения между различными UID, которые идентифицируют разные объекты.

<Корень организации> "1.2.840.10008" зарезервирован для элементов, определённых в DICOM (таких как Transfer Syntax DICOM), и не должен использоваться для частно определённых элементов (таких как экземпляр изображения).

Хотя конкретная реализация может выбрать некоторую определённую структуру для генерируемых ею UID, она никогда не должна предполагать, что UID несёт какую-либо семантику. Таким образом, UID не должен "разбираться" (парситься) для поиска определённого значения или компонента. Определение компонентов (для суффикса) зависит от реализации и может изменяться при условии сохранения уникальности. Разбор UID может поставить под угрозу возможность взаимодействия по мере развития реализаций.

Пример структуры UID приведён в Приложении C.

9.1 Правила кодирования UID

Правила кодирования UID в DICOM определены следующим образом:

Каждый компонент UID является числом и должен состоять из одной или более цифр. Первая цифра каждого компонента не должна быть нулём, если только компонент не является одной цифрой.

Примечание

Регистрационные органы могут распространять компоненты с незначащими ведущими нулями. Ведущие нули следует игнорировать при кодировании (т.е. "00029" должно кодироваться как "29").
Числовое значение каждого компонента должно быть закодировано с использованием символов 0-9 из базового набора G0 Международной эталонной версии [ISO 646] (DICOM Default Character Repertoire).
Компоненты должны разделяться символом "." (2EH).
При завершении на границе нечётного байта, за исключением использования при сетевом согласовании (см. PS3.8), один завершающий NULL (00H) как символ заполнения должен следовать за последним компонентом для выравнивания UID по границе чётного байта.
UID не должны превышать в общей сложности 64 символа, включая цифры каждого компонента, разделители между компонентами и символ заполнения NULL (00H), если он требуется.

9.2 Регистрация уникальных идентификаторов

Каждый UID, используемый в DICOM, должен быть определён и зарегистрирован одним из следующих двух способов:

UID, определённые и зарегистрированные в DICOM
Частно определённые и зарегистрированные UID

Оба типа UID используют те же правила кодирования, что определены в Разделе 9.1. См. Приложение C для более подробного описания процесса регистрации UID.

9.2.1 Определённые и зарегистрированные в DICOM уникальные идентификаторы

Ограниченное число зарегистрированных определённых в DICOM UID используется в стандарте DICOM. Организацией, ответственной за определение и регистрацию таких UID DICOM, является NEMA.

Процесс регистрации будет основываться на публикации зарегистрированных UID DICOM в PS3.6.

9.2.2 Частно определённые уникальные идентификаторы

Частно определённые UID обычно используются в DICOM. Однако такие UID не будут регистрироваться NEMA. Организации, определяющие частные UID, несут ответственность за надлежащую регистрацию своих UID (как минимум, получение зарегистрированного <корня организации>), как это определено для OSI Object Identifiers [ISO/IEC 9834-1]. Частная организация, определяющая UID, должна принять на себя ответственность за обеспечение его уникальности.

10 Transfer Syntaxes

Transfer Syntax — это набор правил кодирования, способных однозначно представить один или несколько Abstract Syntaxes. В частности, он позволяет взаимодействующим Application Entities согласовать общие поддерживаемые ими обоими методы кодирования (например, порядок байтов, сжатие и т.д.). Transfer Syntax является атрибутом Presentation Context, один или несколько которых согласовываются при установлении Association между DICOM Application Entities. Это согласование Association специфицировано в PS3.8 и рассмотрено в PS3.7.

Выбор Transfer Syntax применяется только к правилам кодирования части Data Set DICOM-сообщения. Все стандартные и частные Transfer Syntaxes DICOM неявно задают фиксированное кодирование части Command Set DICOM-сообщения, как указано в PS3.7.

Эта часть стандарта DICOM определяет стандартные Transfer Syntaxes DICOM и присваивает каждому уникальное имя Transfer Syntax Name. Стандартные Transfer Syntaxes DICOM специфицированы в Приложении A. Нотация DICOM для имён Transfer Syntaxes — это нотация, используемая для UID (см. Раздел 9).

Организацией, ответственной за определение и регистрацию Transfer Syntaxes DICOM, является NEMA. NEMA гарантирует уникальность всех имён Transfer Syntax Names DICOM.

Могут также использоваться частно определённые имена Transfer Syntax Names; однако они не будут регистрироваться NEMA. Организации, определяющие частные Transfer Syntax Names, должны следовать процессу регистрации, определённому в Разделе 9.2.

10.1 Transfer Syntax DICOM по умолчанию

DICOM определяет Transfer Syntax по умолчанию — DICOM Implicit VR Little Endian Transfer Syntax (идентифицируемый по Transfer Syntax UID = "1.2.840.10008.1.2"), который должен поддерживаться каждой соответствующей реализацией DICOM. Это означает, что:

Если Application Entity инициирует запрос A-ASSOCIATE, оно должно предложить DICOM Implicit VR Little Endian Transfer Syntax по крайней мере в одном из Presentation Contexts, связанных с каждым предложенным Abstract Syntax.

Примечание

Предложение Abstract Syntax (AS1) в двух Presentation Contexts с Transfer Syntaxes (TS1) и (TS2) недопустимо, но предложение AS1-TS1, AS1-TS2 и AS1-TSD допустимо, поскольку DICOM Default Little Endian Transfer Syntax (TSD) присутствует по крайней мере в одном из Presentation Contexts, основанных на Abstract Syntax (AS1).
Если Application Entity получает A-ASSOCIATE indication, соответствующий запросу, который соответствует требованиям, указанным в Разделе 10.1 (a), каждый Presentation Context, относящийся к заданному Abstract Syntax, не может быть отклонён в ответе A-ASSOCIATE по причине отсутствия поддержки ни одного из Transfer Syntaxes.

Примечание

Когда Abstract Syntax (AS1) предлагается в трёх Presentation Contexts с Transfer Syntaxes (TS1), (TS2) и (TSD), DICOM Default Little Endian Transfer Syntax (TSD) может быть отклонён, если по крайней мере один из других Presentation Contexts для Abstract Syntax (AS1) принят.

Оба этих требования, (a) и (b), снимаются, когда Application Entity, отправляющее Pixel Data, имеет доступ к Pixel Data только в форме сжатия с потерями или к Pixel Data в форме сжатия без потерь или инкапсулированного несжатого вида, размер которых настолько велик, что они не могут быть закодированы в Transfer Syntax по умолчанию, и Transfer Syntax, использующий ссылку на Pixel Data, не предлагается.

Требование (b) о принятии Transfer Syntax по умолчанию снимается, если предлагается Transfer Syntax, использующий ссылку на Pixel Data.

Примечание

Иными словами, каждое отправляющее AE должно быть способно преобразовать любой Data Set, который оно собирается передать, в Transfer Syntax по умолчанию, независимо от формы, в которой оно изначально получило или сохранило Data Set, за исключением случаев, когда декомпрессированные или деинкапсулированные Pixel Data слишком велики для кодирования в Transfer Syntax по умолчанию или получены в форме сжатия с потерями. В случае Pixel Data, сжатых с потерями, отправляющему AE разрешается предлагать только Transfer Syntax сжатия с потерями, соответствующий полученному формату сжатия с потерями. В случае Pixel Data, сжатых без потерь или инкапсулированных в несжатом виде, которые слишком велики для кодирования в Transfer Syntax по умолчанию, отправляющему AE разрешается предлагать любой подходящий Transfer Syntax сжатия без потерь или инкапсулированный несжатый Transfer Syntax, не обязательно тот, в котором изображение было получено, в качестве альтернативы Transfer Syntax по умолчанию.

Это освобождение не применяется к Data Set, полученным в форме сжатия без потерь или инкапсулированного несжатого вида, если декомпрессированные или деинкапсулированные Pixel Data достаточно малы для кодирования в Transfer Syntax по умолчанию, что означает, что любое AE, получающее Data Set в Transfer Syntax сжатия без потерь или инкапсулированном несжатом Transfer Syntax и нуждающееся в повторной отправке Data Set, должно быть способно выполнить декомпрессию или деинкапсуляцию для поддержки (как минимум) Transfer Syntax по умолчанию.

Аналогичные соображения применимы к транзакциям Web Services и рассматриваются в специальных требованиях PS3.18.

10.2 Transfer Syntax для значения DICOM по умолчанию для сжатия без потерь JPEG

DICOM определяет значение по умолчанию для Lossless JPEG Image Compression, использующее подмножество кодирования Process 14 с прогнозом первого порядка (Selection Value 1). Он идентифицируется Transfer Syntax UID = "1.2.840.10008.1.2.4.70" и должен поддерживаться каждой реализацией DICOM, которая решает поддерживать один или несколько процессов сжатия JPEG без потерь. Это означает, что:

Если Application Entity инициирует запрос A-ASSOCIATE, в котором любой предложенный Abstract Syntax связан в одном или нескольких Presentation Context с Transfer Syntax сжатия JPEG без потерь, по крайней мере один из Presentation Contexts, включающих этот Abstract Syntax, должен включать DICOM Default Lossless JPEG Compression Transfer Syntax и DICOM Default Little Endian Transfer Syntax (несжатый).

Примечание

Предложение Abstract Syntax (AS1) в двух Presentation Contexts с Transfer Syntaxes JPEG lossless (JL1) и (JL2) недопустимо, но предложение AS1-JL1, AS1-JL2, AS1-TSD и AS1-JLD допустимо, поскольку DICOM Default Lossless JPEG Compression Transfer Syntax (JLD) и DICOM Default Little Endian Transfer Syntax (TSD) присутствуют по крайней мере в одном из Presentation Contexts, основанных на Abstract Syntax (AS1).
Если Application Entity, поддерживающее один или несколько Transfer Syntaxes JPEG без потерь, получает A-ASSOCIATE indication, соответствующий запросу, который соответствует требованиям, указанным в Разделе 10.2 (a), каждый Presentation Context, относящийся к заданному Abstract Syntax, не может быть отклонён в ответе A-ASSOCIATE по причине отсутствия поддержки DICOM Default Lossless JPEG Compression Transfer Syntax.

Примечание

Когда Abstract Syntax (AS1) предлагается в четырёх Presentation Contexts с Transfer Syntaxes JPEG lossless (JL1) и (JL2), а также (JLD) и (TSD), как DICOM Default Lossless JPEG Compression Transfer Syntax (JLD), так и DICOM Default Little Endian Transfer Syntax (TSD) могут быть отклонены, если по крайней мере один из других Presentation Contexts для Abstract Syntax (AS1) принят.

10.3 Transfer Syntaxes для значений DICOM по умолчанию для сжатия JPEG с потерями

DICOM определяет значения по умолчанию для Lossy JPEG Image Compression: одно для 8-битных изображений и другое для 12-битных изображений. Кодирование JPEG Process 1 (идентифицируемое Transfer Syntax UID = "1.2.840.10008.1.2.4.50") используется для 8-битных изображений. Кодирование JPEG Process 4 (идентифицируемое Transfer Syntax UID = "1.2.840.10008.1.2.4.51") используется для 12-битных изображений. Это означает, что:

Если Application Entity инициирует запрос A-ASSOCIATE, в котором любой предложенный Abstract Syntax связан в одном или нескольких Presentation Context(s) с Transfer Syntax сжатия JPEG с потерями, по крайней мере один из Presentation Contexts, включающих этот Abstract Syntax, должен включать соответствующий DICOM Default Lossy JPEG Compression Transfer Syntax.
Примечание
1. Предложение Abstract Syntax (AS1) в двух Presentation Contexts с Transfer Syntaxes JPEG lossy (JL1) и (JL2) недопустимо, но предложение AS1-JL1, AS1-JL2 и AS1-JLD допустимо, поскольку DICOM Default Lossy JPEG Transfer Syntax (JLD) присутствует по крайней мере в одном из Presentation Contexts, основанных на Abstract Syntax (AS1).
2. DICOM Default Little Endian Transfer Syntax (несжатый) может быть предложен, если отправитель имеет доступ к исходным Pixel Data в несжатом виде или в форме сжатия без потерь.
Если Application Entity, поддерживающее один или несколько Lossy JPEG Transfer Syntaxes, получает A-ASSOCIATE indication, соответствующий запросу, который соответствует требованиям, указанным в Разделе 10.3 (a), каждый Presentation Context, относящийся к заданному Abstract Syntax, не может быть отклонён в ответе A-ASSOCIATE по причине отсутствия поддержки DICOM Default Lossy JPEG Transfer Syntax.

Примечание

12-битный Default Transfer Syntax 1.2.840.10008.1.2.4.51 также может использоваться для кодирования 8-битных изображений, но требуемый битовый поток не идентичен используемому в 8-битном Default Transfer Syntax 1.2.840.10008.1.2.4.50 (см. A.4.1).
Когда Abstract Syntax (AS1) предлагается в трёх Presentation Contexts с Transfer Syntaxes JPEG lossy (JL1) и (JL2), а также (JLD), DICOM Default JPEG Lossy Compression Transfer Syntax (JLD) может быть отклонён, если по крайней мере один из других Presentation Contexts для Abstract Syntax (AS1) принят.

10.4 Transfer Syntax для сжатия изображений DICOM RLE

DICOM определяет RLE Image Compression (см. Приложение G). Это означает, что:

Если Application Entity инициирует запрос A-ASSOCIATE, в котором любой предложенный Abstract Syntax связан в одном или нескольких Presentation Contexts(s) с Transfer Syntax сжатия RLE, по крайней мере один из Presentation Contexts, включающих этот Abstract Syntax, должен включать DICOM Default Little Endian Transfer Syntax (несжатый).

10.5 Transfer Syntaxes для значений DICOM по умолчанию для сжатия JPEG-LS без потерь и с потерями (Near-lossless)

Один Transfer Syntax специфицирован для JPEG-LS Lossless Image Compression и один Transfer Syntax специфицирован для JPEG-LS Lossy (Near-Lossless) Image Compression. JPEG-LS Lossless Transfer Syntax должен поддерживаться как базовый, если поддерживается JPEG-LS Lossy (Near-Lossless) Transfer Syntax.

10.6 Transfer Syntaxes для сжатия JPEG 2000

Один Transfer Syntax специфицирован для JPEG 2000 Image Compression (Lossless Only), и один Transfer Syntax специфицирован для JPEG 2000 Image Compression. Каждый из них может согласовываться отдельно, и значение по умолчанию или базовое не задано (за исключением описанного в Разделе 10.1).

Примечание

Все кодеки JPEG 2000 согласно [ISO/IEC 15444-1] должны поддерживать как обратимые, так и необратимые вейвлет-преобразования и многокомпонентные преобразования. Причина указания двух отдельных Transfer Syntaxes в DICOM состоит в том, чтобы позволить приложению запрашивать передачу изображений без потерь, когда это возможно. Transfer Syntax JPEG 2000 Image Compression допускает использование как сжатия без потерь, так и сжатия с потерями по усмотрению отправителя.
Базовое значение с использованием других схем сжатия не требуется.
Когда Pixel Data были получены в Transfer Syntax JPEG 2000 Image Compression, поскольку они могли быть сжаты с потерями, освобождение от требования Раздела 10.1 о поддержке DICOM Default Little Endian Transfer Syntax остаётся в силе.

Кроме того, один Transfer Syntax специфицирован для JPEG 2000 Multi-component Image Compression (Lossless Only) с расширениями Multi-Component Transformation Extensions, и один Transfer Syntax специфицирован для JPEG 2000 Multi-component Image Compression с расширениями Multi-Component Transformation Extensions. Каждый из них может согласовываться отдельно, и значение по умолчанию или базовое не задано (за исключением описанного в Разделе 10.1).

Примечание

Кодеки JPEG 2000, поддерживающие расширения Part 2 JPEG 2000 Multi-Component Transformation Extensions, должны поддерживать все многокомпонентные расширения, как описано в Приложении J [ISO/IEC 15444-2]. Они включают как преобразования на основе массивов, так и вейвлет-преобразования 9-7 и 5-3, которые также используются в Part 1 JPEG 2000. Это также включает переупорядочивание компонентов, коллекции компонентов и применение более одного многокомпонентного преобразования последовательно.

10.7 Transfer Syntaxes для сжатия видео MPEG2 Main Profile / Main Level

Два Transfer Syntaxes специфицированы для сжатия видео MPEG2 Main Profile / Main Level Video Compression.

10.8 Transfer Syntaxes для JPIP Referenced Pixel Data

Два Transfer Syntaxes специфицированы для JPIP Referenced Pixel Data.

Персистентность ссылок в объектах, переданных с одним из этих Transfer Syntaxes, не определена. То есть приложения не должны делать никаких предположений относительно времени, в течение которого указанные Pixel Data будут доступны. Из-за неопределённого времени, в течение которого URL остаётся действительным, может быть нецелесообразным кэшировать URL. Поскольку Pixel Data могли быть получены не полностью или не с полной точностью, может быть нецелесообразным использовать этот Transfer Syntax для постоянного хранения или ссылаться на такие экземпляры в классах сервисов Storage Commitment и Performed Procedure Step.

Эти Transfer Syntaxes не должны использоваться для хранения на носителях, определённом PS3.10.

10.9 Transfer Syntaxes для сжатия видео MPEG2 Main Profile / High Level

Два Transfer Syntaxes специфицированы для сжатия видео MPEG2 Main Profile / High Level Video Compression.

10.10 Transfer Syntaxes для сжатия видео MPEG-4 AVC/H.264 High Profile / Level 4.1

Два Transfer Syntaxes специфицированы для сжатия видео MPEG-4 AVC/H.264 High Profile / Level 4.1 Video Compression и два Transfer Syntaxes специфицированы для MPEG-4 AVC/H.264 BD-compliant High Profile / Level 4.1. Transfer Syntax MPEG-4 AVC/H.264 High Profile / Level 4.1 соответствует спецификациям профиля и уровня стандарта ITU-T H.264. Transfer Syntax MPEG-4 AVC/H.264 BD-compliant High Profile / Level 4.1 соответствует ограниченному набору пространственных и временных разрешений, описанных в Таблице 8-4. Этот Transfer Syntax ограничивает ITU-T H.264 High Profile / Level 4.1 форматами HD-видео, поддерживаемыми Blu-ray™ (BDRWP 2.B).

10.11 Transfer Syntaxes для сжатия видео MPEG-4 AVC/H.264 High Profile / Level 4.2

Два Transfer Syntaxes специфицированы для MPEG-4 AVC/H.264 High Profile / Level 4.2 для 2D Video Compression и два Transfer Syntaxes специфицированы для MPEG-4 AVC/H.264 High Profile / Level 4.2 для 3D Video Compression. Transfer Syntax MPEG-4 AVC/H.264 High Profile / Level 4.2 для 2D Video Compression соответствует спецификациям профиля и уровня стандарта ITU-T H.264, за исключением того, что использование форматов упаковки кадров для 3D-видео не допускается, как определено в Таблице 8-8. Transfer Syntax MPEG-4 AVC/H.264 High Profile / Level 4.2 для 3D Video Compression соответствует спецификациям профиля и уровня стандарта ITU-T H.264. Его следует использовать для передачи стереоскопического 3D-контента с форматами упаковки кадров, как определено в Таблице 8-8.

10.12 Transfer Syntaxes для сжатия видео MPEG-4 AVC/H.264 Stereo High Profile / Level 4.2

Два Transfer Syntaxes специфицированы для MPEG-4 AVC/H.264 Stereo High Profile / Level 4.2 Video Compression. Transfer Syntax MPEG-4 AVC/H.264 Stereo High Profile соответствует спецификациям профиля и уровня стандарта ITU-T H.264.

10.13 Transfer Syntax для сжатия видео HEVC/H.265 Main Profile / Level 5.1

Один Transfer Syntax специфицирован для HEVC/H.265 Main Profile / Level 5.1 Video Compression. Transfer Syntax HEVC/H.265 Main Profile соответствует спецификациям профиля и уровня стандарта HEVC [ISO/IEC 23008-2].

10.14 Transfer Syntax для сжатия видео HEVC/H.265 Main 10 Profile / Level 5.1

Один Transfer Syntax специфицирован для HEVC/H.265 Main 10 Profile / Level 5.1 Video Compression. Transfer Syntax HEVC/H.265 Main 10 Profile соответствует спецификациям профиля и уровня стандарта HEVC [ISO/IEC 23008-2].

10.15 Transfer Syntax для несжатого прогрессивного активного видео SMPTE ST 2110-20

Этот Transfer Syntax используется для пикселей несжатого видео, передаваемых в DICOM-RTV Flow (отделённом от DICOM-RTV Metadata Flow), как описано в [SMPTE ST 2110-20], в случае, когда видео является прогрессивным (например, 1080p). Основные параметры Transfer Syntax описаны в Разделе A.8.

10.16 Transfer Syntax для несжатого чересстрочного активного видео SMPTE ST 2110-20

Этот Transfer Syntax используется для пикселей несжатого видео, передаваемых в DICOM-RTV Flow (отделённом от DICOM-RTV Metadata Flow), как описано в [SMPTE ST 2110-20], в случае, когда видео является чересстрочным (например, 1080i). Основные параметры Transfer Syntax описаны в Разделе A.9.

10.16.1 Чересстрочное и прогрессивное видео

Чересстрочное видео поддерживает передачу видео с меньшей полосой пропускания. Один кадр содержит только нечётные строки, а следующий — только чётные строки. Чересстрочное видео приемлемо для отображения, но может вызывать проблемы при обработке изображений. Рекомендуется использовать прогрессивное видео. Однако в случае, когда исходный чересстрочный видеосигнал преобразуется в формат DICOM-RTV, рекомендуется сохранить чересстрочный формат и позволить обрабатывающему приложению работать с ним.

10.17 Transfer Syntax для PCM Digital Audio SMPTE ST 2110-30

Этот Transfer Syntax используется для данных аудиоканалов, передаваемых в DICOM-RTV Flow (отделённом от DICOM-RTV Metadata Flow), как описано в [SMPTE ST 2110-30]. Основные параметры Transfer Syntax описаны в Разделе A.10.

10.18 Transfer Syntaxes для сжатия High-Throughput JPEG 2000

Два Transfer Syntaxes специфицированы для High-Throughput JPEG 2000 Image Compression (Lossless Only) (HTJ2KLossless и HTJ2KLosslessRPCL) и один — для неконstrained High-Throughput JPEG 2000 Image Compression (HTJ2K). Любой из них может согласовываться отдельно, и значение по умолчанию или базовое не задано (за исключением описанного в Разделе 10.1).

Примечание

Все кодеки HTJ2K согласно [ISO/IEC 15444-1] должны поддерживать как обратимые, так и необратимые вейвлет-преобразования и многокомпонентные преобразования. Причина указания трёх отдельных Transfer Syntaxes в DICOM состоит в том, чтобы позволить приложению запрашивать передачу изображений без потерь, когда это возможно. Transfer Syntax HTJ2K Image Compression допускает использование как сжатия без потерь, так и сжатия с потерями по усмотрению отправителя.
Базовое значение с использованием других схем сжатия не требуется.
Когда Pixel Data были получены в Transfer Syntax HTJ2K Image Compression, поскольку они могли быть сжаты с потерями, освобождение от требования Раздела 10.1 о поддержке DICOM Default Little Endian Transfer Syntax остаётся в силе.

10.18.1 HTJ2K Lossless RPCL

Transfer Syntax HTJ2K Lossless RPCL обеспечивает прогрессивное отображение изображений, а также получение изображений-миниатюр.

Порядок прогрессии должен быть RPCL (Resolution Position Component Layer). Это упорядочивает блоки разрешения так, что более низкие разрешения могут считываться первыми.

Число декомпозиций должно быть достаточным для того, чтобы ширина или высота базового разрешения была <= 64. Это позволяет получать изображение в разрешении миниатюры.

Маркеры длины фрагментов (Tile Length Markers, TLM) должны присутствовать. Это позволяет находить точки разрыва разрешения для поддержки интеллектуальной потоковой передачи.

Следующие параметры могут повысить производительность декодирования:

Размер блока: 64x64
Количество фрагментов: 1

10.19 Transfer Syntaxes для сжатия JPEG XL без потерь и с потерями

Один Transfer Syntax специфицирован для JPEG XL Lossless Image Compression, один — для JPEG XL JPEG Recompression, который позволяет перекодировать данные, закодированные в JPEG, без дополнительных потерь, и один — для общей схемы сжатия JPEG XL Image Compression для любых данных, закодированных в JPEG XL. Любой из них может согласовываться отдельно, и значение по умолчанию или базовое не задано (за исключением описанного в Разделе 10.1).

Примечание

При перекодировании изображения, закодированного в JPEG Baseline, в JPEG XL, если используется JPEG XL JPEG Recompression Transfer Syntax, а не JPEG XL Transfer Syntax, это сообщает о том, что может быть восстановлено точное побитовое представление JPEG.

10.20 Transfer Syntax для сжатия Deflated Image Frame

Один Transfer Syntax специфицирован для сжатия Deflated Image Frame Compression. Значение по умолчанию или базовое не задано (за исключением описанного в Разделе 10.1).

Поскольку это Transfer Syntax без потерь (обратимый), когда Application Entity инициирует запрос A-ASSOCIATE, в котором любой предложенный Abstract Syntax связан в одном или нескольких Presentation Context(s) с Transfer Syntax сжатия Deflated Image Frame Compression, по крайней мере один из Presentation Contexts, включающих этот Abstract Syntax, должен включать DICOM Default Little Endian Transfer Syntax (несжатый).

A Спецификации Transfer Syntax (Нормативное)

A.1 DICOM Implicit VR Little Endian Transfer Syntax

Этот Transfer Syntax применяется к кодированию всего DICOM Data Set. Это означает, что при кодировании DICOM Data Set с использованием DICOM Implicit VR Little Endian Transfer Syntax должны выполняться следующие требования:

Data Elements, содержащиеся в структуре Data Set, должны быть закодированы с Implicit VR (без поля VR Field), как указано в Разделе 7.1.3.
Кодирование общей структуры Data Set (Data Element Tags, Value Length и Value) должно выполняться в Little Endian, как указано в Разделе 7.3.
Кодирование Data Elements из Data Set должно выполняться следующим образом в зависимости от их Value Representations:
- Для всех Value Representations, определённых в этой части, за исключением Value Representations OB и OW, кодирование должно выполняться в Little Endian, как указано в Разделе 7.3.
- Для Value Representations OB, OL, OV и OW кодирование должно соответствовать следующей спецификации в зависимости от Data Element Tag:
  - Pixel Data (7FE0,0010) имеет Value Representation OW и должен быть закодирован в Little Endian.
    
    Примечание
    
    Value Representations OL и OV не используются для Pixel Data, даже если Bits Allocated (0028,0100) равен 32 или 64, поскольку OL и OV были добавлены в стандарт после того, как кодирование Pixel Data уже было установлено
    
    32-битное поле Value Length Field для VR OW ограничивает максимальный размер Pixel Data, который может быть закодирован в Implicit VR Little Endian Transfer Syntax, до 2³²-2 байт максимум, поскольку они передаются в Native Format.
  - Overlay Data (60xx,3000) имеет Value Representation OW и должен быть закодирован в Little Endian.
  - Waveform Data (5400,1010) должен иметь Value Representation OW и должен быть закодирован в 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) и Alpha Palette Color Lookup Table Data (0028,1204) имеют Value Representation OW и должны быть закодированы в 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) в этой части, но указывали VR US или SS в PS3.6-1993, либо указывали OW в этой части, но VR US, SS или OW в PS3.6-1996. Фактическое кодирование значений и их порядок байтов были бы идентичны в каждом случае.
- Red Palette Color Lookup Table Descriptor (0028,1101), Green Palette Color Lookup Table Descriptor (0028,1102) и Blue Palette Color Lookup Table Descriptor (0028,1103) имеют Value Representation SS или US (в зависимости от правил, указанных в IOD в PS3.3) и должны быть закодированы в Little Endian. Первое и третье значения всегда интерпретируются как беззнаковые, независимо от Value Representation.
- Data Elements (0028,1221),(0028,1222),(0028,1223) Segmented Red, Green, Blue Palette Color Lookup Table Data имеют Value Representation OW и должны быть закодированы в Little Endian.
- LUT Data (0028,3006) имеет Value Representation US или OW и должен быть закодирован в Little Endian.
  
  Примечание
  
  Предыдущие версии стандарта не указывали кодирование этих Data Elements в этой части, но указывали VR US или SS в PS3.6-1998. VR OW был добавлен для поддержки Explicit VR Transfer Syntaxes. Кроме того, этот Data Element всегда беззнаковый, поэтому VR SS был удалён. Фактическое кодирование значений и их порядок байтов были бы идентичны в каждом случае.
- LUT Descriptor (0028,3002) имеет Value Representation SS или US (в зависимости от правил, указанных в IOD в PS3.3) и должен быть закодирован в Little Endian. Первое и третье значения всегда интерпретируются как беззнаковые, независимо от Value Representation.
- Blending Lookup Table Data (0028,1408) имеет Value Representation OW и должен быть закодирован в Little Endian.
- Track Point Index List (0066,0129) имеет Value Representation OL и должен быть закодирован в Little Endian и всегда интерпретируется как беззнаковый.

Примечание

Кодирование Curve Data (50xx,3000) и Audio Sample Data (50xx,200C) ранее было определено, но было выведено из употребления. См. PS3.5-2004.
Vertex Point Index List (0066,0025), Edge Point Index List (0066,0024), Triangle Point Index List (0066,0023) и Primitive Point Index List (0066,0029) ранее были определены с Value Representation OW и всегда интерпретировались как беззнаковые, но были выведены из употребления. Они были заменены соответствующими Data Elements OL, которые позволяют использовать значения больше 65535 для индексации полного диапазона точек, которые могут быть закодированы в Point Coordinates Data (0066,0016). См. PS3.5-2015c.

Этот DICOM Implicit VR Little Endian Transfer Syntax должен идентифицироваться UID со значением "1.2.840.10008.1.2".

A.2 DICOM Little Endian Transfer Syntax (Explicit VR)

Этот Transfer Syntax применяется к кодированию всего DICOM Data Set. Это означает, что при кодировании DICOM Data Set с использованием DICOM Little Endian Transfer Syntax должны выполняться следующие требования:

Data Elements, содержащиеся в структуре Data Set, должны быть закодированы с Explicit VR (с полем VR Field), как указано в Разделе 7.1.2.
Кодирование общей структуры Data Set (Data Element Tags, Value Length и Value) должно выполняться в Little Endian, как указано в Разделе 7.3.
Кодирование Data Elements из Data Set должно выполняться следующим образом в зависимости от их Value Representations:
- Для всех Value Representations, определённых в этой части, за исключением Value Representations OB и OW, кодирование должно выполняться в Little Endian, как указано в Разделе 7.3.
- Для Value Representations OB, OL, OV и OW кодирование должно соответствовать следующей спецификации в зависимости от Data Element Tag:
  - Pixel Data (7FE0,0010)
    
    если Bits Allocated (0028,0100) имеет значение больше 8, должен иметь Value Representation OW и должен быть закодирован в Little Endian;
    
    если Bits Allocated (0028,0100) имеет значение меньше или равное 8, должен иметь Value Representation OB или OW и должен быть закодирован в Little Endian.
    
    Примечание
    
    Value Representations OL и OV не используются для Pixel Data, даже если Bits Allocated (0028,0100) равен 32 или 64, поскольку OL и OV были добавлены в стандарт после того, как кодирование Pixel Data уже было установлено
    
    32-битное поле Value Length Field для VR OB и OW ограничивает максимальный размер Pixel Data, который может быть закодирован в Little Endian Transfer Syntax (Explicit VR), до 2³²-2 байт максимум, поскольку они передаются в Native Format.
  - Overlay Data (60xx,3000)
    
    должен иметь Value Representation OB или OW и должен быть закодирован в Little Endian.
    
    Примечание
    
    Предыдущие версии стандарта указывали, что выбор VR OB или OW основывался на том, было ли Overlay Bits Allocated (60xx,0100) больше, меньше или равно 8. Однако, поскольку в каждом элементе Overlay Data (60xx,3000) может быть закодирован только один битовый слой, любое значение Overlay Bits Allocated, отличное от 1, не имеет смысла. Такое ограничение теперь присутствует в PS3.3.
  - Waveform Data (5400,1010) имеет Value Representation, указанное в его поле Explicit VR Field. Точки компонентов должны быть закодированы в 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) и Alpha Palette Color Lookup Table Data (0028,1204) имеют Value Representation OW и должны быть закодированы в 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) в этой части, но указывали VR US или SS в PS3.6-1993, либо указывали OW в этой части, но VR US, SS или OW в PS3.6-1996. Фактическое кодирование значений и их порядок байтов были бы идентичны в каждом случае, хотя явно закодированное поле VR было бы разным. Однако Explicit VR US или SS не может использоваться для кодирования таблицы из 2¹⁶ записей, поскольку Value Length ограничена 16 битами.
  - Red Palette Color Lookup Table Descriptor (0028,1101), Green Palette Color Lookup Table Descriptor (0028,1102) и Blue Palette Color Lookup Table Descriptor (0028,1103) имеют Value Representation SS или US (в зависимости от правил, указанных в IOD в PS3.3) и должны быть закодированы в Little Endian. Первое и третье значения всегда интерпретируются как беззнаковые, независимо от Value Representation.
  - Segmented Red Palette Color Lookup Table Data (0028,1221), Segmented Green Palette Color Lookup Table Data (0028,1222) и Segmented Blue Palette Color Lookup Table Data (0028,1223) имеют Value Representation OW и должны быть закодированы в Little Endian.
  - LUT Data (0028,3006) имеет Value Representation US или OW и должен быть закодирован в Little Endian.
    
    Примечание
    
    Предыдущие версии стандарта не указывали кодирование этих Data Elements в этой части, но указывали VR US или SS в PS3.6-1998. Однако Explicit VR US или SS не может использоваться для кодирования таблицы из 2¹⁶ записей, поскольку Value Length ограничена 16 битами. Поэтому был добавлен VR OW. Кроме того, этот Data Element всегда беззнаковый, поэтому VR SS был удалён. Фактическое кодирование значений и их порядок байтов были бы идентичны в каждом случае, хотя явно закодированное поле VR было бы разным.
  - LUT Descriptor (0028,3002) имеет Value Representation SS или US (в зависимости от правил, указанных в IOD в PS3.3) и должен быть закодирован в Little Endian. Первое и третье значения всегда интерпретируются как беззнаковые, независимо от Value Representation.
  - Blending Lookup Table Data (0028,1408) имеет Value Representation OW и должен быть закодирован в Little Endian.
  - Track Point Index List (0066,0129) имеет Value Representation OL и должен быть закодирован в Little Endian и всегда интерпретируется как беззнаковый.

Примечание

Для данных, закодированных с Value Representation OB, кодирование данных не зависит от порядка байтов.
Кодирование Curve Data (50xx,3000) и Audio Sample Data (50xx,200C) ранее было определено, но было выведено из употребления. См. PS3.5-2004.
Vertex Point Index List (0066,0025), Edge Point Index List (0066,0024), Triangle Point Index List (0066,0023) и Primitive Point Index List (0066,0029) ранее были определены с Value Representation OW и всегда интерпретировались как беззнаковые, но были выведены из употребления. Они были заменены соответствующими Data Elements OL, которые позволяют использовать значения больше 65535 для индексации полного диапазона точек, которые могут быть закодированы в Point Coordinates Data (0066,0016). См. PS3.5-2015c.

Этот DICOM Explicit VR Little Endian Transfer Syntax должен идентифицироваться UID со значением "1.2.840.10008.1.2.1".

A.3 DICOM Big Endian Transfer Syntax (Explicit VR) — удалён

Этот Transfer Syntax был удалён в 2006 году. За самым последним описанием обращайтесь к PS3.5 2016b.

A.4 Transfer Syntaxes для инкапсуляции закодированных пиксельных данных

Эти Transfer Syntaxes применяются к кодированию всего набора данных DICOM (DICOM Data Set), хотя часть набора данных — Pixel Data (7FE0,0010) — является единственной частью, которая кодируется в инкапсулированном формате. Эти Transfer Syntaxes должны использоваться только если Pixel Data (7FE0,0010) присутствует в наборе данных верхнего уровня, и, следовательно, не должны использоваться, если присутствуют Float Pixel Data (7FE0,0008) или Double Float Pixel Data (7FE0,0009). Это означает, что при кодировании DICOM Message в соответствии с Transfer Syntax инкапсуляции должны выполняться следующие требования:

Элементы данных (Data Elements), содержащиеся в структуре набора данных, должны быть закодированы с Explicit VR (с полем VR), как указано в Разделе 7.1.2.
Кодирование общей структуры набора данных (теги элементов данных, длина значения и т.д.) должно выполняться в Little Endian, как указано в Разделе 7.3.
Кодирование элементов данных набора данных должно выполняться следующим образом в зависимости от их представлений значений (Value Representations):
- Для всех представлений значений (Value Representations), определённых в этой части стандарта DICOM, за исключением представлений значений OB и OW, кодирование должно выполняться в Little Endian, как указано в Разделе 7.3.
- Для представлений значений OB, OL, OV и OW кодирование должно соответствовать следующей спецификации в зависимости от тега элемента данных:
  - Pixel Data (7FE0,0010) может быть в инкапсулированном формате (Encapsulated Format) или собственном формате (Native Format).
    
    Он должен быть в инкапсулированном формате (Encapsulated Format), если присутствует в наборе данных верхнего уровня (т.е. не вложен в элемент данных последовательности (Sequence Data Element)).
    
    Примечание
    
    Различие между явной длиной значения (Explicit Value Length) (собственный формат (Native Format)) и неопределённой длиной значения (Undefined Value Length) (инкапсулированный формат (Encapsulated Format)) предусмотрено для того, чтобы пиксельные данные набора данных верхнего уровня могли быть сжаты (и, следовательно, инкапсулированы), тогда как пиксельные данные в последовательности значков (Icon Image Sequence) могут быть как сжатыми, так и несжатыми.
    
    Если используется собственный формат (Native Format), он должен иметь явную длину значения (Explicit Value Length) и кодироваться следующим образом:
    
    если Bits Allocated (0028,0100) имеет значение больше 8, должно иметь представление значения OW и кодироваться в Little Endian;
    
    если Bits Allocated (0028,0100) имеет значение меньше или равно 8, должно иметь представление значения OB или OW и кодироваться в Little Endian.
    
    Примечание
    
    Представления значений OL и OV не используются для пиксельных данных, даже если Bits Allocated (0028,0100) равно 32 или 64, поскольку OL и OV были добавлены в стандарт после того, как кодирование пиксельных данных уже было установлено
    
    То есть так, как если бы Transfer Syntax был Explicit VR Little Endian.
    
    Если используется инкапсулированный формат (Encapsulated Format), он имеет представление значения OB и представляет собой октетный поток (octet-stream), полученный в результате одного из процессов кодирования. Он содержит закодированный поток пиксельных данных (Pixel Data Stream), фрагментированный на один или несколько элементов (Item(s)). Этот поток пиксельных данных может представлять одиночный кадр (Single-frame) или многокадровое (Multi-frame) изображение. См. Таблицу A.4-1 и Таблицу A.4-2.
    
    Длина элемента данных (7FE0,0010) должна быть установлена в значение неопределённой длины (Undefined Length) (FFFFFFFFH).
    
    Каждый фрагмент потока данных (Data Stream Fragment), закодированный в соответствии с конкретным процессом кодирования, должен быть инкапсулирован как DICOM Item со специфическим тегом элемента данных (Data Element Tag) со значением (FFFE,E000). За тегом элемента (Item Tag) следует 4-байтовое поле длины значения (Item Length Field), кодирующее явное количество байтов элемента (Item).
    
    Примечание
    
    Допускается ли более одного фрагмента на кадр или нет, определяется для каждого Transfer Syntax отдельно.
    
    Все элементы, содержащие закодированный фрагмент (Fragment), должны состоять из чётного количества байтов, большего или равного двум. Последний фрагмент кадра может быть дополнен (padded) при необходимости для соответствия требованиям формата Sequence Item стандарта DICOM.
    
    Примечание
    
    Любое необходимое выравнивание (padding) может быть добавлено в сжатый поток данных JPEG или JPEG-LS в соответствии с [ISO/IEC 10918-1] и [ISO/IEC 14495-1] таким образом, чтобы маркер конца изображения (End of Image, EOI) заканчивался на границе чётного байта, или может быть добавлен после маркера EOI, в зависимости от реализации.
    
    [ISO/IEC 10918-1] и [ISO/IEC 14495-1] определяют возможность добавления любого количества байтов выравнивания FFH перед любым маркером (все они также начинаются с FFH). Настоятельно рекомендуется не добавлять байты выравнивания FFH перед маркером начала изображения (Start of Image, SOI).
    
    Конец дефлированного битового потока (deflated bit stream) будет обозначен ограничителем, который появится перед любым необходимым выравниванием одним завершающим нулевым байтом (NULL byte).
    
    Первый элемент в последовательности элементов (Sequence of Items) перед закодированным потоком пиксельных данных должен быть элементом таблицы базовых смещений (Basic Offset Table). Однако значение элемента таблицы базовых смещений (Basic Offset Table Item Value) не обязательно должно присутствовать:
    
    Когда значение элемента (Item Value) отсутствует, длина элемента (Item Length) должна быть равна нулю (00000000H) (см. Таблицу A.4-1).
    
    Когда значение элемента (Item Value) присутствует, значение элемента таблицы базовых смещений (Basic Offset Table Item Value) должно содержать конкатенированные 32-битные целочисленные значения без знака, являющиеся байтовыми смещениями к первому байту тега элемента (Item Tag) первого фрагмента (Fragment) для каждого кадра (Frame) в последовательности элементов (Sequence of Items). Эти смещения измеряются от первого байта первого тега элемента (Item Tag), следующего за элементом таблицы базовых смещений (Basic Offset Table item) (см. Таблицу A.4-2).
    
    Примечание
    
    Для многокадрового изображения (Multi-frame Image), содержащего только один кадр (Frame), или однокадрового изображения (Single-frame Image), значение элемента таблицы базовых смещений (Basic Offset Table Item Value) может присутствовать или нет. Если оно присутствует, оно будет содержать единственное значение 00000000H.
    
    Декодеры инкапсулированных пиксельных данных (encapsulated Pixel Data), как однокадровые (Single-frame), так и многокадровые (Multi-frame), должны принимать как пустую таблицу базовых смещений (Basic Offset Table) (нулевой длины), так и таблицу базовых смещений, заполненную 32-битными значениями смещений.
    
    Значение элемента таблицы базовых смещений (Basic Offset Table Item Value) не допускается (т.е. длина элемента (Item Length) первого элемента будет равна нулю), если присутствует Extended Offset Table (7FE0,0001).
    
    Если значение элемента таблицы базовых смещений (Basic Offset Table Item Value) не имеет нулевую длину, первая запись всегда будет 00000000H.
    
    Смещение указывает на первый байт самого тега элемента (Item Tag), а не на первый байт поля значения (Value Field) внутри элемента (Item)
    
    Эта последовательность элементов (Sequence of Items) завершается элементом ограничения последовательности (Sequence Delimitation Item) с тегом (Tag) (FFFE,E0DD) и полем длины значения (Value (Item) Length Field) со значением (00000000H) (т.е. поле значения (Value Field) не должно присутствовать).
    
    Примечание
    
    Декодеру набора данных (Data Set) потребуется проанализировать поле значения (Value Field), обрабатывая элементы Item, чтобы определить конец поля значения. Он не может выполнять поиск элемента ограничения последовательности (Sequence Delimitation Item), поскольку последовательность байтов, из которой он состоит, может быть допустимым значением в поле значения (Value Field), и механизм экранирования отсутствует.
  - Overlay Data (60xx,3000)
    
    должен иметь представление значения OB или OW и должен кодироваться в Little Endian.
  - Waveform Data (5400,1010) имеет представление значения, указанное в его поле Explicit VR. Компонентные точки (component points) должны кодироваться в 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) и Alpha Palette Color Lookup Table Data (0028,1204) имеют представление значения OW и должны кодироваться в Little Endian.
    
    Примечание
    
    Предыдущие версии стандарта либо не указывали кодирование элементов данных (0028,1201), (0028,1202), (0028,1203) в этой части, но указывали VR US или SS в PS3.6-1993, либо указывали OW в этой части, но VR US, SS или OW в PS3.6-1996. Фактическое кодирование значений и их порядок байтов были бы идентичны в каждом случае, хотя явно закодированное поле VR было бы другим. Однако Explicit VR US или SS не может использоваться для кодирования таблицы из 2¹⁶ записей, поскольку длина значения (Value Length) ограничена 16 битами.
  - Red Palette Color Lookup Table Descriptor (0028,1101), Green Palette Color Lookup Table Descriptor (0028,1102) и Blue Palette Color Lookup Table Descriptor (0028,1103) имеют представление значения SS или US (в зависимости от правил, указанных в IOD в PS3.3), и должны кодироваться в Little Endian. Первое и третье значения всегда интерпретируются как беззнаковые, независимо от представления значения.
  - Segmented Red Palette Color Lookup Table Data (0028,1221), Segmented Green Palette Color Lookup Table Data (0028,1222) и Segmented Blue Palette Color Lookup Table Data (0028,1223) имеют представление значения OW и должны кодироваться в Little Endian.
  - LUT Data (0028,3006) имеет представление значения US или OW и должно кодироваться в Little Endian.
    
    Примечание
    
    Предыдущие версии стандарта не указывали кодирование этих элементов данных в этой части, но указывали VR US или SS в PS3.6-1998. Однако Explicit VR US или SS не может использоваться для кодирования таблицы из 2¹⁶ записей, поскольку длина значения (Value Length) ограничена 16 битами. Следовательно, была добавлена VR OW. Кроме того, этот элемент данных всегда беззнаковый, поэтому VR SS была удалена. Фактическое кодирование значений и их порядок байтов были бы идентичны в каждом случае, хотя явно закодированное поле VR было бы другим.
  - LUT Descriptor (0028,3002) имеет представление значения SS или US (в зависимости от правил, указанных в IOD в PS3.3), и должен кодироваться в Little Endian. Первое и третье значения всегда интерпретируются как беззнаковые, независимо от представления значения.
  - Blending Lookup Table Data (0028,1408) имеет представление значения OW и должен кодироваться в Little Endian.
  - Track Point Index List (0066,0129) имеет представление значения OL и должен кодироваться в Little Endian и всегда интерпретируется как беззнаковый.

Примечание

Для данных, закодированных с представлением значения OB, кодирование данных не зависит от порядка байтов.
Кодирование Curve Data (50xx,3000) и Audio Sample Data (50xx,200C) ранее было определено, но было удалено. См. PS3.5-2004.
Vertex Point Index List (0066,0025), Edge Point Index List (0066,0024), Triangle Point Index List (0066,0023) и Primitive Point Index List (0066,0029) ранее были определены с представлением значения OW и всегда интерпретировались как беззнаковые, но были удалены. Они были заменены соответствующими элементами данных OL, которые позволяют использовать значения больше 65535 для индексации полного диапазона точек, которые могут быть закодированы в Point Coordinates Data (0066,0016). См. PS3.5-2015c.

Таблица A.4-1. Пример элементов закодированного однокадрового изображения, определённого как последовательность трёх фрагментов без значения элемента таблицы базовых смещений

Тег элемента Pixel Data	Представление значения		Длина элемента данных	Элемент данных
(7FE0, 0010) с VR OB	OB	0000H Зарезервировано	FFFF FFFFH Неопределённая длина	Таблица базовых смещений БЕЗ значения элемента		Первый фрагмент (одиночный кадр) Pixel Data
				Тег элемента (Item Tag)	Длина элемента (Item Length)	Тег элемента (Item Tag)	Длина элемента (Item Length)	Значение элемента (Item Value)
				(FFFE, E000)	0000 0000H	(FFFE, E000)	0000 04C6H	Сжатый фрагмент
4 байта	2 байта	2 байта	4 байта	4 байта	4 байта	4 байта	4 байта	04C6H байт

Таблица A.4-1b. Пример элементов закодированного однокадрового изображения, определённого как последовательность трёх фрагментов без значения элемента таблицы базовых смещений (продолжение)

Элемент данных (продолжение)
Второй фрагмент (одиночный кадр) Pixel Data			Третий фрагмент (одиночный кадр) Pixel Data			Элемент ограничения последовательности
Тег элемента (Item Tag)	Длина элемента (Item Length)	Значение элемента (Item Value)	Тег элемента (Item Tag)	Длина элемента (Item Length)	Значение элемента (Item Value)	Тег элемента ограничения последовательности	Длина элемента (Item Length)
(FFFE, E000)	0000 024AH	Сжатый фрагмент	(FFFE, E000)	0000 0628H	Сжатый фрагмент	(FFFE,E0DD)	0000 0000H
4 байта	4 байта	024AH байт	4 байта	4 байта	0628H байт	4 байта	4 байта

Таблица A.4-2. Примеры элементов закодированного двухкадрового изображения, определённого как последовательность трёх фрагментов со значениями элементов таблицы базовых смещений

Тег элемента Pixel Data	Представление значения		Длина элемента данных	Элемент данных
(7FE0, 0010) с VR OB	OB	0000H Зарезервировано	FFFF FFFFH Неопределённая длина	Таблица базовых смещений со значением элемента			Первый фрагмент (Кадр 1) Pixel Data
				Тег элемента (Item Tag)	Длина элемента (Item Length)	Значение элемента (Item Value)	Тег элемента (Item Tag)	Длина элемента (Item Length)	Значение элемента (Item Value)
				(FFFE, E000)	0000 0008H	0000 0000H 0000 0646H	(FFFE, E000)	0000 02C8H	Сжатый фрагмент
4 байта	2 байта	2 байта	4 байта	4 байта	4 байта	0008H байт	4 байта	4 байта	02C8H байт

Таблица A.4-2b. Примеры элементов закодированного двухкадрового изображения, определённого как последовательность трёх фрагментов со значениями элементов таблицы базовых смещений (продолжение)

Элемент данных (продолжение)
Второй фрагмент (Кадр 1) Pixel Data			Третий фрагмент (Кадр 2) Pixel Data			Элемент ограничения последовательности
Тег элемента (Item Tag)	Длина элемента (Item Length)	Значение элемента (Item Value)	Тег элемента (Item Tag)	Длина элемента (Item Length)	Значение элемента (Item Value)	Тег элемента ограничения последовательности	Длина элемента (Item Length)
(FFFE, E000)	0000 036EH	Сжатый фрагмент	(FFFE, E000)	0000 0BC8H	Сжатый фрагмент	(FFFE, E0DD)	0000 0000H
4 байта	4 байта	036EH байт	4 байта	4 байта	0BC8H байт	4 байта	4 байта

A.4.1 Сжатие изображений JPEG

Международная организация по стандартизации ISO/IEC JTC1 разработала международный стандарт [ISO/IEC 10918-1] (JPEG Part 1) и международный стандарт [ISO/IEC 10918-2] (JPEG Part 2), известные как стандарт JPEG, для цифрового сжатия и кодирования полутоновых неподвижных изображений (дополнительные сведения см. в Приложении F).

DICOM Transfer Syntax для сжатия изображений JPEG должен идентифицироваться UID, соответствующим его процессу JPEG-кодирования, выбранным из Таблицы A.4-3.

Таблица A.4-3. UID Transfer Syntax DICOM для JPEG

UID DICOM Transfer Syntax	Процесс JPEG-кодирования	Описание JPEG
1.2.840.10008.1.2.4.50	1	базовый (baseline)
1.2.840.10008.1.2.4.51	2(8-bit),4(12-bit)	расширенный (extended)
1.2.840.10008.1.2.4.57	14	без потерь, неиерархический
1.2.840.10008.1.2.4.70	14 (Значение выбора 1)	без потерь, неиерархический, предсказание первого порядка

Примечание

DICOM определяет, чтобы повысить вероятность успешной ассоциации, три Transfer Syntaxes для процессов сжатия изображений JPEG по умолчанию (см. Раздел 8.2.1 и Раздел 10).
Различные процессы JPEG могут использовать различные сегменты маркеров SOF. Например, базовый процесс JPEG 1, используемый с Transfer Syntax 1.2.840.10008.1.2.4.50, использует маркер SOF0, тогда как расширенный процесс 2, используемый с Transfer Syntax 1.2.840.10008.1.2.4.51, использует маркер SOF1. Следовательно, хотя оба битовых потока кодируют 8-битные изображения с использованием DCT и кодирования Хаффмана, битовые потоки не идентичны. Более того, расширенный процесс 2 может (но не обязан) использовать больше таблиц AC и DC (до 4 каждой, а не 2, см. [ISO/IEC 10918-1], раздел F.1.3).

Несоответствует стандарту отправлять битовые потоки с маркером SOF0 с использованием Transfer Syntax 1.2.840.10008.1.2.4.51, но рекомендуется, чтобы получатели Transfer Syntax 1.2.840.10008.1.2.4.51 могли декодировать битовые потоки с маркером SOF0 (эта асимметрия соответствует требованиям [ISO/IEC 10918-2]; см. A.4.1).
Рекомендуется кодировать 8-битные изображения, сжатые с потерями, с использованием Transfer Syntax 1.2.840.10008.1.2.4.50, а не 1.2.840.10008.1.2.4.51, если не требуются дополнительные функции расширенного процесса. Поддержка Transfer Syntax 1.2.840.10008.1.2.4.50 требуется для 8-битных изображений в любом случае (как описано в 8.2.1) и для избежания путаницы с использованием 12-битных изображений, закодированных с процессом 4 в Transfer Syntax 1.2.840.10008.1.2.4.51 (определённом как значение по умолчанию для 12-битных изображений в 10.3).

Если объект допускает многокадровые изображения в Pixel Data (7FE0,0010), то каждый кадр должен кодироваться отдельно.

Каждый фрагмент должен содержать закодированные данные только одного кадра.

Примечание

Хотя фрагмент не может содержать закодированные данные более чем одного кадра, закодированные данные одного кадра могут охватывать несколько фрагментов. См. примечание в Разделе 8.2.

Для всех изображений, включая все кадры многокадрового изображения, должен использоваться JPEG Interchange Format (должно быть включено спецификация таблицы).

Примечание

Это относится к "interchange format" [ISO/IEC 10918-1], а не к JPEG File Interchange Format (JFIF) [ISO/IEC 10918-5].

Если изображения с Photometric Interpretation (0028,0004) YBR_FULL_422 или YBR_PARTIAL_422 кодируются с процессом JPEG-кодирования 1 (неиерархический с кодированием Хаффмана), идентифицируемым UID DICOM Transfer Syntax "1.2.840.10008.1.2.4.50", минимальной сжимаемой единицей является YYCBCR, где Y, CB и CR — это блоки пиксельных значений размером 8 на 8. Поток данных кодирует два блока Y, за которыми следуют соответствующие блоки CB и CR.

A.4.2 Сжатие изображений RLE

Приложение G определяет Transfer Syntax сжатия изображений RLE. Этот Transfer Syntax идентифицируется UID "1.2.840.10008.1.2.5".

Если объект допускает многокадровые изображения в Pixel Data (7FE0,0010), то каждый кадр должен кодироваться отдельно.

Каждый кадр должен кодироваться в одном и только одном фрагменте (см. Раздел 8.2).

A.4.3 Сжатие изображений JPEG-LS

Международная организация по стандартизации ISO/IEC JTC1 разработала международный стандарт [ISO/IEC 14495-1] (JPEG-LS Part 1) для цифрового сжатия и кодирования полутоновых неподвижных изображений (дополнительные сведения см. в Приложении F).

DICOM Transfer Syntax для сжатия изображений JPEG-LS должен идентифицироваться UID, соответствующим его процессу JPEG-LS-кодирования.

Для JPEG-LS определены два Transfer Syntaxes:

Transfer Syntax с UID "1.2.840.10008.1.2.4.80 ", определяющий использование режима без потерь JPEG-LS. В этом режиме абсолютная ошибка между исходным и реконструированным изображениями будет равна нулю.
Transfer Syntax с UID "1.2.840.10008.1.2.4.81 ", определяющий использование приблизительно безпотерного (near-lossless) режима JPEG-LS. В этом режиме абсолютная ошибка между исходным и реконструированным изображениями будет ограничена конечным значением, которое передаётся в сжатом битовом потоке. Следует отметить, что этот процесс может, по усмотрению кодировщика, использоваться для сжатия изображений с ошибкой, ограниченной значением ноль, что приводит к отсутствию потерь информации.

Если объект допускает многокадровые изображения в Pixel Data (7FE0,0010), то каждый кадр должен кодироваться отдельно.

Каждый фрагмент должен содержать закодированные данные только одного кадра.

Примечание

Для всех изображений, включая все кадры многокадрового изображения, должен использоваться JPEG-LS Interchange Format (должны быть включены все спецификации параметров).

A.4.4 Сжатие изображений JPEG 2000

Международная организация по стандартизации ISO/IEC JTC1 разработала международный стандарт [ISO/IEC 15444-1] (JPEG 2000 Part 1) для цифрового сжатия и кодирования полутоновых неподвижных изображений (дополнительные сведения см. в Приложении F). Дополнительно существует схема сжатия изображений High-Throughput JPEG 2000, определённая в [ISO/IEC 15444-15] (JPEG 2000 Part 15 HTJ2K).

DICOM Transfer Syntax для сжатия изображений JPEG 2000 должен идентифицироваться UID, соответствующим выбранному процессу JPEG 2000-кодирования.

Для JPEG 2000 Part 1 определены два Transfer Syntaxes:

Transfer Syntax с UID "1.2.840.10008.1.2.4.90", определяющий использование режима без потерь (обратимого) JPEG 2000 Part 1 ([ISO/IEC 15444-1]) (т.е. использование обратимого вейвлет-преобразования и обратимого преобразования цветовых компонентов, если применимо, и без квантования).
Transfer Syntax с UID "1.2.840.10008.1.2.4.91", определяющий использование либо:
1. режима без потерь (обратимого) JPEG 2000 Part 1 ([ISO/IEC 15444-1]) (т.е. использования обратимого вейвлет-преобразования и обратимого преобразования цветовых компонентов, если применимо, и без квантования или усечения кодового потока), либо
2. режима с потерями (необратимого) JPEG 2000 Part 1 ([ISO/IEC 15444-1]) (т.е. использования необратимого вейвлет-преобразования и необратимого преобразования цветовых компонентов, если применимо, и дополнительно квантования, либо использования обратимого вейвлет-преобразования и обратимого преобразования цветовых компонентов, если применимо, с последующим усечением кодового потока).
Выбор обратимого или необратимого режима остаётся на усмотрении отправителя (SCU или FSC/FSU).

Примечание

При использовании необратимого вейвлет-преобразования и необратимого преобразования цветовых компонентов, если применимо, даже если квантование не выполняется, всегда будет происходить некоторая потеря из-за конечной точности вычисления вейвлет- и мультикомпонентных преобразований.

Для этих двух Transfer Syntaxes разрешены только функции, определённые в JPEG 2000 Part 1 ([ISO/IEC 15444-1]). Дополнительные функции и расширения, которые могут быть определены в других частях JPEG 2000, не должны включаться в сжатый битовый поток, если они не могут быть декодированы или проигнорированы без потери качества всеми реализациями, соответствующими Part 1.

DICOM Transfer Syntax для сжатия изображений HTJ2K должен идентифицироваться значением UID, соответствующим его процессу HTJ2K-кодирования.

Для HTJ2K определены три Transfer Syntaxes:

Transfer Syntax с UID "1.2.840.10008.1.2.4.201", определяющий использование режима без потерь HTJ2K.
Transfer Syntax с UID "1.2.840.10008.1.2.4.202", определяющий использование режима без потерь HTJ2K с параметрами сжатия, позволяющими прогрессивную визуализацию.
Transfer Syntax с UID "1.2.840.10008.1.2.4.203", определяющий использование либо:
1. режима без потерь (обратимого) HTJ2K ([ISO/IEC 15444-15]) (т.е. использования обратимого вейвлет-преобразования и обратимого преобразования цветовых компонентов, если применимо, и без квантования или усечения кодового потока), либо
2. режима с потерями (необратимого) HTJ2K ([ISO/IEC 15444-15]) (т.е. использования необратимого вейвлет-преобразования и необратимого преобразования цветовых компонентов, если применимо, и дополнительно квантования, либо использования обратимого вейвлет-преобразования и обратимого преобразования цветовых компонентов, если применимо, с последующим усечением кодового потока).

Если объект допускает многокадровые изображения в Pixel Data (7FE0,0010), то как для Transfer Syntaxes JPEG 2000 Part 1, так и для Transfer Syntaxes HTJ2K, каждый кадр должен кодироваться отдельно.

Каждый фрагмент должен содержать закодированные данные только одного кадра.

Примечание

Т.е. процессы, определённые в [ISO/IEC 15444-1] или [ISO/IEC 15444-15], должны применяться покадрово. Предложение по инкапсуляции нескольких кадров не-DICOM образом, так называемое "Motion-JPEG" или "M-JPEG", определённое в 15444-3, не используется.
Хотя фрагмент не может содержать закодированные данные более чем одного кадра, для Transfer Syntaxes JPEG 2000 закодированные данные одного кадра могут охватывать несколько фрагментов. См. примечание в Разделе 8.2.

Для HTJ2K-кодирования каждый кадр должен кодироваться отдельно как один фрагмент.

Для всех изображений, включая все кадры многокадрового изображения, должен использоваться битовый поток JPEG 2000, определённый в [ISO/IEC 15444-1] или [ISO/IEC 15444-15]. Необязательный заголовок файла формата JP2 не должен быть включён.

Примечание

Роль заголовка файла формата JP2 выполняется атрибутами, не относящимися к пиксельным данным, в наборе данных DICOM.

Международная организация по стандартизации ISO/IEC JTC1 также разработала JPEG 2000 Part 2 ([ISO/IEC 15444-2]), которая включает расширения методов сжатия, описанных в Part 1 стандарта JPEG 2000. Приложение J к JPEG 2000 Part 2 описывает расширения мультикомпонентных преобразований ICT и RCT, разрешённых в Part 1. В Приложении J к Part 2 стандарта JPEG 2000 определены два типа мультикомпонентных преобразований:

Массивные мультикомпонентные преобразования, формирующие линейные комбинации компонентов для снижения корреляции между компонентами. Массивные преобразования включают преобразования на основе предсказаний, такие как DPCM, а также более сложные преобразования, такие как KLT. Эти массивные преобразования могут быть реализованы обратимо или необратимо.
Вейвлет-преобразования мультикомпонентных преобразований с использованием тех же двух вейвлет-фильтров, что и в Part 1 JPEG 2000 (обратимый вейвлет 5-3 и необратимый вейвлет 9-7).

Приложение J к JPEG 2000 Part 2 также описывает гибкий механизм, позволяющий применять эти методы последовательно. Более того, оно предоставляет механизмы, позволяющие переупорядочивать компоненты и группировать их в коллекции компонентов. Затем к каждой коллекции компонентов может быть применено различное мультикомпонентное преобразование.

Для JPEG 2000 Part 2 определены два дополнительных Transfer Syntaxes:

Transfer Syntax с UID 1.2.840.10008.1.2.4.92, определяющий использование режима без потерь (обратимого) расширений мультикомпонентных преобразований JPEG 2000 Part 2 ([ISO/IEC 15444-2]), как определено в Приложении J к JPEG 2000 Part 2 (т.е. использование обратимого вейвлет-преобразования и обратимого мультикомпонентного преобразования, и без квантования или усечения кодового потока).
Transfer Syntax с UID 1.2.840.10008.1.2.4.93, определяющий использование либо:
1. режима без потерь (обратимого) расширений мультикомпонентных преобразований JPEG 2000 Part 2 ([ISO/IEC 15444-2]), как определено в Приложении J к JPEG 2000 Part 2 (т.е. использования обратимого вейвлет-преобразования и обратимого мультикомпонентного преобразования и без квантования), либо
2. режима с потерями (необратимого) расширений мультикомпонентных преобразований JPEG 2000 Part 2 ([ISO/IEC 15444-2]), как определено в Приложении J к JPEG 2000 Part 2 (т.е. использования необратимого вейвлет-преобразования и необратимого мультикомпонентного преобразования и дополнительно квантования, либо использования обратимого вейвлет-преобразования и обратимого мультикомпонентного преобразования с последующим усечением кодового потока).

Для этих двух Transfer Syntaxes разрешены только расширения мультикомпонентных преобразований, определённые в Приложении J к JPEG 2000 Part 2 ([ISO/IEC 15444-2]). Дополнительные функции и расширения, которые могут быть определены в других Приложениях JPEG 2000 Part 2, не должны включаться в сжатый битовый поток.

Примечание

Произвольные вейвлет-преобразования, определённые в Приложении H к JPEG 2000 Part 2 ([ISO/IEC 15444-2]), не разрешены для этих двух Transfer Syntaxes. Единственные вейвлет-преобразования, которые разрешено использовать в качестве мультикомпонентных преобразований, — это обратимое вейвлет-преобразование 5-3 и необратимое вейвлет-преобразование 9-7, определённые в Приложении F к JPEG 2000 Part 1 ([ISO/IEC 15444-1]).

Если объект допускает многокадровые изображения в Pixel Data (7FE0,0010), то для этих Transfer Syntaxes JPEG 2000 Part 2 кадры в объекте сначала обрабатываются с использованием мультикомпонентного преобразования.

После применения мультикомпонентного преобразования преобразованные кадры кодируются с использованием процесса, описанного в JPEG 2000 Part 1.

Дополнительно кадры могут быть сгруппированы в одну или несколько коллекций компонентов. Затем мультикомпонентные преобразования применяются к каждой коллекции компонентов независимо. Использование коллекций компонентов может применяться для снижения вычислительной сложности и улучшения доступа к определённым кадрам на декодере. Если используются коллекции компонентов, каждый фрагмент должен содержать закодированные данные только одной коллекции компонентов.

Примечание

Преобразования 3-й размерности, описанные в этом дополнении, рассматриваются в Part 2 JPEG 2000 как прямые расширения преобразований цветовых компонентов (RGB в YUV), описанных в Part 1 JPEG 2000. По этой причине каждое изображение или кадр в последовательности называется "компонентом". Хотя термин "компонент" используется как универсальный термин для обозначения элемента 3-й размерности, не делается и не подразумевается ограничение того, что преобразования в этом дополнении применимы только к мультикомпонентным (или многоканальным цветным) данным. Для сжатия объёмного набора данных с использованием этого Transfer Syntax каждый кадр DICOM-изображения рассматривается как компонент мультикомпонентного изображения.
Прогрессивная природа кодового потока JPEG 2000 позволяет выполнять декомпрессию изображения до того, как полное изображение было передано. Если Storage SCP усекает кодовый поток путём прерывания ассоциации, экземпляр не был полностью передан и, следовательно, не должен сохраняться, если только не назначены различные UID (хотя он мог быть временно использован для целей отображения).
Было показано, что использование коллекций компонентов не значительно влияет на эффективность сжатия (подробности см. http://medical.nema.org/Dicom/minutes/WG-04/2004/2004-02-18/3D_compression_RSNA_2003_ver2.pdf).
Хотя фрагмент не может содержать закодированные данные более чем одной коллекции компонентов, закодированные данные одной коллекции компонентов могут охватывать несколько фрагментов.

A.4.5 Сжатие видео MPEG2

Международная организация по стандартизации ISO/IEC MPEG2 разработала международный стандарт [ISO/IEC 13818-2] "Информационные технологии — Универсальное кодирование подвижных изображений и сопутствующей аудиоинформации: видео — часть 2", называемый "MPEG-2".

DICOM Transfer Syntax для сжатия видео MPEG2 должен идентифицироваться одним из следующих UID:

1.2.840.10008.1.2.4.100 соответствующий варианту MPEG2 Main Profile / Main Level стандарта ISO/IEC MPEG2 Video, закодированному в один фрагмент,
1.2.840.10008.1.2.4.101 соответствующий варианту MPEG2 Main Profile / High Level стандарта ISO/IEC MPEG2 Video, закодированному в один фрагмент,
1.2.840.10008.1.2.4.100.1 соответствующий варианту MPEG2 Main Profile / Main Level стандарта ISO/IEC MPEG2 Video, закодированному в один или несколько фрагментов,
1.2.840.10008.1.2.4.101.1 соответствующий варианту MPEG2 Main Profile / High Level стандарта ISO/IEC MPEG2 Video, закодированному в один или несколько фрагментов.

A.4.6 Сжатие видео MPEG-4 AVC/H.264 High Profile / Level 4.1

Международная организация по стандартизации ISO/IEC MPEG4 разработала международный стандарт [ISO/IEC 14496-10] (MPEG-4 Part 10) для видеосжатия универсального кодирования подвижных изображений и сопутствующей аудиоинформации. Этот стандарт совместно поддерживается и имеет идентичное техническое содержание со стандартом ITU-T H.264.

DICOM Transfer Syntax для сжатия видео MPEG-4 AVC/H.264 должен идентифицироваться одним из следующих UID:

1.2.840.10008.1.2.4.102 соответствующий MPEG-4 AVC/H.264 High Profile / Level 4.1 стандарта ITU-T H.264 Video, закодированному в один фрагмент,
1.2.840.10008.1.2.4.103 соответствующий MPEG-4 AVC/H.264 BD-compatible High Profile / Level 4.1 стандарта ITU-T H.264 Video с ограничениями временного и пространственного разрешения, определёнными в Таблице 8-4, закодированному в один фрагмент,
1.2.840.10008.1.2.4.102.1 соответствующий MPEG-4 AVC/H.264 High Profile / Level 4.1 стандарта ITU-T H.264 Video, закодированному в один или несколько фрагментов,
1.2.840.10008.1.2.4.103.1 соответствующий MPEG-4 AVC/H.264 BD-compatible High Profile / Level 4.1 стандарта ITU-T H.264 Video с ограничениями временного и пространственного разрешения, определёнными в Таблице 8-4, закодированному в один или несколько фрагментов.

A.4.7 Сжатие видео MPEG-4 AVC/H.264 High Profile / Level 4.2

DICOM Transfer Syntax MPEG-4 AVC/H.264 High Profile / Level 4.2 для сжатия 2D-видео должен идентифицироваться одним из следующих UID:

1.2.840.10008.1.2.4.104 соответствующий MPEG-4 AVC/H.264 High Profile / Level 4.2 стандарта ITU-T H.264 Video с ограничением о том, что упаковка кадров для стереоскопического 3D-контента не должна использоваться, как определено в Таблице 8-8, закодированному в один фрагмент,
1.2.840.10008.1.2.4.104.1 соответствующий MPEG-4 AVC/H.264 High Profile / Level 4.2 стандарта ITU-T H.264 Video с ограничением о том, что упаковка кадров для стереоскопического 3D-контента не должна использоваться, как определено в Таблице 8-8, закодированному в один или несколько фрагментов.

DICOM Transfer Syntax MPEG-4 AVC/H.264 High Profile / Level 4.2 для сжатия 3D-видео должен идентифицироваться одним из следующих UID:

1.2.840.10008.1.2.4.105 соответствующий MPEG-4 AVC/H.264 High Profile / Level 4.2 стандарта ITU-T H.264 Video. Его следует использовать для передачи стереоскопического 3D-контента с форматами упаковки кадров, как определено в Таблице 8-8, закодированному в один фрагмент,
1.2.840.10008.1.2.4.105.1 соответствующий MPEG-4 AVC/H.264 High Profile / Level 4.2 стандарта ITU-T H.264 Video. Его следует использовать для передачи стереоскопического 3D-контента с форматами упаковки кадров, как определено в Таблице 8-8, закодированному в один или несколько фрагментов.

A.4.8 Сжатие видео MPEG-4 AVC/H.264 Stereo High Profile / Level 4.2

DICOM Transfer Syntax для сжатия видео MPEG-4 AVC/H.264 Stereo High Profile / Level 4.2 должен идентифицироваться одним из следующих UID:

1.2.840.10008.1.2.4.106 соответствующий MPEG-4 AVC/H.264 Stereo High Profile / Level 4.2 стандарта ITU-T H.264 Video, закодированному в один фрагмент,
1.2.840.10008.1.2.4.106.1 соответствующий MPEG-4 AVC/H.264 Stereo High Profile / Level 4.2 стандарта ITU-T H.264 Video, закодированному в один или несколько фрагментов.

A.4.9 Сжатие видео HEVC/H.265 Main Profile / Level 5.1

Международная организация по стандартизации ISO/IEC MPEG разработала международный стандарт [ISO/IEC 23008-2] (HEVC) для видеосжатия универсального кодирования подвижных изображений и сопутствующей аудиоинформации. Этот стандарт совместно поддерживается и имеет идентичное техническое содержание со стандартом HEVC [ISO/IEC 23008-2].

DICOM Transfer Syntax для сжатия видео HEVC/H.265 Main Profile / Level 5.1 должен идентифицироваться UID:

1.2.840.10008.1.2.4.107 соответствующий HEVC/H.265 Main Profile / Level 5.1 стандарта HEVC Video [ISO/IEC 23008-2].

A.4.10 Сжатие видео HEVC/H.265 Main 10 Profile / Level 5.1

DICOM Transfer Syntax для сжатия видео HEVC/H.265 Main 10 Profile / Level 5.1 должен идентифицироваться UID:

1.2.840.10008.1.2.4.108 соответствующий HEVC/H.265 Main 10 Profile / Level 5.1 стандарта HEVC Video [ISO/IEC 23008-2].

A.4.11 Инкапсулированный несжатый Explicit VR Little Endian

DICOM Transfer Syntax для инкапсулированного несжатого Explicit VR Little Endian кодирует поток одного или нескольких кадров несжатых пиксельных данных (Pixel Data) в виде инкапсулированных фрагментов и должен идентифицироваться UID "1.2.840.10008.1.2.1.98".

Если объект допускает многокадровые изображения в Pixel Data (7FE0,0010), то каждый кадр должен кодироваться отдельно.

Каждый кадр должен кодироваться в одном и только одном фрагменте (см. Раздел 8.2).

Внутри значения элемента (Item Value) каждого фрагмента (кадра) Pixel Data должен кодироваться там же образом, как если бы он кодировался в собственном формате (Native format), включая порядок байтов и выравнивание до чётной длины элемента (Item Length). Должна использоваться VR OB, как это требуется для всех Transfer Syntaxes инкапсулированного формата (Encapsulated Format).

A.4.12 Сжатие изображений JPEG XL

Международная организация по стандартизации ISO/IEC разработала международный стандарт [ISO/IEC 18181-1] (JPEG XL) для кодирования двухуровневых, полутоновых получерно-белых, полутоновых цветных или мультиканальных цифровых изображений (дополнительные сведения см. в Приложении F).

DICOM Transfer Syntax для сжатия изображений JPEG XL должен идентифицироваться значением UID, соответствующим его процессу JPEG XL-кодирования.

Для JPEG XL определены три Transfer Syntaxes:

Transfer Syntax с UID "1.2.840.10008.1.2.4.110", определяющий использование режима без потерь JPEG XL.
Transfer Syntax с UID "1.2.840.10008.1.2.4.111", определяющий использование обратимого JPEG-транскодирования.
Transfer Syntax с UID "1.2.840.10008.1.2.4.112", определяющий использование любого метода сжатия в JPEG XL, включая режим с потерями, без потерь или режим JPEG-рекомпрессии JPEG XL.

Для JPEG XL-кодирования каждый кадр должен кодироваться отдельно как один фрагмент.

Изображение JPEG Baseline, перекодированное без потерь в JPEG XL, не является производным изображением, если только исходное JPEG-изображение не было производным. Разрешается, но не требуется добавлять Derivation Code Sequence (0008,9215) для фиксации алгоритма перекодирования.

A.4.13 Сжатие кадров изображений Deflate

DICOM Transfer Syntax для сжатия кадров изображений Deflate кодирует поток одного или нескольких кадров сжатых пиксельных данных в виде инкапсулированных фрагментов. Этот Transfer Syntax идентифицируется UID "1.2.840.10008.1.2.8.1".

Если объект допускает многокадровые изображения в поле пиксельных данных, то каждый кадр должен кодироваться отдельно.

Каждый кадр должен кодироваться в одном и только одном фрагменте (см. Раздел 8.2).

Байтовый поток пиксельных данных каждого кадра отдельно сжимается с использованием алгоритма Deflate, определённого в [RFC1951].

Если алгоритм Deflate производит нечётное число байтов, то после последнего байта дефлированного битового потока для каждого кадра должен быть добавлен один завершающий нулевой байт (NULL byte).

A.5 DICOM Deflated Explicit VR Little Endian Transfer Syntax

Этот Transfer Syntax применяется для кодирования всего DICOM Data Set.

Весь Data Set сначала кодируется согласно правилам, указанным в Разделе A.2.

Весь байтовый поток затем сжимается с использованием алгоритма Deflate, определённого в [RFC1951].

Примечание

Хотя он использует ту же схему сжатия, Deflated Explicit VR Little Endian Transfer Syntax отличается от Deflated Image Frame Compression Transfer Syntax, определённого в Разделе A.4.13, который сжимает пиксельные данные каждого кадра изображения как отдельный сжатый битовый поток и использует кодирование в формате инкапсуляции (Encapsulated Format).

Если алгоритм Deflate производит нечётное число байтов, то после последнего байта дефлированного битового потока должен быть добавлен один завершающий нулевой байт (NULL byte).

Примечание

Pixel Data в Pixel Data (7FE0,0010), Float Pixel Data (7FE0,0008) или Double Float Pixel Data (7FE0,0009) не обрабатывается каким-либо специальным образом. Pixel Data сначала кодируется как последовательные несжатые кадры (Frames) без инкапсуляции, а затем обрабатывается как часть байтового потока, подаваемого в компрессор Deflate, так же, как и Value Field любого другого Data Element.
Этот Transfer Syntax особенно полезен для сжатия объектов без Pixel Data, таких как структурированные отчёты. Он не особенно эффективен для сжатия изображений, поскольку любая выгода, полученная от сжатия непиксельных данных, нивелируется менее эффективным сжатием значительно большего по объёму Pixel Data.
Свободно доступная эталонная реализация компрессора Deflate может быть найдена в пакете zlib, который может быть загружен с http://www.zlib.net/.
Хотя закодированный поток может быть дополнен завершающим нулевым байтом (NULL byte), конец дефлированного битового потока будет указан ограничителем, который появится перед дополнением.

Для обеспечения совместимости реализаций, соответствующих стандарту DICOM и выбравших использование этого Transfer Syntax, установлена следующая политика:

Любая реализация, выбравшая поддержку Deflated Explicit VR Little Endian Transfer Syntax для любого Abstract Syntax, должна также поддерживать Explicit VR Little Endian Transfer для этого Abstract Syntax.

Примечание

Это требование поддерживать (несжатый) Explicit VR Little Endian Transfer Syntax необходимо для обеспечения полноточного обмена VR-информацией в случае, когда Association Acceptor не поддерживает Deflated Explicit VR Little Endian Transfer Syntax. Требование, указанное в Разделе 10.1 настоящего Part, о том, что Default Implicit VR Little Endian Transfer Syntax должен поддерживаться всеми реализациями, за исключением тех, которые имеют доступ только к сжимаемым с потерями Pixel Data, не отменяется. Иными словами, реализация должна поддерживать все три Transfer Syntax.
На носителях не существует подобных "базовых" требований, поскольку такие требования относятся к усмотрению Media Application Profile. Кроме того, достаточная информация по "управлению" объектами должна присутствовать в DICOMDIR, даже если отдельное приложение не может распаковать экземпляр, закодированный с помощью Deflated Explicit VR Little Endian Transfer Syntax.

Этот DICOM Deflated Explicit VR Little Endian Transfer Syntax должен идентифицироваться UID со значением "1.2.840.10008.1.2.1.99".

A.6 DICOM JPIP Referenced Transfer Syntax (Explicit VR)

Этот Transfer Syntax применяется для кодирования всего DICOM Data Set. Этот Transfer Syntax должен использоваться только тогда, когда Pixel Data (7FE0,0010) присутствует в Data Set верхнего уровня, и, следовательно, не должен использоваться, когда присутствуют Float Pixel Data (7FE0,0008) или Double Float Pixel Data (7FE0,0009). Это означает, что при кодировании DICOM Data Set с помощью DICOM Little Endian Transfer Syntax должны выполняться следующие требования:

Data Elements, содержащиеся в структуре Data Set, должны быть закодированы с Explicit VR (с VR Field), как указано в Разделе 7.1.2.
Кодирование общей структуры Data Set (Data Element Tags, Value Length и Value) должно выполняться в Little Endian, как указано в Разделе 7.3.
Кодирование Data Elements в Data Set должно выполняться следующим образом в соответствии с их Value Representations:
- Для всех Value Representations, определённых в настоящем Part, за исключением Value Representations OB и OW, кодирование должно выполняться в Little Endian, как указано в Разделе 7.3.
- Для Value Representations OB и OW кодирование должно соответствовать следующей спецификации в зависимости от Data Element Tag:
  - Pixel Data (7FE0,0010) не должен присутствовать; вместо этого Pixel Data должен быть указан по ссылке через Data Element (0028,7FE0) Pixel Data Provider URL
  - Данные оверлея (Overlay data), если они присутствуют, должны кодироваться только в Element Overlay Data (60xx,3000), который должен иметь Value Representation OB или OW и должен быть закодирован в Little Endian.
  - Data Element (0028,0004) Photometric Interpretation должен быть ограничен значениями: MONOCHROME1, MONOCHROME2, YBR_ICT и YBR_RCT.

Этот DICOM JPIP Referenced Transfer Syntax должен идентифицироваться UID со значением "1.2.840.10008.1.2.4.94".

A.7 DICOM JPIP Referenced Deflate Transfer Syntax (Explicit VR)

Этот Transfer Syntax применяется для кодирования всего DICOM Data Set.

Весь Data Set сначала кодируется согласно правилам, указанным в Разделе A.6.

Весь байтовый поток затем сжимается с использованием алгоритма "Deflate", определённого в Internet RFC 1951.

Этот DICOM JPIP Referenced Deflate Transfer Syntax должен идентифицироваться UID со значением "1.2.840.10008.1.2.4.95".

A.8 SMPTE ST 2110-20 Transfer Syntax несжатого прогрессивного активного видео

Этот Transfer Syntax используется в DICOM-RTV Metadata Flow для описания сопровождающего [SMPTE ST 2110-20] Video Flow.

DICOM-атрибуты

Samples per Pixel (0028,0002)
Photometric Interpretation (0028,0004)
Bits Allocated (0028,0100)
Bits Stored (0028,0101)
High Bit (0028,0102)

по-прежнему применимы с некоторыми допущениями, указанными ниже.

Поскольку значения DICOM Photometric Interpretation (0028,0004) YBR_FULL, YBR_FULL_422, YBR_PARTIAL_420 основаны на CCIR 601 (также известном как BT.601), DICOM-RTV поддерживает только следующее:

[SMPTE ST 2110-20] Система дискретизации YCbCr-4:4:4
[SMPTE ST 2110-20] Система дискретизации RGB
[SMPTE ST 2110-20] Система дискретизации YCbCr-4:2:2
[SMPTE ST 2110-20] Система дискретизации YCbCr-4:2:0

Таблица A.8-1 описывает различное цветовое разрешение.

Таблица A.8-1. DICOM-атрибуты для различного цветового разрешения

Разрядность	Samples per Pixel (0028,0002)	Bits Allocated (0028,0100)	Bits Stored (0028,0101)	High Bit (0028,0102)
8	3	8	8	7
10	3	16	10	9
12	3	16	12	11
16	3	16	16	15

Способ кодирования пикселей должен соответствовать SMPTE ST2110-20.

Примечание

Это кодирование отличается от кодирования Pixel Data (7FE0,0010). Пример для YBR_FULL_422 10 бит:

- SMPTE ST 2110-20 Video Flow YCbCr 4:2:2 10 bits

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   C'B00 (10 bits) |   Y'00 (10 bits)  |   C'R00 (10 bits) |   Y'01 (10 bits)  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

- DICOM Pixel Data (7FE0,0010) YBR_FULL_422 10 bits

 0                   1                   2                   3                   4                   
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Y'00 (10 bits)  |0|0|0|0|0|0|    Y'01 (10 bits) |0|0|0|0|0|0|   C'B00 (10 bits) |0|0|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    5                   6
8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   C'R00 (10 bits) |0|0|0|0|0|0|
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

DICOM Transfer Syntax для SMPTE ST 2110-20 несжатого прогрессивного активного видео должен идентифицироваться UID:

1.2.840.10008.1.2.7.1, соответствующий [SMPTE ST 2110-20] для прогрессивного видео.

A.9 SMPTE ST 2110-20 Transfer Syntax несжатого чересстрочного активного видео

Этот Transfer Syntax используется в DICOM-RTV Metadata Flow для описания сопровождающего [SMPTE ST 2110-20] Video Flow.

Параметры аналогичны описанным для [SMPTE ST 2110-20] несжатого прогрессивного активного видео ( Раздел A.8), но кадры являются чересстрочными: один кадр содержит только нечётные строки, а следующий — только чётные.

DICOM Transfer Syntax для SMPTE ST 2110-20 несжатого чересстрочного активного видео должен идентифицироваться UID:

1.2.840.10008.1.2.7.2, соответствующий [SMPTE ST 2110-20] для чересстрочного видео.

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

Этот Transfer Syntax используется в DICOM-RTV Metadata Flow для описания сопровождающего Audio Flow SMPTE ST21110-30.

DICOM-атрибуты

Number of Waveform Channels (003A,0005) ограничен 15
Number of Waveform Samples (003A,0010) ограничен 96 (1 мс при 96 кГц)
Sampling Frequency (003A,001A) должен быть 44100, 48000 или 96000
Waveform Bits Stored (003A,021A) должен быть 16 или 24
Waveform Bits Allocated (5400,1004) должен быть 16 или 24
Waveform Sample Interpretation (5400,1006) должен быть US, SS или OB

Таблица A.10-1. Частота дискретизации ST 2110-30 и DICOM

Частота дискретизации ST 2110-30	Sampling frequency(0003,001A)
44.1 kHz	44100
48 kHz*	48000
96 kHz	96000

Примечание

* 48 кГц рекомендуется SMPTE

Таблица A.10-2. Интерпретация отсчётов сигнала

Разрядность	Waveform Bits Stored (003A,021A)	Waveform Bits Allocated (5400,1006)	Waveform Sample Interpretation (5400,1006)	Значение Wave Sample Interpretation
16	16	16	SS	знаковое 16-битное линейное
16	16	16	US	беззнаковое 16-битное линейное
24	24	24	OB	24-битное линейное

Таблица A.10-3. Пример Number of Waveform Samples для 48 кГц для базового аудио (моно или стерео)

Разрядность	Waveform Bits Stored (003A,021A)	Numbers of Waveform Channels (003A,0005)	Number of Waveform Sample (003A,0010)	Результирующая длина пакета (1 мс)
16	16	1	48	96
24	24	1	48	144
16	16	2	48	192
24	24	2	48	288

[SMPTE ST 2110-30] ограничивает аудио Flow:

Частота дискретизации составляет 44,1 кГц, 48 кГц или 96 кГц, причём 48 кГц является рекомендуемым значением
Схема кодирования — L16 (16-битное линейное) или L24 (24-битное линейное)
Время пакета должно составлять 1 мс (но может быть уменьшено до 125 мкс)
Number of Waveform Channels ограничен 15

DICOM Transfer Syntax для SMPTE ST 2110-30 PCM Digital Audio должен идентифицироваться UID:

1.2.840.10008.1.2.7.3, соответствующий SMPTE ST 2110-30 Professional Media over IP Networks: PCM Digital Audio.

A.11 DICOM JPIP HTJ2K Referenced Transfer Syntax (Explicit VR)

Data Elements, содержащиеся в структуре Data Set, должны быть закодированы с Explicit VR (с VR Field), как указано в Разделе 7.1.2.
Кодирование общей структуры Data Set (Data Element Tags, Value Length и Value) должно выполняться в Little Endian, как указано в Разделе 7.3.
Кодирование Data Elements в Data Set должно выполняться следующим образом в соответствии с их Value Representations:
- Для всех Value Representations, определённых в настоящем Part, за исключением Value Representations OB и OW, кодирование должно выполняться в Little Endian, как указано в Разделе 7.3.
- Для Value Representations OB и OW кодирование должно соответствовать следующей спецификации в зависимости от Data Element Tag:
  - Pixel Data (7FE0,0010) не должен присутствовать; вместо этого Pixel Data должен быть указан по ссылке через Data Element (0028,7FE0) Pixel Data Provider URL
  - Данные оверлея (Overlay data), если они присутствуют, должны кодироваться только в Element Overlay Data (60xx,3000), который должен иметь Value Representation OB или OW и должен быть закодирован в Little Endian.
  - Data Element (0028,0004) Photometric Interpretation должен быть ограничен значениями: MONOCHROME1, MONOCHROME2, YBR_ICT и YBR_RCT.

Этот DICOM JPIP HTJ2K Referenced Transfer Syntax должен идентифицироваться UID со значением "1.2.840.10008.1.2.4.204".

A.12 DICOM JPIP HTJ2K Referenced Deflate Transfer Syntax (Explicit VR)

Этот Transfer Syntax применяется для кодирования всего DICOM Data Set.

Весь Data Set сначала кодируется согласно правилам, указанным в Разделе A.11.

Весь байтовый поток затем сжимается с использованием алгоритма "Deflate", определённого в Internet RFC 1951.

Этот DICOM JPIP HTJ2K Referenced Deflate Transfer Syntax должен идентифицироваться UID со значением "1.2.840.10008.1.2.4.205".

B Создание частно определённого уникального идентификатора (Информативное)

Частно определённые уникальные идентификаторы (UID) используются в DICOM для однозначной идентификации таких элементов, как специализированные или частные SOP Classes, Image SOP Instances, Study SOP Instances и т.д.

B.1 Организационно производный UID

UID может быть сформирован с использованием зарегистрированного корня (см. Приложение C) и суффикса, специфичного для организации. Способ определения суффикса такого организационно производного UID не ограничивается стандартом DICOM. От DICOM требуется только гарантия его уникальности со стороны определяющей организации.

Следующий пример представляет конкретный выбор, сделанный определённой организацией при определении своего суффикса для гарантии уникальности SOP Instance UID.

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

В этом примере корень:

1 Идентифицирует ISO
2 Идентифицирует ANSI Member Body
840 Код страны конкретного Member Body (США для ANSI)
xxxxx Идентифицирует конкретную организацию. (назначается ANSI)

В этом примере первые два компонента суффикса относятся к идентификации устройства:

3 Определённый производителем тип устройства
152 Определённый производителем серийный номер

Оставшиеся четыре компонента суффикса относятся к идентификации изображения:

235 Номер исследования (Study)
2 Номер серии (Series)
12 Номер изображения
187636473 Закодированная отметка даты и времени получения изображения

В этом примере организация выбрала эти компоненты для гарантии уникальности. Другие организации могут выбрать совершенно другой набор компонентов для однозначной идентификации своих изображений. Например, было бы вполне допустимо опустить Study Number, Series Number и Image Number, если бы отметка времени имела достаточную точность, чтобы гарантировать, что никакие два изображения не могут иметь одинаковую отметку даты и времени.

Из-за гибкости, допускаемой стандартом DICOM при создании организационно производных UID, реализации не должны зависеть от какой-либо предполагаемой структуры UID и не должны пытаться анализировать UID для извлечения семантики некоторых из их компонентов.

B.2 Производный от UUID UID

[ISO/IEC 9834-8] / [ITU-T X.667] определяет метод, с помощью которого UID может быть построен из корня "2.25.", за которым следует десятичное представление универсального уникального идентификатора (UUID). Это десятичное представление рассматривает 128-битный UUID как целое число и, таким образом, может содержать до 39 цифр (ведущие нули должны быть подавлены).

UID, производный от UUID, может подходить для динамически создаваемых UID, таких как SOP Instance UID, но обычно не подходит для UID, определяемых на этапе проектирования программного обеспечения приложения, таких как UID частных SOP Class или Transfer Syntax, или Implementation Class UID.

C Процесс регистрации уникальных идентификаторов DICOM (Информативное)

Этот процесс регистрации применяется к ряду уникальных идентификаторов, которые имеют одинаковые свойства, структуру и процесс регистрации. Он применяется к следующим идентификаторам:

Значения, присвоенные Элементам Данных DICOM с Представлением Значений VR = UI (см. Таблицу 6.2-1). Такие Элементы Данных определены в PS3.3, PS3.4, PS3.6 и PS3.7.
Имена Абстрактных Синтаксисов DICOM. Имена Абстрактных Синтаксисов определены в PS3.4.
Имена Transfer Syntax DICOM. Имена Transfer Syntax определены в Приложении A.
Имена Контекста Приложения DICOM. Имена Контекста Приложения определены в PS3.7

Структура UID основана на числовой форме Идентификатора Объекта OSI, как определено в [ISO/IEC 8824]. Значения должны быть зарегистрированы, как определено в [ISO/IEC 9834-1], для обеспечения глобальной уникальности.

Стандарт DICOM присваивает значения ряду таких уникальных идентификаторов. Организация, ответственная за их регистрацию — NEMA, которая гарантирует уникальность.

Для частных зарегистрированных идентификаторов NEMA не выступает в качестве регистрационного органа. Соответствующие организации должны получить надлежащую регистрацию, как определено для Идентификаторов Объектов OSI в [ISO/IEC 9834-1], для обеспечения глобальной уникальности. Национальные организации по стандартизации, представляющие ряд стран (например, Великобритания, Франция, Япония, США и т. д.) от имени Международной организации по стандартизации, действуют в качестве регистрационного органа по поручению ISO, как определено в [ISO/IEC 9834-1].

Примечание

Например, в США ANSI за плату присваивает Идентификаторы Организации любой запрашивающей организации. Такой идентификатор может использоваться идентифицированной организацией в качестве корня, к которому она может добавить суффикс, состоящий из одного или нескольких компонентов. Идентифицированная организация принимает на себя ответственность за надлежащую регистрацию этих суффиксов для обеспечения уникальности.
Ниже приведены два типичных примера получения <org root> UID. Эти примеры не предназначены для иллюстрации всех возможных методов получения <org root> UID, см. [ISO/IEC 8824] и [ISO/IEC 9834-1] для полных спецификаций. Идентификаторы организаций могут быть получены от различных национальных органов ISO (например, IBN в Бельгии, ANSI в Соединённых Штатах, AFNOR во Франции, BSI в Великобритании, DIN в Германии, COSIRA в Канаде).

Первый пример показывает случай <org root>, выданный национальным органом ISO (в данном примере — ANSI в США). <org root> состоит из идентификатора ISO, идентификатора ветви национального органа, кода страны и идентификатора организации. Следует отметить, что не существует требования, чтобы реализация, использующая <org root>, выданный ANSI, была произведена или расположена в США. <org root> состоит из следующих компонентов: 1.2.840.xxxxx
- 1 идентифицирует ISO
- 2 идентифицирует ветвь национального органа ISO
- 840 идентифицирует код страны конкретного национального органа ISO (США для ANSI)
- xxxxx идентифицирует конкретную организацию, зарегистрированную национальным органом ISO — ANSI.
Второй пример показывает случай <org root>, выданный ISO (делегировано BSI) международной организации. Он состоит из идентификатора ISO, идентификатора ветви международных организаций и Международного Кодового Обозначения. Значение <org root> присваивается международным регистрационным органом и может использоваться для множества различных UID, определяемых одной и той же международной организацией. <org root> состоит из следующих компонентов: 1.3.yyyy
- 1 идентифицирует ISO
- 3 идентифицирует ветвь международных организаций
- yyyy идентифицирует конкретную организацию, зарегистрированную регистрационным органом Международного Кодового Обозначения (см. ISO 6523).
Примеры компонентов <suffix> для уникальной идентификации изображения могут включать:
- продукт
- системный идентификатор
- номера исследования, серии и изображения
- дата и время исследования, серии и изображения.

D Примеры различных схем кодирования пиксельных данных и оверлеев (Информативное)

D.1 Подробный пример кодирования пиксельных данных

Как указано в PS3.3, Пиксельные Данные Изображения хранятся в Значении Элемента Pixel Data (7FE0,0010). Порядок, в котором пиксельные данные для плоскости изображения кодируются — слева направо и сверху вниз, по одной строке за раз (см. Рисунок D-1).

Рисунок D-1. Плоскость пикселей изображения

Отдельный пиксель может состоять из одного или нескольких Значений Выборки Пикселя (например, цветные или многоплоскостные изображения). Каждое Значение Выборки Пикселя может быть выражено либо как двоичное целое число в дополнительном коде (2's complement), либо как двоичное беззнаковое целое число, как указано Элементом Данных Pixel Representation (0028, 0103). Количество битов в каждом Значении Выборки Пикселя указывается атрибутом Bits Stored (0028,0101). Для целочисленных выборок пикселя в дополнительном коде знаковый бит является старшим значащим битом Значения Выборки Пикселя.

Пиксельная Ячейка — это контейнер для Значения Выборки Пикселя и, по выбору, дополнительных битов. Эти дополнительные биты используются для размещения пикселей на определённых границах (байт, слово и т. д.). Пиксельная Ячейка существует для каждого отдельного Значения Выборки Пикселя в пиксельных данных. Размер Пиксельных Ячеек определяется атрибутом Bits Allocated (0028,0100) и больше или равен Bits Stored (0028,0101). Размещение Значений Выборки Пикселя внутри Пиксельных Ячеек определяется атрибутом High Bit (0028,0102).

Любые ограничения на характеристики Пиксельной Ячейки и содержащегося в ней Значения Выборки Пикселя зависят от конкретного Определения Информационного Объекта (например, Объекта Изображения), содержащего Элемент Pixel Data (см. PS3.3).

Элемент Pixel Data, как определено DICOM Default Little Endian Transfer Syntax в Разделе 10.1, имеет Представление Значения OW (Other Word). Пиксельные данные в DICOM, как и в ACR-NEMA 2.0, упакованы, за исключением того, что Bits Allocated всегда равно 1 или кратно 8 (см. Рисунок D-2). Один из способов визуализировать эту упакованную кодировку — представить кодирование Пиксельных Ячеек как конкатенированный поток битов от младшего значащего бита первой Пиксельной Ячейки до старшего значащего бита последней Пиксельной Ячейки. Внутри этого потока старший значащий бит любой Пиксельной Ячейки следует за младшим значащим битом следующей Пиксельной Ячейки. Затем пиксельные данные могут быть разбиты на поток физических 16-битных слов, каждое из которых подчиняется ограничениям порядка байтов Transfer Syntax.

Все остальные (не установленные по умолчанию) Transfer Syntax DICOM используют кодирование Explicit VR. Для этих Transfer Syntax все пиксельные данные, где Bits Allocated меньше или равно 8, могут быть закодированы с явным VR типа OB (см. Приложение A). Как и в случае OW, Пиксельные Ячейки упакованы вместе, но в данном случае пиксельные данные разбиваются на поток физических 8-битных слов.

Примечание

Для пиксельных данных, закодированных с явным VR типа OB, кодирование пиксельных данных не зависит от порядка байтов.

Рисунок D-2. Кодирование (упаковка) произвольных пиксельных данных с VR = OW

За исключением однобитных изображений, Пиксельные Ячейки начинаются и заканчиваются на границах байта или слова так, что содержащееся в них Значение Выборки Пикселя также «аккуратно» помещается в ячейку.

Рисунок D-3 является примером кодирования пиксельных данных с использованием Представления Значения OW в целях пояснения. Этот пример является допустимым примером для Информационного Объекта Изображения CT.

Рисунок D-3. Пример пиксельных ячеек

Рисунок D-4 показывает пиксельные данные, составленные из этих примерных Пиксельных Ячеек, упакованные в поток 16-битных слов.

Рисунок D-4. Пример пиксельных ячеек, упакованных в 16-битные слова (VR = OW)

Порядок байтов становится предметом рассмотрения, когда мы представляем пиксельные данные физически — в памяти, файле или в сети.

В памяти байт-адресуемой машины Big Endian старший по порядку байт (биты 8 - 15) в каждом 16-битном слове имеет двоичный адрес x...x0. В то время как в байт-адресуемой машине Little Endian младший по порядку байт (биты 0 - 7) в каждом 16-битном слове имеет двоичный адрес x...x0. Рисунок D-5 изображает наши примеры потоков пиксельных данных так, как они были бы адресованы в памяти как Big Endian, так и Little Endian машины.

Рисунок D-5. Пример порядка байтов пиксельных ячеек в памяти (VR = OW)

Порядок байтов также определяется как часть согласованного Transfer Syntax, используемого при обмене сообщением DICOM. Шестнадцатибитные слова передаются по сети (по одному байту за раз) младшим значащим байтом первым в случае Transfer Syntax Little Endian (см. Рисунок D-6).

Рисунок D-6. Примеры байтовых потоков пиксельных данных (VR = OW)

В качестве последней пары примеров: для пиксельных данных с Представлением Значения OW и следующими Атрибутами: 8 битов выделено, 8 битов сохранено и старший бит 7; результирующие байтовые потоки, изображённые на Рисунке D-7, представлены так, как они были бы переданы по сети и/или сохранены на носителе. Для пиксельных данных с теми же Атрибутами, но с явным Представлением Значения OB; результирующие байтовые потоки не зависят от порядка байтов и изображены на Рисунке D-8.

Рисунок D-7. Примеры байтовых потоков пиксельных данных для 8 битов выделено и 8 битов сохранено (VR = OW)

Рисунок D-8. Примеры байтовых потоков пиксельных данных для 8 битов выделено и 8 битов сохранено (Explicit VR = OB)

D.2 Различные дополнительные примеры ячеек пиксельных данных и оверлеев

Следующие примеры дополнительно иллюстрируют использование Элементов Данных Bits Allocated (0028,0100), Bits Stored (0028,0101) и High Bit (0028,0102) при кодировании пиксельных данных и оверлеев. Все примеры показывают образцы Пиксельных Ячеек до их кодирования в байтовые потоки (и до воздействия конкретного Transfer Syntax).

Рисунок D.2-1. Пример 1 ячеек пиксельных данных и оверлеев

Рисунок D.2-2 «Пример 2 ячеек пиксельных данных и оверлеев» был удалён. См. PS3.3 2014c.

Рисунок D.2-3. Пример 3 ячеек пиксельных данных и оверлеев

Рисунок D.2-4. Пример 4 ячеек данных оверлея

Примечание

В этом примере биты оверлея пронумерованы так же, как пронумерованы Пиксельные Ячейки в других примерах в данном Приложении. То есть Бит Оверлея 1 является первым битом Плоскости Оверлея, кодируемым слева направо и сверху вниз, по одной строке за раз.

Рисунок D.2-5. Пример 5 ячеек однобитных пиксельных данных (VR=OW)

D.3 Примеры пиксельных данных типа Float и Double Float

Пиксельные данные Float Pixel Data с Представлением Значения OF всегда имеют 32 выделённых бита; результирующие байтовые потоки, изображённые на Рисунке D.3-1, представлены так, как они были бы переданы по сети и/или сохранены на носителе.

Рисунок D.3-1. Примеры байтовых потоков пиксельных данных типа Float для VR = OF

Пиксельные данные Double Float Pixel Data с Представлением Значения OD всегда имеют 64 выделённых бита; результирующие байтовые потоки, изображённые на Рисунке D.3-2, представлены так, как они были бы переданы по сети и/или сохранены на носителе.

Рисунок D.3-2. Примеры байтовых потоков пиксельных данных типа Float для VR = OD

E Репертуар символов DICOM по умолчанию (Нормативное)

Репертуар по умолчанию для символьных строк в DICOM — это набор Basic G0 Международной ссылочной версии стандарта [ISO 646] (ISO IR-6). Кроме того, поддерживаются управляющие символы LF, FF, CR, TAB и ESC. Эти управляющие символы являются подмножеством набора C0, определённого в [ISO 646] и ISO 6429:1990.

Байтовое кодирование репертуара символов по умолчанию представлено в Таблице E-1. Эта таблица может использоваться для получения как байтовых значений ISO столбец/строка, так и шестнадцатеричных значений для кодированных представлений (см. Раздел 6.1.1).

Таблица E-1. Кодирование репертуара символов DICOM по умолчанию

					b₈	0	0	0	0	0	0	0	0
					b₇	0	0	0	0	1	1	1	1
					b₆	0	0	1	1	0	0	1	1
					b₅	0	1	0	1	0	1	0	1
b₄	b₃	b₂	b₁			00	01	02	03	04	05	06	07
0	0	0	0	00				SP	0	@	P	`	p
0	0	0	1	01				!	1	A	Q	a	q
0	0	1	0	02				"	2	B	R	b	r
0	0	1	1	03				#	3	C	S	c	s
0	1	0	0	04				$	4	D	T	d	t
0	1	0	1	05				%	5	E	U	e	u
0	1	1	0	06				&	6	F	V	f	v
0	1	1	1	07				'	7	G	W	g	w
1	0	0	0	08				(	8	H	X	h	x
1	0	0	1	09		TAB		)	9	I	Y	i	y
1	0	1	0	10		LF		*	:	J	Z	j	z
1	0	1	1	11			ESC	+	;	K	[	k	{
1	1	0	0	12		FF		,	<	L	\	l	\|
1	1	0	1	13		CR		-	=	M	]	m	}
1	1	1	0	14				.	>	N	^	n	~
1	1	1	1	15				/	?	O	_	o

F Инкапсулированные изображения как часть DICOM-сообщения (Информативное)

Следующие замечания в общем случае применимы к передаче закодированного изображения в структуре сообщения согласно стандарту DICOM:

a) В процессе включения закодированного изображения в DICOM-сообщение кодирование не изменяется. Закодированный поток данных лишь сегментируется и инкапсулируется согласно протоколам стандарта DICOM. После распаковки DICOM-сообщения закодированный поток данных может быть полностью восстановлен на принимающем узле.

b) Определение объекта стандарта DICOM всегда определяет формат и другие параметры, которые может предлагать конкретная реализация кодирования. Закодированное изображение должно быть согласовано с определением объекта, частью которого оно является. Например:

1) Если объект определён как содержащий 10-битные Pixel Data, предполагается, что процесс кодирования принимает как минимум 10-битные данные. Следовательно, нет необходимости определять отдельные Transfer Syntax, например, для 8-битных или 12-битных реализаций. Предполагается, что любая 12-битная реализация работает в 8-битном режиме, если объект определён как содержащий 8-битные данные.

2) Если изображение объекта чередуется (interleaved), процесс кодирования должен воспроизводить это чередование.

c) Спецификации в заголовке файла кодирования должны быть согласованы с заголовком DICOM-сообщения, например, в отношении количества строк и столбцов.

d) Спецификация порядка байтов закодированного файла не изменяется в процессе его инкапсуляции в DICOM-сообщение.

F.1 Инкапсулированные изображения, закодированные в JPEG

Международная организация по стандартизации (ISO/IEC JTC1/SC29/WG1) подготовила Международный стандарт [ISO/IEC 10918-1] (JPEG Part 1) и проект Международного стандарта [ISO/IEC 10918-2] (JPEG Part 2) для цифрового сжатия и кодирования непрерывных полутоновых изображений. Этот стандарт в совокупности известен как Стандарт JPEG.

Часть 1 стандарта JPEG устанавливает требования и рекомендации по реализации для кодированного представления сжатых данных изображений, подлежащих обмену между приложениями. Процессы и представления предназначены для общего использования с целью поддержки широкого спектра приложений для цветных и полутоновых неподвижных изображений в целях передачи и хранения в компьютерных системах. Часть 2 стандарта JPEG определяет тесты для определения того, соответствуют ли реализации требованиям различных процессов кодирования и декодирования, заданных в Части 1 стандарта JPEG.

Стандарт JPEG определяет процессы кодирования с потерями и без потерь. Кодирование с потерями основано на дискретном косинусном преобразовании (DCT), допуская сжатие данных с регулируемым коэффициентом сжатия. Кодирование без потерь использует дифференциальную импульсно-кодовую модуляцию (DPCM).

Стандарт JPEG допускает различные процессы кодирования для кодера и декодера. Эти процессы различаются схемами кодирования квантованных данных и точностью выборки. Процессы кодирования пронумерованы последовательно, как определено в проекте Международного стандарта [ISO/IEC 10918-2] (JPEG Part 2), и сведены в Таблицу F.1-1. Простейший процесс кодирования на основе DCT называется Baseline Sequential с кодированием Хаффмана для 8-битных выборок.

Таблица F.1-1. Режимы кодирования изображений JPEG

№	Описание	С потерями LY Без потерь LL	Не-иерархический NH Иерархический H	Последовательный S Прогрессивный P	Преобразование	Кодирование	Принимаемые биты
1 2 4	Baseline Extended Extended	LY LY LY	NH NH NH	S S S	DCT DCT DCT	Huffman Huffman Huffman	8 8 12
14	Lossless	LL	NH	S	DPCM	Huffman	2-16

№

Описание

С потерями

Без потерь

Не-иерархический

Иерархический

Последовательный

Прогрессивный

Преобразование

Кодирование

Принимаемые биты

Baseline

Extended

DCT

Huffman

Lossless

DPCM

Huffman

2-16

Различные процессы кодирования, заданные в стандарте JPEG, тесно связаны между собой. Расширяя возможности реализации, всё больше «низкоуровневых» процессов может также выполняться этой реализацией. Это показано в Таблице F.1-2 для кодирования Хаффмана.

Включение JPEG-кодированного изображения в DICOM-сообщение обеспечивается использованием специфических Transfer Syntax, которые определены в Приложении A. Независимо от процессов JPEG-кодирования применяется один и тот же синтаксис. Единственное различие для разных процессов в синтаксисе (помимо различных сегментов маркеров SOF в потоке битов JPEG) заключается в UID. Таблица F.1-5 содержит UID в Transfer Syntax для различных процессов JPEG-кодирования в качестве справки.

Таблица F.1-2. Связь между процессами JPEG-кодирования Хаффмана с потерями

Процесс	1	2	4
1	*	*	*
2		*	*
4			*

* Процесс кодирования столбца может выполнять процесс кодирования строки

Таблица F.1-5. Идентификация процессов JPEG-кодирования в DICOM

UID DICOM Transfer Syntax	JPEG процесс	Описание JPEG	способен декодировать
1.2.840.10008.1.2.4.50	1	базовый (baseline)	1
1.2.840.10008.1.2.4.51	2,4	расширенный (extended)	1,2,4 (см. Примечание)
1.2.840.10008.1.2.4.57	14	lossless (без потерь) NH	14
1.2.840.10008.1.2.4.70	14 Selection Value 1	lossless (без потерь) NH, предсказание первого порядка

Примечание

Хотя процессы кодирования (2, 4), описанные в [ISO/IEC 10918-1], способны декодировать другой указанный процесс (1), поток битов использует различные сегменты маркеров SOF. Т.е. базовый JPEG-процесс 1, используемый с Transfer Syntax 1.2.840.10008.1.2.4.50, использует маркер SOF0, тогда как расширенный процесс 2, используемый с Transfer Syntax 1.2.840.10008.1.2.4.51, использует маркер SOF1. Соответственно, хотя оба потока битов кодируют 8-битные изображения с использованием DCT и кодирования Хаффмана, потоки битов не идентичны.

[ISO/IEC 10918-2] описывает тесты на соответствие для декодеров и требует, чтобы реализации конкретных расширенных процессов (таких как 2 и 4) могли декодировать потоки битов связанных базовых процессов (таких как 1) ([ISO/IEC 10918-2] Раздел 7.4 Тесты соответствия для процессов декодирования в последовательном режиме на основе DCT). Однако обратное неверно для кодеров, и наличие сегментов маркеров SOF, не определённых конкретным процессом, не соответствует стандарту ([ISO/IEC 10918-2] Раздел 5.1.1 Тест соответствия синтаксиса не-иерархических процессов кодирования, Таблицы 1 и 2).

F.2 Инкапсулированные изображения, закодированные в JPEG-LS

Международная организация по стандартизации (ISO/IEC JTC1/SC29/WG1) подготовила Международный стандарт [ISO/IEC 14495-1] (JPEG-LS Part 1) для цифрового сжатия и кодирования непрерывных полутоновых изображений. Этот стандарт известен как Стандарт JPEG-LS.

Часть 1 стандарта JPEG-LS устанавливает требования и рекомендации по реализации для кодированного представления сжатых данных изображений, подлежащих обмену между приложениями. Процессы и представления предназначены для общего использования с целью поддержки широкого спектра приложений для цветных и полутоновых неподвижных изображений в целях передачи и хранения в компьютерных системах.

Стандарт JPEG-LS определяет единственный процесс кодирования с потерями (почти без потерь), который может обеспечивать сжатие без потерь путём ограничения абсолютного значения ошибки до нуля при кодировании. Кодирование без потерь и с потерями (почти без потерь) основано на схеме предсказания со статистическим моделированием, в которой вычисляются разности между пикселами и их окружением, а их контекст моделируется перед кодированием, с механизмом обхода по длине серии (run-length). Эта схема последовательно обеспечивает лучшее сжатие в режиме без потерь, чем процессы без потерь JPEG, определённые в [ISO/IEC 10918-1], с меньшей сложностью.

Хотя используется процесс кодирования, отличный от определённых в [ISO/IEC 10918-1], синтаксис закодированного потока битов тесно связан с ним.

Единый процесс JPEG-LS используется для разрядности до 16 бит.

Включение JPEG-LS-кодированного изображения в DICOM-сообщение обеспечивается использованием специфических Transfer Syntax, которые определены в Приложении A.

F.3 Инкапсулированные изображения, закодированные в JPEG 2000

Международная организация по стандартизации (ISO/IEC JTC1/SC29/WG1) подготовила Международный стандарт [ISO/IEC 15444-1] (JPEG 2000) для цифрового сжатия и кодирования непрерывных полутоновых изображений. Этот стандарт известен как Стандарт JPEG 2000.

Стандарт JPEG 2000 устанавливает требования и рекомендации по реализации для кодированного представления сжатых данных изображений, подлежащих обмену между приложениями. Процессы и представления предназначены для общего использования с целью поддержки широкого спектра приложений для цветных и полутоновых неподвижных изображений в целях передачи и хранения в компьютерных системах.

Единый процесс JPEG 2000 используется для разрядности до 16 бит.

Включение JPEG 2000-кодированного изображения в DICOM-сообщение обеспечивается использованием специфических Transfer Syntax, которые определены в Приложении A.

F.4 Инкапсулированные изображения, закодированные в HTJ2K

Международная организация по стандартизации (ISO/IEC JTC1/SC29/WG1) подготовила Международный стандарт [ISO/IEC 15444-15] (JPEG 2000 Part 15 HTJ2K) для цифрового сжатия и кодирования непрерывных полутоновых изображений. Этот стандарт известен как Стандарт JPEG 2000 Part 15 HTJ2K или просто Стандарт HTJ2K.

Стандарт JPEG 2000 Part 15 HTJ2K устанавливает требования и рекомендации по реализации для кодированного представления сжатых данных изображений, подлежащих обмену между приложениями. Процессы и представления предназначены для общего использования с целью поддержки широкого спектра приложений для цветных и полутоновых неподвижных изображений в целях передачи и хранения в компьютерных системах.

Поток HTJ2K допускает разрядность до 38 бит на канал.

Включение HTJ2K-кодированного изображения в DICOM-сообщение обеспечивается использованием специфических Transfer Syntax, которые определены в Приложении A.

F.5 Инкапсулированные изображения, закодированные в JPEG XL

Международная организация по стандартизации (ISO/IEC JTC1/SC29/WG1) подготовила Международный стандарт [ISO/IEC 18181-1] (JPEG XL) для цифрового сжатия и кодирования непрерывных полутоновых изображений. Этот стандарт известен как Стандарт JPEG XL.

Поток JPEG XL допускает разрядность до 24 бит и до 8192 компонентов. Компоненты не обязаны быть одного типа или разрядности. Цветовое пространство изображения задаётся в кодировании JPEG XL.

Включение JPEG XL-кодированного изображения в DICOM-сообщение обеспечивается использованием специфических Transfer Syntax, которые определены в Приложении A.

G Инкапсулированные RLE-сжатые изображения (Нормативное)

G.1 Краткое описание

В этом Приложении описывается, как применять RLE-сжатие изображений к изображению или отдельному кадру много кадрового изображения. Этот метод может использоваться для любого изображения независимо от значений элементов данных, описывающих изображение (т.е. Photometric Interpretation (0028,0004) и Bits Stored (0028,0101)).

RLE-сжатие изображений состоит из следующих шагов:

Изображение преобразуется в последовательность составных кодов пикселов (Composite Pixel Codes) (см. PS3.3).
Из составных кодов пикселов формируется набор сегментов байтов (Byte Segments) (см. Раздел G.2).
Каждый сегмент байтов сжимается методом RLE для получения RLE-сегмента (см. Раздел G.4).
RLE-заголовок добавляется перед конкатенированными RLE-сегментами (см. Раздел G.5).

G.2 Сегменты байтов

Сегмент байтов — это серия байтов, сформированная путём разложения составного кода пиксела (Composite Pixel Code) (см. PS3.3).

Если составной код пиксела не составляет целое число байтов, добавляются достаточные старшие нулевые биты для получения целочисленного размера в байтах. Это называется дополненным составным кодом пиксела (Padded Composite Pixel Code).

Первый сегмент формируется путём отделения старшего байта каждого дополненного составного кода пиксела и последовательного расположения этих байтов. Второй сегмент формируется путём повторения этого процесса с остатком дополненного составного кода пиксела; процесс продолжается до тех пор, пока последний сегмент пикселов не будет сформирован путём последовательного расположения младшего байта каждого дополненного составного кода пиксела.

Примечание

Если Photometric Interpretation (0028, 0004) равно RGB и Bits Allocated равно 8, то формируются три сегмента. Первый содержит все значения Red (красный), второй — все значения Green (зелёный), третий — все значения Blue (синий).
Использование отдельных сегментов означает, что Planar Configuration (0028,0006) теоретически может быть равен 1 для RLE-сжатых изображений, однако для согласованности с другими инкапсулированными (сжатыми) Transfer Syntax и ограничениями на Planar Configuration во многих IOD он может быть равен 0, если не ограничен IOD.

G.3 Алгоритм RLE

Алгоритм RLE, описанный в этом разделе, используется для сжатия сегментов байтов в RLE-сегменты. Существует однозначное соответствие между сегментами байтов и RLE-сегментами. Каждый RLE-сегмент должен содержать чётное число байтов или быть дополнен в конце нулями до чётного размера.

G.3.1 Кодер RLE

Поток одинаковых байтов (Replicate Run) кодируется как двухбайтовый код:

< -count + 1 > <значение байта>, где
- count = количество байтов в серии, и
- 2 <= count <= 128

а неповторяющийся октетный поток (Literal Run) кодируется как:

< count - 1 > <Literal октетный поток>, где
- count = количество байтов в октетном потоке, и
- 1 <= count <= 128.

Значение -128 не может использоваться как префикс значения байта.

Примечание

Обычно двухбайтовую повторяющуюся серию кодируют как Replicate Run, за исключением случая, когда она предшествует и следует за Literal Run — в этом случае лучше объединить три серии в одну Literal Run.

Трёхбайтовые повторы должны кодироваться как Replicate Run. Каждая строка изображения должна кодироваться отдельно и не должна пересекать границу строки.

G.3.2 Декодер RLE

Псевдокод декодера RLE приведён ниже:

Цикл, пока число выходных байтов не равно размеру несжатого сегмента
- Считать следующий байт источника в n
- Если n>=0 и n<=127, то
  - вывести следующие n+1 байтов буквально
- Иначе если n<=-1 и n>=-127, то
  - вывести следующий байт -n+1 раз
- Иначе если n = -128, то
  - ничего не выводить
- Конец если
Конец цикла

G.4 Организация RLE-сжатого кадра

RLE-сегменты упорядочены, как описано в Разделе G.2. Им предшествует RLE-заголовок, содержащий смещения начала каждого RLE-сегмента. RLE-заголовок описан в G.5.

Первый RLE-сегмент следует непосредственно за RLE-заголовком, а остальные RLE-сегменты следуют непосредственно друг за другом. Это проиллюстрировано на приведённой ниже схеме.

Таблица G.4-1. Организация RLE-сжатого кадра

Заголовок

RLE Segment 1

RLE Segment 2

. . .

RLE Segment n

G.5 Формат RLE-заголовка

RLE-заголовок содержит количество RLE-сегментов изображения и начальное смещение каждого из RLE-сегментов. Каждое из этих чисел представлено значением UL (unsigned long), хранящимся в формате little-endian. RLE-заголовок имеет длину 16 длинных слов. Это позволяет ему описывать сжатое изображение с количеством RLE-сегментов до 15. Все неиспользуемые смещения сегментов должны быть установлены в ноль.

Каждая из начальных позиций RLE-сегментов представляет собой байтовое смещение относительно начала RLE-заголовка. Поскольку RLE-заголовок состоит из 16 беззнаковых длинных целых, т.е. 64 байтов, смещение первого RLE-сегмента равно 64.

Следующая схема иллюстрирует порядок смещений в RLE-заголовке.

Таблица G.5-1. Порядок смещений в RLE-заголовке

количество RLE-сегментов

смещение RLE-сегмента 1 = 64

смещение RLE-сегмента 2

. . .

смещение RLE-сегмента n

G.6 Пример элементов для закодированного YCbCr RLE трёхкадрового изображения с Basic Offset Table

Таблица G.6-1 — пример кодирования RLE-сжатых кадров (описанных в Разделе G.4) с Basic Offset Table. Таблица G.6-2 — пример данных значения Item Value для одного кадра.

Таблица G.6-1. Пример элементов для закодированного YCbCr RLE трёхкадрового изображения с Basic Offset Table

Тег элемента Pixel Data	Представление значения		Длина элемента данных	Элемент данных
				Basic Offset Table со значением Item Value			Первый фрагмент (кадр 1) Pixel Data
				Тег Item	Длина Item	Значение Item	Тег Item	Длина Item	Значение Item
(7FE0,0010) с VR, равным OB	OB	0000H	FFFF FFFFH Неопределённая длина	(FFFE,E000)	0000 000CH	0000 0000H 0000 02D0H 0000 0642H	(FFFE,E000)	0000 02C8H	RLE-сжатый кадр
4 байта	2 байта	2 байта	4 байта	4 байта	4 байта	000CH байт	4 байта	4 байта	02C8H байт

Таблица G.6-1b. Пример элементов для закодированного YCbCr RLE трёхкадрового изображения с Basic Offset Table (продолжение)

Элемент данных (продолжение)
Второй фрагмент (кадр 2) Pixel Data			Третий фрагмент (кадр 3) Pixel Data			Элемент Sequence Delimitation
Тег Item	Длина Item	Значение Item	Тег Item	Длина Item	Значение Item	Тег Sequence Delimitation Item	Длина Item
(FFFE,E000)	0000 036AH	RLE-сжатый кадр	(FFFE,E000)	0000 0BC8H	RLE-сжатый кадр	(FFFE,E0DD)	0000 0000H
4 байта	2 байта	036AH байт	4 байта	4 байта	0BC8H байт	4 байта	4 байта

Таблица G.6-2. Пример значения Item закодированного YCbCr RLE-сжатого кадра

Смещение	Данные	Описание данных
0000 0000H	0000 0003H	количество RLE-сегментов	(Заголовок)
	0000 0040H	расположение RLE-сегмента 1 (компонента Y)
	0000 0140H	расположение RLE-сегмента 2 (компонента C_B)
	0000 01C0H	расположение RLE-сегмента 3 (компонента C_R)
	0000 0000H
	…..
	…..
	0000 0000H
0000 0040H	Y — данные RLE-сегмента		(DATA)
0000 0140H	C_B — данные RLE-сегмента		(DATA)
0000 01C0H	C_R — данные RLE-сегмента		(DATA)

H Наборы символов и представление значения имени персоны на японском языке (Информативное)

H.1 Наборы символов для японского языка

Цель данного раздела — объяснить наборы символов для японского языка.

H.1.1 JIS X 0201

[JIS X 0201] имеет следующие элементы кода:

ISO-IR 13 Японские символы кана (катакана, фонетические) (94 символа)
ISO-IR 14 Японские символы ромадзи (алфавитно-цифровые) (94 символа)

[JIS X 0201] определяет 7-битную таблицу кодов ромадзи (ISO-IR 14), 7-битную таблицу кодов катаканы (ISO-IR 13) и комбинацию ромадзи и катаканы в виде 8-битной таблицы кодов (ISO-IR 14 как G0, ISO-IR 13 как G1).

7-битный ромадзи (ISO-IR 14) идентичен ASCII (ISO-IR 6), за исключением того, что битовая комбинация 05/12 представляет знак йены (YEN SIGN), а битовая комбинация 07/14 представляет надчёркивание (over-line). Это распределения национальных графических символов в [ISO 646].

Escape-последовательность для ISO/IEC 2022 показана для справки в Таблице H.1-1 (определённые термины см. в PS3.3).

Таблица H.1-1. Escape-последовательность ISO/IEC 2022 для ISO-IR 13 и ISO-IR 14

	ISO-IR 14	ISO-IR 13
Набор G0	ESC 02/08 04/10	ESC 02/08 04/09
Набор G1	ESC 02/09 04/10	ESC 02/09 04/09

Примечание

Таблица H.1-1 не включает наборы G2 и G3, которые не используются в DICOM. См. Раздел 6.1.2.5.1.
Определённые термины ISO_IR 13 и ISO 2022 IR 13 для Значения атрибута Specific Character Set (0008,0005) поддерживают набор G0 для ISO-IR 14 и набор G1 для ISO-IR 13. См. PS3.3.
ISO-IR 14 не может кодировать пути в стиле DOS, в которых используется обратная косая черта (BACKSLASH) в качестве разделителя компонентов файла, поскольку битовая комбинация 05/12 представляет знак йены (YEN SIGN), а не символ обратной косой черты. Кроме того, для некоторых VR (SH, LO, PN и UC), 05/12 является разделителем между Значениями, а не частью Значения.

H.1.2 JIS X 0208

[JIS X 0208] имеет следующий элемент кода:

ISO-IR 87: Японские кандзи (идеографические), хирагана (фонетические) и катакана (фонетические) символы (94² символов, 2 байта).

H.1.3 JIS X 0212

[JIS X 0212] имеет следующий элемент кода:

ISO-IR 159: Дополнительные японские кандзи (идеографические) символы (94² символов, 2 байта)

Escape-последовательность для ISO/IEC 2022 показана для справки в Таблице H.1-2 (определённые термины см. в PS3.3)

Таблица H.1-2. Escape-последовательность ISO/IEC 2022 для ISO-IR 87 и ISO-IR 159

	ISO-IR 87	ISO-IR 159
Набор G0	ESC 02/04 04/02	ESC 02/04 02/08 04/04
Набор G1	ESC 02/04 02/09 04/02	ESC 02/04 02/09 04/04

Примечание

Escape-последовательность для функции designate набора G0-DESIGNATE 94-SET имеет первый I-байт 02/04 и второй I-байт 02/08. Существует исключение: второй I-байт 02/08 опускается, если Final Byte равен 04/00, 04/01 или 04/02. См. ISO/IEC 2022.
Таблица не включает наборы G2 и G3, которые не используются в DICOM. См. Раздел 6.1.2.5.1.
Определённый термин ISO 2022 IR 87 для Значения атрибута Specific Character Set (0008,0005) поддерживает набор G0 для ISO-IR 87, а определённый термин ISO 2022 IR 159 поддерживает набор G0 для ISO-IR 159. См. PS3.3.

H.2 Практика в Интернете

DICOM принял метод кодирования для японских наборов символов, аналогичный методу, используемому в практике Интернета.

Основные протоколы Интернета, такие как SMTP, NNTP и HTTP, используют метод кодирования японских символов, называемый "ISO-2022-JP", как описано в RFC 1468 (Japanese Character Encoding for Internet Messages). Существует также менее распространённая практика в Интернете, называемая "ISO-2022-JP-2", описанная в RFC 1554, которая поддерживает более широкий набор символов и дополнительно требует перехода к однобайтовому набору символов перед кодированием символа SPACE (в отличие от DICOM и ISO-2022-JP).

Наборы символов, поддерживаемые для японского языка в DICOM и в практике Интернета, показаны в Таблице H.2-1.

Таблица H.2-1. Наборы символов для японского языка в DICOM и в практике Интернета

DICOM	ISO-2022-JP	ISO-2022-JP-2
ASCII (ISO-IR 6) [JIS X 0201] Катакана (ISO-IR 13) [JIS X 0201] Ромадзи (ISO-IR 14) [JIS X 0208] Кандзи (ISO-IR 87) [JIS X 0212] Кандзи (ISO-IR 159)	ASCII (ISO-IR 6) [JIS X 0201] Ромадзи (ISO-IR 14) [JIS X 0208]-1978 Кандзи (ISO-IR 42) [JIS X 0208]-1983 Кандзи (ISO-IR 87)	ASCII (ISO-IR 6) [ISO/IEC 8859-1] (ISO-IR 100) [ISO/IEC 8859-7] Греческий (ISO-IR 126) [JIS X 0201] Ромадзи (ISO-IR 14) [JIS X 0208]-1978 Кандзи (ISO-IR 42) [JIS X 0208]-1983 Кандзи (ISO-IR 87) [JIS X 0212] Кандзи (ISO-IR 159) [GB 2312] (ISO-IR 58) [KS X 1001] (ISO-IR 149)

DICOM

ISO-2022-JP

ISO-2022-JP-2

ASCII (ISO-IR 6)

[JIS X 0201] Катакана (ISO-IR 13)

[JIS X 0201] Ромадзи (ISO-IR 14)

[JIS X 0208] Кандзи (ISO-IR 87)

[JIS X 0212] Кандзи (ISO-IR 159)

ASCII (ISO-IR 6)

[JIS X 0201] Ромадзи (ISO-IR 14)

[JIS X 0208]-1978 Кандзи (ISO-IR 42)

[JIS X 0208]-1983 Кандзи (ISO-IR 87)

ASCII (ISO-IR 6)

[ISO/IEC 8859-1] (ISO-IR 100)

[ISO/IEC 8859-7] Греческий (ISO-IR 126)

[JIS X 0201] Ромадзи (ISO-IR 14)

[JIS X 0208]-1978 Кандзи (ISO-IR 42)

[JIS X 0208]-1983 Кандзи (ISO-IR 87)

[JIS X 0212] Кандзи (ISO-IR 159)

[GB 2312] (ISO-IR 58)

[KS X 1001] (ISO-IR 149)

Управляющие символы, поддерживаемые в DICOM и в практике Интернета, показаны в Таблице H.2-2.

Таблица H.2-2. Управляющие символы, поддерживаемые в DICOM и в практике Интернета

DICOM	ISO-2022-JP and ISO-2022-JP-2
LF (00/10) FF (00/12) CR (00/13) ESC (01/11)	LF (00/10) CR (00/13) SO (00/14) SI (00/15) ESC (01/11)

DICOM

ISO-2022-JP and ISO-2022-JP-2

LF (00/10)

FF (00/12)

CR (00/13)

ESC (01/11)

LF (00/10)

CR (00/13)

SO (00/14)

SI (00/15)

ESC (01/11)

H.3 Пример представления значения имени персоны на японском языке

Символьные строки, представляющие имена персон, кодируются с использованием соглашения для Value Representation PN на основе групп компонентов с 5 компонентами.

Для языков, использующих идеографические символы, иногда необходимо записывать имена как в идеографических символах, так и в фонетических символах. Идеографические символы могут требоваться для официальных целей, в то время как фонетические символы могут быть необходимы для произношения и обработки данных.

Для записи имён в идеографических и фонетических символах может использоваться до 3 групп компонентов. Разделителем группы компонентов должен быть знак равенства "=" (3DH). Три группы компонентов в порядке их следования: алфавитное представление, идеографическое представление и фонетическое представление.

H.3.1 Значение 1 атрибута Specific Character Set (0008,0005) отсутствует.

Пример H.3-1. Значение 1 атрибута Specific Character Set (0008,0005) отсутствует

В этом случае ISO-IR 6 используется по умолчанию в Specific Character Set:

(0008,0005) \ISO 2022 IR 87

Символьная строка:

Yamada^Tarou=山田^太郎=やまだ^たろう
Yamada^Tarou= ESC 02/04 04/02 山田 ESC 02/08 04/02 ^ ESC 02/04 04/02 太郎 ESC 02/08 04/02 = ESC 02/04 04/02 やまだ ESC 02/08 04/02 ^ ESC 02/04 04/02 たろう ESC 02/08 04/02

Закодированное представление:

05/09 06/01 06/13 06/01 06/04 06/01 5/14 05/04 06/01 07/02 06/15 07/05 03/13 01/11 02/04 04/02 03/11 03/03 04/05 04/04 01/11 02/08 04/02 05/14 01/11 02/04 04/02 04/02 04/00 04/15 03/10 01/11 02/08 04/02 03/13 01/11 02/04 04/02 02/04 06/04 02/04 05/14 02/04 04/00 01/11 02/08 04/02 05/14 01/11 02/04 04/02 02/04 03/15 02/04 06/13 02/04 02/06 01/11 02/08 04/02

Пример того, что может быть отображено или распечатано машиной на основе ASCII, которая отображает или печатает управляющий символ ESC (01/11) с использованием \033:

Yamada^Tarou=\033$B;3ED\033(B^\033$BB@O:\033(B=\033$B$d$^$@\033(B^\033$B$?$m$&\033(B

Таблица H.3-1. Наборы символов и escape-последовательности, использованные в Примере 1

Описание набора символов	Группа компонентов	Определённый термин — Значение (0008,0005)	Регистрационный номер ISO	Стандарт расширения кода	ESC-последовательность	Элемент кода	Набор символов: цель использования
Японский	Первая: Однобайтовый	Значение 1: нет	ISO-IR 6			GL	[ISO 646]
	Вторая: Идеографический	Значение 2: ISO 2022 IR 87	ISO-IR 87	ISO 2022	ESC 02/04 04/02	GL	[JIS X 0208]: Японские кандзи, хирагана, катакана
		Значение 1: нет	ISO-IR 6	ISO 2022	ESC 02/08 04/02	GL	[ISO 646] для разделителей
	Третья: Фонетический	Значение 2: ISO 2022 IR 87	ISO-IR 87	ISO 2022	ESC 02/04 04/02	GL	[JIS X 0208]: Японские хирагана и катакана
		Значение 1: нет	ISO-IR 6	ISO 2022	ESC 02/08 04/02	GL	[ISO 646] для разделителей

H.3.2 Значение 1 атрибута Specific Character Set (0008,0005) — ISO 2022 IR 13.

Пример H.3-2. Значение 1 атрибута Specific Character Set (0008,0005) — ISO 2022 IR 13

Specific Character Set:

(0008,0005) ISO 2022 IR 13\ISO 2022 IR 87

Символьная строка:

ﾔﾏﾀﾞ^ﾀﾛｳ=山田^太郎=やまだ^たろう
ﾔﾏﾀﾞ^ﾀﾛｳ= ESC 02/04 04/02 山田 ESC 02/08 04/10 ^ ESC 02/04 04/02 太郎 ESC 02/08 04/10 = ESC 02/04 04/02 やまだ ESC 02/08 04/10 ^ ESC 02/04 04/02 たろう ESC 02/08 04/10

Закодированное представление:

13/04 12/15 12/00 13/14 05/14 12/00 13/11 11/03 03/13 01/11 02/04 04/02 03/11 03/03 04/05 04/04 01/11 02/08 04/10 05/14 01/11 02/04 04/02 04/02 04/00 04/15 03/10 01/11 02/08 04/10 03/13 01/11 02/04 04/02 02/04 06/04 02/04 05/14 02/04 04/00 01/11 02/08 04/10 05/14 01/11 02/04 04/02 02/04 03/15 02/04 06/13 02/04 02/06 01/11 02/08 04/10

\324\3l7\300\336^\300\333\263=\033$B;3ED\033(J^\033$BB@O:\033(J=\033$B$d$^$@\033(J^\033$B$?$m$&\033(J

Таблица H.3-2. Наборы символов и escape-последовательности, использованные в Примере 2

Описание набора символов	Группа компонентов	Определённый термин — Значение (0008,0005)	Регистрационный номер ISO	Стандарт расширения кода	ESC-последовательность	Элемент кода	Набор символов: цель использования
Японский	Первая: Однобайтовый	Значение 1: ISO 2022 IR 13	ISO-IR 13	ISO 2022	ESC 02/09 04/09	GR	[JIS X 0201]: Японская катакана
			ISO-IR 14	ISO 2022	ESC 02/08 04/10	GL	[JIS X 0201]: Японские ромадзи для разделителей
	Вторая: Идеографический	Значение 2: ISO 2022 IR 87	ISO-IR 87	ISO 2022	ESC 02/04 04/02	GL	[JIS X 0208]: Японские кандзи, хирагана, катакана
		Значение 1: ISO 2022 IR 13	ISO-IR 14	ISO 2022	ESC 02/08 04/10	GL	[JIS X 0201]: Японские ромадзи для разделителей
	Третья: Фонетический	Значение 2: ISO 2022 IR 87	ISO-IR 87	ISO 2022	ESC 02/04 04/02	GL	[JIS X 0208]: Японские хирагана и катакана
		Значение 1: ISO 2022 IR 13	ISO-IR 14	ISO 2022	ESC 02/08 04/10	GL	[JIS X 0201]: Японские ромадзи для разделителей

I Наборы символов и представление значения персоны на корейском языке (Информативное)

I.1 Наборы символов для корейского языка в DICOM

[KS X 1001] (зарегистрирован как ISO-IR 149) используется в DICOM в качестве корейского набора символов. Этот набор символов является наиболее широко используемым для представления корейских символов. Он может быть закодирован с помощью методов расширения кода [ISO/IEC 2022] и зарегистрирован в [ISO 2375].

Escape-последовательность показана для справки в Таблице I.1-1 (см. PS3.3)

Таблица I.1-1. Escape-последовательность ISO/IEC 2022 для ISO-IR 149

	ISO-IR 149
Набор G0	ESC 02/04 02/08 04/03
Набор G1	ESC 02/04 02/09 04/03

Примечание

ISO-IR 149 используется в DICOM только в качестве набора G1.
Корейский набор символов (ISO IR 149) вызывается в область G1. Это отличается от японских многобайтовых наборов символов (ISO 2022 IR 87 и ISO 2022 IR 159), которые используют кодовую область G0. Выбор Японией области G0 обусловлен принятием метода кодирования на основе "ISO-2022-JP". ISO-2022-JP, наиболее привычный метод кодирования в Японии, использует только кодовую область G0. В Корее большинство операционных систем используют метод кодирования, который вызывает набор символов хангыль [KS X 1001] в кодовую область G1. Таким образом, различие между кодовыми областями корейских и японских символов обусловлено соглашением, а не технической проблемой. Вызов многобайтовых наборов символов в область G1 не изменяет текущие нормативные требования DICOM.

I.2 Пример представления значения имени персоны на корейском языке

Пример I.2-1. Пример представления значения имени персоны на корейском языке

Имена персон на корейском языке могут быть записаны на хангыле (фонетические символы), ханче (идеографические символы) или латинице (алфавитные символы). Три группы компонентов следует записывать в порядке: алфавитная, идеографическая и фонетическая (см. Таблицу 6.2-1).

Specific Character Set:

(0008,0005) \ISO 2022 IR 149

Символьная строка:

Hong^Gildong=洪^吉洞=홍^길동
Hong^Gildong= ESC 02/04 02/09 04/03 洪 ^ ESC 02/04 02/09 04/03 吉洞 = ESC 02/04 02/09 04/03 홍 ^ ESC 02/04 02/09 04/03 길동

Закодированное представление:

04/08 06/15 06/14 06/07 05/14 04/07 06/09 06/12 06/04 06/15 06/14 06/07 03/13 01/11 02/04 02/09 04/03 15/11 15/03 05/14 01/11 02/04 02/09 04/03 13/01 12/14 13/04 13/07 03/13 01/11 02/04 02/09 04/03 12/08 10/11 05/14 01/11 02/04 02/09 04/03 11/01 14/06 11/05 11/15

Hong^Gildong=\033$) C\373\363^\033$)C\321\316\324\327=\033$)C\310\253^\033$)C\261\346\265\277

Примечание

Многобайтовый набор символов (ISO-IR 149) и однобайтовый набор символов [ISO 646] могут использоваться совместно без какой-либо явной escape-последовательности после начальной escape-последовательности. После того как [ISO 646] назначен в область GL, а ISO-IR 149 — в область GR, каждый набор символов имеет свою кодовую область, поэтому они могут использоваться совместно. Декодер будет проверять старший бит символа, чтобы определить, является ли он двухбайтовым символом в области GR (старший бит равен единице) или однобайтовым символом в области GL (старший бит равен нулю).
В приведённом выше примере представления имени персоны явные escape-последовательности предшествуют каждой строке хангыль и ханча. Эти escape-последовательности нужны для выполнения требований техники расширения кода, которая предписывает переключение на Default Character Repertoire перед разделителями. В предыдущем примере предполагается, что Default Character Repertoire (ISO-646) вызывается в кодовую область G0, а в область G1 после разделителей (знаки "^" и "=") никакой набор символов не вызывается. См. Раздел 6.1.2.5.3.

I.3 Пример представления длинного текстового значения на корейском языке без явных escape-последовательностей между наборами символов

Пример I.3-1. Пример представления длинного текстового значения на корейском языке без явных escape-последовательностей между наборами символов

Наборы символов хангыль (ISO IR 149) и ASCII [ISO 646] могут использоваться совместно без явных escape-последовательностей между ними. Набор символов хангыль ISO IR 149 вызывается в область G1, поэтому этот вызов не влияет на область G0, в которую был вызван набор символов ASCII. Ниже приведён пример Value Representation длинного текста (Long Text), включающий набор символов ASCII и хангыль.

Specific Character Set:

(0008,0005) \ISO 2022 IR 149

Символьная строка:

Первая строка содержит 한글 .

Вторая строка также содержит 한글 .

Третья строка

Закодированная строка:

ESC 02/04 02/09 04/03 Первая строка содержит 한글 .

ESC 02/04 02/09 04/03 Вторая строка также содержит 한글 .

Третья строка

После вызова набора символов ISO IR 149 в область G1 с помощью escape-последовательности в начале строки, можно использовать хангыль и ASCII совместно в этой строке.

Таблица I.3-1. Наборы символов и escape-последовательности, использованные в примерах

Описание набора символов	Группа компонентов	Определённый термин — Значение (0008,0005)	Регистрационный номер ISO	Стандарт расширения кода	ESC-последовательность	Элемент кода	Набор символов: цель использования
Корейский	Первая: Однобайтовый	Значение 1: нет	ISO-IR 6			GL	[ISO 646]
	Вторая: Идеографический	Значение 1: нет	ISO-IR 6			GL	[ISO 646]: Для разделителей
		Значение 2: ISO 2022 IR 149	ISO-IR 149	ISO 2022	ESC 02/04 02/09 04/03	GR	[KS X 1001]: Хангыль и ханча
	Третья: Фонетический	Значение 1: нет	ISO-IR 6			GL	[ISO 646]: Для разделителей
		Значение 2: ISO 2022 IR 149	ISO-IR 149	ISO 2022	ESC 02/04 02/09 04/03	GR	[KS X 1001]: Хангыль и ханча

J Наборы символов и представление значения имени персоны с использованием Unicode UTF-8, GB18030 и GBK (Информативное)

Набор символов Unicode UTF-8 и набор символов [GB 18030] могут использоваться для нескольких языков. Некоторые из этих языков могут также кодироваться с использованием других наборов символов, которые определены в другом месте стандарта DICOM. Поскольку кодировки Unicode UTF-8 и [GB 18030] не допускают замены набора символов [ISO/IEC 2022], они должны использоваться для всех строк в одном экземпляре SOP. Это может иметь последствия для выбора набора символов для кодирования экземпляра SOP.

Поскольку набор символов [GBK] полностью совместим по кодовым точкам с более широким набором символов [GB 18030], а конкретные примеры кодирования [GB 18030] в данном Приложении (J.3 и J.4) включают только китайские символы, попадающие в общую область кодирования между двумя стандартами, эти примеры используются для демонстрации кодирования имени персоны и текста в обоих стандартах. Примеры, специфичные для [GBK], не требуются.

J.1 Пример представления значения имени персоны на китайском языке с использованием Unicode

Пример J.1-1. Пример представления значения имени персоны на китайском языке с использованием Unicode

Имена персон на китайском языке могут быть записаны на ханьцзы (идеографические символы) и/или латинице (алфавитные символы). Латинское представление может быть получено с использованием пиньинь или другого метода романизации, либо может быть выбранным «вестернизированным» именем. Две группы компонентов должны быть записаны в порядке: сначала алфавитная, затем идеографическая; фонетическая группа компонентов обычно не используется (см. Таблица 6.2-1). В данном примере используется традиционное письмо.

Примечание

Некоторые системы медицинской информации могут кодировать «вестернизированное» имя вместе с другими псевдонимами пациента в отдельном Атрибуте, например, Other Patient Names (0010,1091).
В некоторых средах, использующих китайский язык, может применяться третий компонент имени, например, для письма йи или монгольского, с первым компонентом имени или без него. Это аналогично использованию компонентов имени в японском и корейском языках.

В приведённом ниже примере Атрибут Specific Character Set (0008,0005) будет содержать:

(0008,0005) ISO_IR 192

Текстовая строка:

Wang^XiaoDong=王^小東=

Кодированное представление символов:

0x57 0x61 0x6e 0x67 0x5e 0x58 0x69 0x61 0x6f 0x44 0x6f 0x6e 0x67 0x3d 0xe7 0x8e 0x8b 0x5e 0xe5 0xb0 0x8f 0xe6 0x9d 0xb1 0x3d

Примечание

Подчёркнутые байты соответствуют кодовым точкам Unicode для китайских символов:

王 (U+738B)
小 (U+5C0F)
東 (U+6771)

а соответствующие кодировки UTF-8:

UTF-8 (U+738b) = 0xe7 0x8e 0x8b
UTF-8 (U+5c0f U+6771) = 0xe5 0xb0 0x8f 0xe6 0x9d 0xb1

J.2 Пример представления длинного текстового значения на китайском языке с использованием Unicode

Пример J.2-1. Пример представления длинного текстового значения на китайском языке с использованием Unicode

Ниже приведён пример представления длинного текстового значения (Long Text Value Representation), включающего ASCII и набор символов [ISO/IEC 10646].

Specific Character Set:

(0008,0005) ISO_IR 192

Текстовая строка:

Первая строка включает 中文 .

Вторая строка также включает 中文 .

Третья строка.

Кодированное представление символов:

0x54 0x68 0x65 0x20 0x66 0x69 0x72 0x73 0x74 0x20 0x6c 0x69 0x6e 0x65 0x20 0x69 0x6e 0x63 0x6c 0x75 0x64 0x65 0x73 0xe4 0xb8 0xad 0xe6 0x96 0x87 0x2e 0x0d 0x0a 0x54 0x68 0x65 0x20 0x73 0x65 0x63 0x6f 0x6e 0x64 0x20 0x6c 0x69 0x6e 0x65 0x20 0x69 0x6e 0x63 0x6c 0x75 0x64 0x65 0x73 0xe4 0xb8 0xad 0xe6 0x96 0x87 0x2c 0x20 0x74 0x6f 0x6f 0x2e 0x0d 0x0a 0x54 0x68 0x65 0x20 0x74 0x68 0x69 0x72 0x64 0x20 0x6c 0x69 0x6e 0x65 0x2e 0x0d 0x0a

Примечание

Подчёркнутые байтовые коды соответствуют кодовым точкам Unicode для китайских символов:

中 (U+4E2D) 0xe4 0xb8 0xad
文 (U+6587) 0xe6 0x96 0x87

J.3 Пример представления значения имени персоны на китайском языке с использованием GB18030

Пример J.3-1. Пример представления значения имени персоны на китайском языке с использованием GB18030

Примечание

См. примечания к Разделу J.1.

В приведённом ниже примере Атрибут Specific Character Set (0008,0005) будет содержать:

(0008,0005) GB18030

Текстовая строка:

Wang^XiaoDong=王^小东=

Кодированное представление символов:

0x57 0x61 0x6e 0x67 0x5e 0x58 0x69 0x61 0x6f 0x44 0x6f 0x6e 0x67 0x3d 0xcd 0xf5 0x5e 0xd0 0xa1 0xb6 0xab 0x3d

Примечание

Кодировки [GB 18030] для используемых здесь китайских символов:

王 (CDF5 in [GB 18030])
小 (D0A1 in [GB 18030])
东 (B6AB in [GB 18030])

J.4 Пример представления длинного текстового значения на китайском языке с использованием GB18030

Пример J.4-1. Пример представления длинного текстового значения на китайском языке с использованием GB18030

Ниже приведён пример представления длинного текстового значения (Long Text Value Representation), включающего ASCII и набор символов [GB 18030].

Specific Character Set:

(0008,0005) GB18030

Текстовая строка:

Первая строка включает 中文 .

Вторая строка также включает 中文 .

Третья строка.

Кодированное представление символов:

0x54 0x68 0x65 0x20 0x66 0x69 0x72 0x73 0x74 0x20 0x6c 0x69 0x6e 0x65 0x20 0x69 0x6e 0x63 0x6c 0x75 0x64 0x65 0x73 0xd6 0xd0 0xce 0xc4 0x2e 0x0d 0x0a 0x54 0x68 0x65 0x20 0x73 0x65 0x63 0x6f 0x6e 0x64 0x20 0x6c 0x69 0x6e 0x65 0x20 0x69 0x6e 0x63 0x6c 0x75 0x64 0x65 0x73 0xd6 0xd0 0xce 0xc4 0x2c 0x20 0x74 0x6f 0x6f 0x2e 0x0d 0x0a 0x54 0x68 0x65 0x20 0x74 0x68 0x69 0x72 0x64 0x20 0x6c 0x69 0x6e 0x65 0x2e 0x0d 0x0a

Примечание

Подчёркнутые байтовые коды соответствуют кодировкам [GB 18030] для используемых китайских символов:

中 (D6D0 in [GB 18030])
文 (CEC4 in [GB 18030])

J.5 Представление значения имени персоны на других языках с использованием Unicode

Имена персон на многих языках могут быть записаны местным (не латинским) письмом, а также в транслитерации на латинское письмо (романизация). Системы медицинской информации в таких средах могут поддерживать один или оба формата имени. Местные письменности могут кодироваться с использованием Unicode в UTF-8.

Для целей обмена в DICOM существуют три типичных варианта использования групп компонентов имени с применением Unicode в UTF-8:

Имена на латинском письме могут быть закодированы в первой (алфавитной) группе компонентов, а имена на местном письме (алфавит, абугида или слоговое письмо) — в третьей (фонетической) группе компонентов (см. Таблицу 6.2-1). Вторая (идеографическая) группа компонентов пуста. Это предпочтительный вариант для межкорпоративного или международного обмена.
Если для местного письма исторически определён однобайтовый набор символов для Specific Character Set (0008,0005), т.е. кириллица, арабский, греческий, иврит, тайский и различные версии латиницы, может использоваться только первая группа компонентов имени. Кодирование может выполняться в Unicode в UTF-8, как описано в данном Приложении, в качестве эквивалента использования определённого однобайтового набора символов в первой группе компонентов имени (см. примечание 1).
Имена на местном письме могут быть закодированы в первой группе компонентов, а имена на латинском письме — в третьей группе компонентов, обе закодированы в Unicode в UTF-8.

Примечание

Предыдущая редакция DICOM требовала, чтобы первая группа компонентов имени использовала однобайтовый набор символов (см. PS3.5-2008). Unicode в UTF-8 теперь может использоваться в этой группе компонентов просто как иной вариант кодирования набора символов, но с тем же прикладным использованием данной группы компонентов.
Системы медицинской информации будут использовать определённые письменности в одной, двух или трёх группах компонентов имени персоны в соответствии с локальной политикой. Соответствующие DICOM прикладные элементы, принимающие атрибуты имени, должны принимать несколько групп компонентов имени. Прикладной элемент, который можно настроить для использования местного письма для имён в первой или третьей группе компонентов и письменности транслитерации в другой, будет поддерживать все эти типичные представления.
Транслитерация (с местного письма) может быть не латинским письмом, например, кириллицей. Применяются те же принципы, и кириллизированное имя может быть закодировано в первой группе компонентов, а местное письмо (которое фактически может быть письмом латинского происхождения) — в третьей группе компонентов.

K Наборы символов и представление значения имени персоны на китайском языке с расширениями кода (Информативное)

K.1 Наборы символов для китайского языка в DICOM

[GB 2312] (зарегистрированный как ISO-IR 58) используется как набор китайских символов в DICOM. Этот набор символов является наиболее широко используемым для представления китайских символов. Он может кодироваться с помощью методов расширения кода [ISO/IEC 2022].

Escape-последовательность показана для справки в Таблице K.1-1 (см. PS3.3)

Таблица K.1-1. ISO/IEC 2022 Escape-последовательность для ISO-IR 58

	ISO-IR 58
Набор G0 (ASCII)	ESC 02/08 04/02
Набор G1	ESC 02/04 02/09 04/01

K.2 Пример представления значения имени персоны на китайском языке

Пример K.2-1. Пример представления значения имени персоны на китайском языке

Имена персон на китайском языке могут быть записаны на пиньинь (фонетические символы), ханьцзы (идеографические символы) или английском имени (алфавитные символы). Три группы компонентов должны быть записаны в порядке: алфавитная (английское имя), идеографическая и фонетическая.

Specific Character Set:

(0008,0005) \ISO 2022 IR 58

Символьная строка:

Zhang^XiaoDong=张^小东=

Кодированная строка:

Zhang^XiaoDong= ESC 02/04 02/09 04/01 张^ESC 02/04 02/09 04/01小东 =

Кодированное представление символов (GB2312):

0x5A 0x68 0x61 0x6E 0x67 0x5E 0x58 0x69 0x61 0x6F 0x44 0x6F 0x6E 0x67 0x3D 0x1B 0x24 0x29 0x41 0xD5 0xC5 0x5E 0x1B 0x24 0x29 0x41 0xD0 0xA1 0xB6 0xAB 0x3D 0x20

Примечание

Подчёркнутые байтовые коды соответствуют двухбайтовым символам, жирные байтовые коды — escape-последовательностям.
Многобайтовый набор символов (ISO-IR 58) и однобайтовый набор символов [ISO 646] могут использоваться вперемешку без явной escape-последовательности после начальной escape-последовательности, вплоть до следующего разделителя (^ или =) или конца поля значения. После того как [ISO 646] назначен в G0, а ISO-IR 58 — в G1, каждый набор символов имеет свою кодовую область, поэтому они могут использоваться вперемешку. Декодер будет проверять старший бит символа, чтобы определить, является ли он двухбайтовым символом в области G1 (старший бит равен единице) или однобайтовым символом в области G0 (старший бит равен нулю). Не требуется явного вызова (escape) для назначения [ISO 646] в G0 в конце строки перед разделителем (^ или =) или концом поля значения. Однако требуется новый вызов ISO-IR 58 в каждом компоненте имени, в котором он используется.

K.3 Пример представления длинного текстового значения на китайском языке с GB2312 G1

Пример K.3-1. Пример представления длинного текстового значения на китайском языке с GB2312 G1

Наборы символов китайского языка (ISO 2022 IR 58) и ASCII [ISO 646] могут использоваться вперемешку без явных escape-последовательностей между ними. Набор китайских символов ISO IR 58 вызывается в область G1, а набор символов ASCII — в область G0. Ниже приведён пример представления длинного текстового значения (Long Text Value Representation), включающего ASCII и набор китайских символов. Предполагается, что каждая строка начинается с набора символов по умолчанию и требует явного вызова [GB 2312] в G1, но не требует повторного вызова набора символов ASCII по умолчанию в G0.

Specific Character Set:

(0008,0005) \ISO 2022 IR 58

Символьная строка (с CR LF после каждой строки):

1) 第一行文字。

2) 第二行文字。

3) 第三行文字。

Кодированная строка:

1) ESC 02/04 02/09 04/01 第一行文字。

2) ESC 02/04 02/09 04/01 第二行文字。

3) ESC 02/04 02/09 04/01 第三行文字。

Кодированное представление символов (GB2312):

0x31 0x2e 0x1B 0x24 0x29 0x41 0xB5 0xDA 0xD2 0xBB 0xD0 0xD0 0xCE 0xC4 0xD7 0xD6 0xA1 0xA3 0x0D 0x0A

0x32 0x2e 0x1B 0x24 0x29 0x41 0xB5 0xDA 0xB6 0xFE 0xD0 0xD0 0xCE 0xC4 0xD7 0xD6 0xA1 0xA3 0x0D 0x0A

0x33 0x2e 0x1B 0x24 0x29 0x41 0xB5 0xDA 0xC8 0xFD 0xD0 0xD0 0xCE 0xC4 0xD7 0xD6 0xA1 0xA3 0x0D 0x0A

Примечание

Подчёркнутые байтовые коды соответствуют двухбайтовым символам, жирные байтовые коды — escape-последовательностям.

Таблица K.3-1. Наборы символов и escape-последовательности, используемые в примерах имени персоны

Описание набора символов

Группа компонентов

Определённый термин — Значение (0008,0005)

Регистрационный номер ISO

Стандарт расширения кода

ESC-последовательность

Элемент кода

Набор символов: цель использования

Китайский

Первый:

Алфавитный (английское имя)

Значение 1:

нет

ISO-IR 6

[ISO 646]

Второй:

Идеографический

Значение 1:

ISO 2022 IR 58

ISO-IR58

ISO 2022

ESC 02/04 02/09 04/01

ISO 2022 CN:

Китайский

Третий:

Фонетический

Значение 1:

нет

ISO-IR 6

ISO 2022

ESC 02/08 04/02

[ISO 646]:

Для разделителей