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是错误的。或者，我理解错了，大家一起探讨。

4 文件二进制数据

隐式小端

下面给的一个例子是隐式，小端的例子。可见GroupTag（7FE0）和ElementTag（0010），在实际二进制排列中是e07f 1000的二进制；0x00080000=524288个字节=2Byte512512

显式，小端

可见GroupTag（7FE0）和ElementTag（0010），VR:OW 缺省两个字节 ，VL： 0X00 08 00 00=524288个字节=2Byte512512

JpegLossLess 二进制存储方式 小端 显式