DICOM入门系列——DICOM文件结构解析：从标签到像素数据

czhmx

1013人浏览 · 2025-11-28 18:21:58

czhmx · 2025-11-28 18:21:58 发布

在上一篇文章《DICOM入门系列——DICOM简介》中，我们了解到DICOM（医学数字成像和通信）是医学影像领域的“通用语言”，解决了不同设备与系统间的互联互通问题。但要真正理解DICOM如何存储和传递医学图像，必须深入其核心——DICOM文件的结构。

一个DICOM文件看似只是一个普通的“.dcm”文件，实则是一个精心设计的“数据包裹”，内部由文件元信息头（File Meta Information）和核心数据集（Data Set）两部分组成，通过一系列标准化的“标签（Tag）”组织患者信息、设备参数和图像像素数据。本文将带你逐层拆解DICOM文件的结构，从最基础的“标签”开始，逐步解析到最终的图像像素数据，揭开它的神秘面纱。

一、DICOM文件的“双层包装”：元信息头 + 数据集

DICOM文件采用二进制格式存储（不能用记事本直接打开），其物理结构分为严格的两个部分：

1. 文件元信息头（File Meta Information，Part 10规定）

这是DICOM文件开头的“头部说明书”，采用Explicit VR Little Endian（显式值表示+小端字节序）传输语法，主要包含与文件本身相关的“高层信息”，例如：

文件是否遵循DICOM标准（通过固定标识“DICM”确认）；
图像的存储格式规范（如传输语法UID，决定后续数据如何解码）；
文件的唯一标识符（如实现类UID、媒体存储SOP类UID）。

这部分的作用类似于“文件说明书”，告诉解析软件：“接下来的数据是按照DICOM标准组织的，具体解码规则如下”。

2. 核心数据集（Data Set）

这是DICOM文件的“主体内容”，包含患者信息、检查参数、设备信息以及最关键的图像像素数据。数据集由一系列数据元素（Data Element）组成，每个数据元素通过唯一的“标签（Tag）”定位，存储特定的信息（如患者姓名、CT扫描层厚或图像的像素矩阵）。

简单来说：元信息头是“规则说明”，数据集是“实际内容”，二者共同构成一个完整的DICOM文件。

二、文件元信息头：DICOM文件的“身份证明”

文件元信息头位于DICOM文件的最开头，长度不固定（通常约128字节的前导空白 + 128字节后的固定内容）。它的核心作用是标识这是一个标准的DICOM文件，并定义后续数据的解析规则。

关键组成部分：

前导128字节（可选空白）：早期设计用于兼容其他格式，现代DICOM文件通常直接跳过这部分。
128字节后的“DICM”标识：这是DICOM文件的“身份证”，文件开头偏移128字节后的4个字节必须是ASCII字符 'D' 'I' 'C' 'M'（十六进制值为0x44 0x49 0x43 0x4D）。如果这4个字节不存在或不对，解析软件会认为这不是一个标准DICOM文件。
元信息数据元素（Meta Elements）：紧随“DICM”之后，是一系列符合DICOM标准的数据元素，最重要的包括：
- (0002,0002) Media Storage SOP Class UID：说明该文件存储的医学影像类型（例如“1.2.840.10008.5.1.4.1.1.2”表示CT图像存储）；
- (0002,0010) Transfer Syntax UID：定义后续数据集的编码规则（如是否压缩、字节序、值表示方式），例如“1.2.840.10008.1.2.1”表示显式VR小端序（最常用）；
- (0002,0012) Implementation Class UID：标识生成该文件的软件/设备的唯一类标识符。

📌 为什么需要元信息头？

因为DICOM文件的数据集可能采用不同的编码规则（如压缩、字节序），元信息头通过Transfer Syntax UID提前告知解析软件：“后续数据要按照XX规则解码”，避免出现“语言不通”的错误。

三、核心数据集：由“标签”驱动的结构化信息仓库

数据集是DICOM文件的“核心内容”，包含患者信息、检查参数、设备信息以及图像像素数据。它的组织方式非常独特——不通过传统的分段或表格，而是由一系列“数据元素（Data Element）”按顺序排列，每个数据元素通过唯一的“标签（Tag）”定位，类似数据库中的“键值对”，但更严格。

1. 数据元素（Data Element）的结构

每个数据元素由4个关键字段组成（按顺序紧密排列）：

