DICOM-文件解析
参考文献
- https://plastimatch.org/dicom_tutorial.html
- https://saravanansubramanian.com/makingsenseofdicomfile/
DICOM Elements
- DICOM 对象由 DICOM 元素或 DICOM 属性组成.
- 每个 DICOM 元素都有一个标签、称为 VR(值表示的缩写)的数据类型、长度和值.各行以标签号 (gggg,eeee) 开头,然后是 VR 代码,然后是值(字符串打印在方括号中),然后是井号 (#),后跟元素值长度、逗号,然后是值多重性和标签名称.这张取自 DICOM 标准第 5 章的图中显示了 DICOM 编码元素的方式.
Tags
标签
- 每个 DICOM 元素都有一个唯一定义该元素及其属性的标签,就像条形码定义超市中的产品一样. DICOM 标签由两个短数字组成,称为“组”和“元素”.彼此相关的 DICOM 标签有时具有相同的组.
Value Representation
价值表示
- VR 用两个字符代码表示. VR定义了元素的数据类型. UI 代表唯一标识符,US 代表无符号短整型,CS 代表编码字符串,OB 代表其他字节,即字节流.
- 因为每个元素都有一个标签,所以标签隐式定义了 VR.例如,行元素(标签 0028,0010)始终为 US(无符号短整型).这就是为什么 VR 通常是多余的并且可以省略的原因.然而,常见的做法和 IHE 建议是在将 DICOM 对象序列化到文件或网络缓冲区时明确声明 VR.
Value Length
值长度
- 因为 DICOM 是二进制协议(与 html 和 xml 等文本协议相反),所以元素具有长度. DICOM 元素长度始终是偶数.即使元素的值是单个字符串,例如患者性别 (0010,0040),即“M”(代表男性)、“F”(女性)或“O”(其他),元素长度也应为 2,且值将为用空格填充 (ASCII 0x20).字符串类型(如 CS 和 UI)用空格填充,二进制类型(如 US)用 null 0x0 填充.
DICOM Data Model
DICOM
数据模型定义信息实体(Information Entities IE
):Patient, Study, Series and Image(Instance )
DICOM
静态数据模型的类称为"Service Object Pair" SOP
类,由 IOD(Information Object Definition
信息对象定义)定义.- 所有 DICOM 对象必须包括 SOP 通用模块和来自四个主要 IE 的模块:
Patient, Study, Series
和Image
(图像和实例在 DICOM 中是相同的.曾经只有图像,但随后定义了非图像的对象,并且因此,名称从Image
更改为Instance
,以表示 SOP 类的实例).所有 DICOM 图像(即作为图像的 DICOM 实例)必须包含图像模块.因为每个 DICOM 对象都必须是Series
的一部分,所以所有 DICOM 对象必须包括通用Series
模块,并且因为所有系列必须是Study
的一部分,所以每个 DICOM 对象必须包括通用研究模块,并且因为每个研究都是针对某个患者进行的,所有 DICOM 对象都必须有一个Patient
模块.- SOP 是一对 DICOM 服务和 DICOM 对象,如辅助捕获对象和存储服务.
Secondary Capture Image IOD
- 所有标有 U 的行(将这些模块标记为用户可选),只留下代表强制模块的 M 行
IE | Module | Reference | Usage |
---|---|---|---|
Patient | Patient | C.7.1.1 | M |
Clinical Trial Subject | C.7.1.3 | U | |
Study | General Study | C.7.2.1 | M |
Patient Study | C.7.2.2 | U | |
Clinical Trial Study | C.7.2.3 | U | |
Series | General Series | C.7.3.1 | M |
Clinical Trial Series | C.7.3.2 | U | |
Equipment | General Equipment | C.7.5.1 | U |
SC Equipment | C.8.6.1 | M | |
Image | General Image | C.7.6.1 | M |
Image Pixel | C.7.6.3 | M | |
Device | C.7.6.12 | U | |
Specimen | C.7.6.22 | U | |
SC Image | C.8.6.2 | M | |
Overlay Plane | C.9.2 | U | |
Modality LUT | C.11.1 | U | |
VOI LUT | C.11.2 | U | |
SOP Common | C.12.1 | M |
IE | Module | Reference | Usage |
---|---|---|---|
Patient | Patient | C.7.1.1 | M |
Study | General Study | C.7.2.1 | M |
Series | General Series | C.7.3.1 | M |
Equipment | SC Equipment | C.8.6.1 | M |
Image | General Image | C.7.6.1 | M |
Image Pixel | C.7.6.3 | M | |
SC Image | C.8.6.2 | M | |
SOP Common | C.12.1 | M |
Unique Identifiers (UID’s)
- DICOM 广泛使用唯一标识符. DICOM 数据模型中的几乎每个实体都有一个唯一的标识符.在 DICOM 中,每个 SOP 类都有其 UID.所有预定义 UID(包括 SOP 类 UID)均记录在 DICOM 标准的第 6 章中. DICOM 对象是此类的实例,称为 SOP 实例,它还有一个称为 SOP 实例 UID 的 UID. DICOM 定义了一种机制来确保 UID 是全局唯一的.每个 DICOM 应用程序都应该获取一个“根”UID,用作其创建的 UID 的前缀. DICOM 数据模型中的每个实体也有一个 UID(患者除外).患者通过姓名和 ID 的组合来识别.
Study
、Series
都有 UID. DICOM 档案 (PACS) 应使用 UID 为其数据库建立索引,以便当其他应用程序进行搜索(查询)时,它们可以使用 UID 引用对象,并且档案可以快速响应搜索. - 此发布的标识符(通常称为“组织根”)用作整体标识符的一部分,以确保没有两个组织或实施者可以生成彼此冲突的 DICOM 信息,即使它们位于全球各地。例如,在 SOP UID 1.2.840.10008.5.1.4.1.1.1.2 中,用于表示数字乳腺 X 射线图像存储 – 用于演示,“1.2.840.10008”是保留仅供以下人员使用的组织根: DICOM 委员会。然后将组织根附加到由实施组织生成的后缀。
- 整体UID编码方案如下所示:
{org root}.{suffix}
。后缀又可以包含一组使用组织规则生成的标识符。 DICOM 标准并不关心如何管理这些,尽管行业中的最佳实践似乎遵循“{应用程序 id 或 MAC id}.{org 对象类型 id}.{唯一密钥 id}{日期和时间}
”等约定。
DICOM
文件解析
- 每个DICOM文件都由三个主要部分组成.
- 文件头:
File header
- 文件元信息表头:
File meta-information header
- 该部分紧跟在文件头之后,由一个数据集组成,该数据集由一系列标记信息(称为“Dicom 元素”)组成,该数据集指定传输语法(如上所述)等详细信息以及有关设备或实现的其他信息创建此文件的人以及为谁创建此信息的人(接收应用程序).
- 数据对象:
Data object
- 文件头:
序言和标题Preamble and header
-
DICOM
文件可能有标题,也可能没有.标准说它们需要一个标头,但较旧的dicom
文件不会有这个标头.如果它有标题,则其格式如下:128 byte file preamble, containing application-specific data
- 128 字节文件前导码,包含特定于应用程序的数据
4 bytes containing the string “DICM”
- 包含字符串“
DICM
”的 4 个字节
- 包含字符串“
数据元素Data elements
dicom
数据集(例如文件)包括一系列数据元素.单个数据元素由以下字段组成:
-
4 bytes containing the string “DICM”
- 4字节标签(包括2字节组号+2字节属性号)
- “(0008, 0070)”表示属于组号 0008、属性号为 0070 的标签
-
2 byte value representation (optional, with optional 2 byte reserved field)
- 2 字节值表示(可选,带有可选的 2 字节保留字段)
-
2 or 4 byte value length
- 2 或 4 字节值长度
-
variable length value field (with even bytes)
-
可变长度值字段(偶数字节)
值表示Value representations
- 值表示(
VR
)是数据的“类型”.例如,它表示某个项目是字符串、整数、UID 还是序列.
值长度Value length
- 值长度是 2 或 4 字节无符号整数.如果有
Explicit VR
(显式VR
)则为2字节,否则为4字节.如果没有元信息标头,则此选择是不明确的.
显式和隐式 VRExplicit and implicit VR
VR
可以是Explicit
显式的,也可以是Implicit
隐式的.显式意味着VR
与每个对象一起指定,而隐式意味着应用程序必须从字典中查找正确的VR
.字典将(组、元素)对映射到VR
值.- 应用程序在应用程序标头中描述是否将使用隐式或显式
VR
.一个特殊情况是由序列标签 (fffe,e000
)、(fffe,e00d
) 和 (fffe,e0dd
) 组成,它们始终是隐式VR
.
元信息头Meta-information header
- 由于数据元素可以是显式或隐式
VR
,并且数据可以是小端序little-endian
或大端序big-endian
,因此DICOM
使用组0002
中的数据元素来解释这些歧义.这组数据称为元信息头.
属性类型Attribute types
- 属性可以是必需的、有条件地必需的或可选的.属性类型告诉我们其中哪一个成立
1 Required, cannot be empty
1
必填,不能为空
1C Conditionally required, cannot be empty
1C
有条件必填,不能为空
2 Required, can be empty
2
必填,可以为空
2C Conditionally required, can be empty
2C
有条件必填,可以为空
3 Optional
3
可选
DICOM RT
- 这些是
DICOM
标准中定义的额外IOD
(信息对象):RT 图像、RT 计划、RT 离子计划、RT 剂量和 RT 结构集.
IOD
- IOD 对象本身被分成称为信息实体(
Information Entities
缩写为 IE)的子组,而信息实体又被分成信息模块的小组.信息模块由一系列我们已经见过的 DICOM 元素组成. DICOM 定义了哪些模块是强制性的、哪些是有条件存在的以及哪些是可选的规则. IOD 本身分为标准化 IOD(Normalized IODs
) 和复合 IOD(Composite IODs
).标准化 IOD 表示仅与一个实体相关的数据,而复合 IOD 表示来自彼此相关的各种实体的混合数据
本博客所有文章除特别声明外,均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来自 HoleLin's Blog!