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

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