DICOM 文件中，VR，VL，SQ，图像二进制的几个注意点

DICOM 文件的结构，在网上有很多的学习资料，这里只介绍些容易混淆的概念，作为回看笔记。

1. 传输语法

每个传输语法，起都是表达的三个概念：大小端、显隐式、压缩算法

DICOM Implicit VR Little Endian: 1.2.840.10008.1.2
DICOM Explicit VR Little Endian: 1.2.840.10008.1.2.1
DICOM Explicit VR Big Endian: 1.2.840.10008.1.2.2
JPEG_LOSSLESS_TRANSFER_SYNTAX： “1.2.840.10008.1.2.4.70”;
在dcmtk中，dcmdata工程内dcxfer.cc文件都有明确的标识，例如JPEG_LOSSLESS_TRANSFER_SYNTAX： “1.2.840.10008.1.2.4.70”; 表示

{ UID_JPEGProcess14SV1TransferSyntax, // "1.2.840.10008.1.2.4.70"
  "JPEG Lossless, Non-hierarchical, 1st Order Prediction",
  EXS_JPEGProcess14SV1,
  EBO_LittleEndian,
  EVT_Explicit,
  EJE_Encapsulated,
  14L ,14L,
  OFFalse,
  OFFalse,
  ESC_none },

上边就表示了JPEG_LOSSLESS_TRANSFER_SYNTAX这个传输语法，是小端和显式的。

2 显式VR

当VR是OB OW OF UT SQ UT UN的时候，VL占用4个字节

组号	元素号	VR+预留	值长度	数据元素值
2字节	2字节	2字节+2字节(0x00,0x00)	4字节	由数据长度决定

在这里插入图片描述

当为其他普通类型的时候，是如下的结构

组号	元素号	VR+预留	值长度	数据元素值
2字节	2字节	2字节	2字节	由数据长度决定

在这里插入图片描述

隐式

组号	元素号	值长度	数据元素值
2字节	2字节	4字节	由数据长度决定

在这里插入图片描述

3. Sequence二进制文件编码

3.1. 显式长度

当Sequence的数据元素值被编码为32位无符号整数值的时候，这个长度应该包括由该数据元素传递的零个或多个Item产生的总长度。如果项目序列包含零个项目，则此数据元素长度应为00000000H。
在这里插入图片描述
以下是一个例子：

因为这个文件是显式小端（边）编码方式，标注1表示组号和元素号，标注2中显示，前两个字节是SQ，接下来2个字节是预留00 00，标注3中，长度是0x18，也就是24个字节长度，这就表示接下来的24个字节都是此Sequence元素。
接下来我们再详细看下Sequence内部item的定义的结构；内部的Item以FFFE,E000开始，然后是4个字节的长度，然后是一个标准的DataSet集合。
在这里插入图片描述
上图中，标注1就是Sequence中的Item的开始。

再看另外一个例子2，这个可以大家自己分析一下

3.2 当Sequence中，是未定义的长度，也就是，数据元素长度字段为FFFF，FFFFH的值的时候，此时，它应与序列定界项目结合使用。序列定界项目应位于项目序列的最后一个项目之后，其Item的标签应为（FFFE，E0DD），项目长度为00000000H。

在这里插入图片描述
以下是一个西门子CT产生的dicom文件片段，我个人感觉这个文件是错误的。

大家可以看到标注1的位置，表示这个sequence是没有设定长度的，所以，它的结尾是以FFFE,E0DD结束，后边再跟上0000 0000.也就是标注4所指的位置。这里，注意一下，第一个item的长度是四个字节，使用55 00 00 00来表示，换算为十进制就是85个字节，实际上接下来有122个字节，这里我感觉应该是7A 00 00 00。接下来的item都是正常，这里注意，内部也同样包含了一个SQ，内部的SQ的长度也是用FF FF FF FF表示的，这里的第一个item的长度文件内记为10 00 00 00，也就是16个字节，通过观察，确实是16个字节的长度，这样也可以进一步证明，标识2的位置55 00 00 00是错误的。或者，我理解错了，大家一起探讨。