字段	说明	示例（以患者姓名为例）
Tag（标签）	数据元素的唯一标识符，由两组16进制数（Group, Element）组成，例如(0010,0010)	(0010,0010) 表示“患者姓名”
Value Representation (VR，值表示)	定义该数据值的类型（如文本、数字、日期），例如PN（人名）、DA（日期）、US（无符号整数）	PN（人名）表示患者姓名是文本类型
Value Length（值长度）	该数据值占用的字节数（部分传输语法中可省略）	若患者姓名为“张三”，长度可能是6字节（含分隔符）
Value（值）	实际存储的数据内容	“张三”（文本）、19800101（日期）、512（图像行数）等

📌 关键点：

Tag是数据元素的“身份证”，例如(0010,0010)永远代表“患者姓名”，(7FE0,0010)永远代表“图像像素数据”。

VR和Value Length在部分传输语法（如Implicit VR Little Endian）中可能被省略，但Explicit VR（显式值表示）是更常用且易读的格式。

2. 常见数据元素（Tag）示例：从患者信息到图像参数

以下是DICOM数据集中常见的关键Tag及其含义（均为显式VR格式）：

Tag（组,元素）	VR（值类型）	名称（中文）	典型值示例	说明
(0010,0010)	PN（人名）	患者姓名	“张三^三”	姓名格式通常为“姓^名”
(0010,0020)	LO（长字符串）	患者ID	“123456”	医院的唯一患者编号
(0010,0030)	DA（日期）	出生日期	“19800101”	格式为YYYYMMDD
(0010,0040)	CS（代码字符串）	性别	“M”（男）/“F”（女）	男性用M，女性用F
(0008,0060)	CS（代码字符串）	模态（Modality）	“CT”（CT扫描）、“MR”（MRI）、“CR”（X光）	标识检查设备类型
(0018,0050)	DS（十进制字符串）	层厚（Slice Thickness）	“1.25”	CT扫描的每层厚度（单位：mm）
(0020,0010)	SH（短字符串）	检查ID（Study ID）	“12345678”	本次检查的唯一编号
(0028,0010)	US（无符号整数）	图像行数（Rows）	“512”	图像的垂直像素数
(0028,0011)	US（无符号整数）	图像列数（Columns）	“512”	图像的水平像素数
(0028,0100)	US（无符号整数）	每像素比特数（Bits Allocated）	“16”	通常为8（灰度）或16（高精度）
(7FE0,0010)	OW（其他字长）	像素数据（Pixel Data）	[二进制数组]	实际的图像像素矩阵（核心数据！）

📌 重点说明：

(7FE0,0010) 像素数据是DICOM文件中最大的数据块，存储了图像的原始像素矩阵（例如一张512×512的CT图像，每个像素占2字节（16比特），则该部分占512×512×2=524,288字节）。

其他Tag存储的元数据（如患者信息、检查参数）虽然直观，但像素数据才是图像可视化的核心。

四、从DICOM文件到图像：解析流程示例

假设你有一个名为“CT_example.dcm”的文件，它的解析流程大致如下：

读取前128字节：跳过（通常无有效信息）；
检查第132-135字节（偏移128+4）：确认是否为“DICM”标识（如果是，则为标准DICOM文件）；
解析元信息头：读取后续的元数据元素（如Transfer Syntax UID），确定后续数据集的编码规则（例如是否压缩、字节序）；
解析数据集：按顺序读取每个数据元素：
- 先读Tag（如(0010,0010)），判断是“患者姓名”；
- 再读VR（如PN），确认值类型是“人名”；
- 接着读Value Length（如6字节），知道后续值的长度；
- 最后读Value（如“张三”），获取实际内容；
定位像素数据：当读到Tag为(7FE0,0010)时，该数据元素的Value就是图像的像素矩阵（可能是8位灰度或16位高精度数据）；
重建图像：根据像素数据（如512×512×16bit）和元数据（如窗宽窗位），通过专业软件（如OHIF Viewer）显示为可视化的医学图像。

五、为什么理解DICOM文件结构很重要？

对于不同角色，掌握DICOM文件结构的意义各不相同：

医生/影像科技师：了解患者信息、检查参数（如层厚、模态）如何存储，有助于更准确地解读图像；
医疗IT工程师：在部署PACS系统、对接不同设备时，需确保DICOM文件的元数据和像素数据符合标准，避免兼容性问题；
开发者/研究人员：若想用代码（如Python的pydicom库）提取患者姓名、图像尺寸，或开发AI模型处理DICOM图像，必须清楚Tag的含义和数据排列规则；
医学生/初学者：理解DICOM文件不是“单纯的图片”，而是包含丰富信息的“结构化数据包”，是深入学习医学影像信息化的基础。