DICOM 放气显式 VR Little Endian (1.2.840.10008.1.2.1.99)答案

【问题标题】：DICOM Deflated Explicit VR Little Endian (1.2.840.10008.1.2.1.99)DICOM 放气显式 VR Little Endian (1.2.840.10008.1.2.1.99)
【发布时间】：2015-10-14 01:26:35
【问题描述】：

这种传输语法中的数据是如何组织的？来自标准的描述：

此传输语法适用于整个 DICOM 数据集的编码。整个数据集首先根据 A.2 节中指定的规则进行编码。然后使用 Internet RFC 1951 中定义的“Deflate”算法压缩整个字节流。

最初我认为这意味着整个 DICOM 文件本身已被 gzip 压缩。但是，如果整个文件被压缩，包括包含识别传输语法的标头，解析器/查看器如何能够读取传输语法以知道它是压缩的？

从给定这种类型文件的查看者的角度来看，它如何知道它是这种传输语法？寻找 GZIP 标头？

是否有任何公开可用的使用这种传输语法的示例图像？

【问题讨论】：

标签： image-processing dicom deflate

【解决方案1】：

如果我没记错的话，DICOM 将大多数流分为两个 Dataset，第一个是 DICOM 文件元信息，它始终被编码为 Explicit VR Little Endian Transfer Syntax，第二个 Dataset 被编码为文件元信息中所示。

发件人：

http://medical.nema.org/dicom/2013/output/chtml/part10/chapter_7.html

“Transfer Syntax UID”标签描述为：

唯一标识用于对以下内容进行编码的传输语法数据集。此传输语法不适用于文件元信息。

【讨论】：

【解决方案2】：

对于@Springfield762 指出的示例，每个_dfl 文件都有一个有效的放气流，从末尾开始有300 个奇数字节到8 个字节。他们每个都解压缩到档案中没有_dfl后缀的相应文件的长度，但数据不一样。从解压缩的数据到原始数据需要额外的解码。

image_dfl 有一个 deflate 流，从偏移量 334、report_dfl 在 348 和 wave_dfl 在 314 开始。它们分别解压缩到 262682、6178 和 62408 字节。

每个 deflate 流之后的最后 8 个字节与 gzip 预告片相同，即解压缩数据的 CRC-32（四个字节），然后是小端顺序的未压缩长度。它们都与解压缩 deflate 流产生的数据相匹配。

deflate 数据之前的字节不是 gzip 标头。

【讨论】：

你知道什么会夸大这些数据吗？我弄清楚了偏移量，但不知道预告片（所以这有帮助）。我尝试使用几个基于 zlib 的工具/实现来膨胀它们，但一切都失败了。 Osirix 可以读取它们，所以我知道数据必须是有效的。放气标头有效吗？
是的，zlib 会。这就是我用的。放气数据有效。你需要做一个原始的膨胀。请参阅inflateInit2() 文档。

【解决方案3】：

您可以从这里下载一些以 1.2.840.10008.1.2.1.99 传输语法编码的测试 DICOM 图像：

http://www.dclunie.com/images/compressed/

解压存档时，使用 Deflated 传输语法的图像被命名为：name_dfl

该传输语法只是压缩整个 DICOM 数据的一种，但是当我在 Hex Editor XVI32 中打开它时，它看起来像 dicom 文件的元数据未压缩，因此您可以读取传输语法，但我找不到其他编码的图像传输语法，所以我不确定。

【讨论】：