DICOM Deflated Explicit VR Little Endian(1.2.840.10008.1.2.1.99)

whi*_*der 7 image-processing dicom deflate

这种传输语法中的数据是如何组织的?标准说明:

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

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

从给定这种类型文件的查看器的角度来看,它如何知道这种传输语法?寻找GZIP标题?

是否有使用此传输语法的公开示例图像?

rkh*_*rkh 5

如果我没记错的话,DICOM将大多数流划分为两个数据集,第一个是DICOM文件元信息,它始终编码为显式VR小端传输语法,第二个数据集按文件元信息中的指示进行编码.

从:

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

"传输语法UID"标记描述为:

唯一标识用于编码以下数据集的传输语法.此传输语法不适用于文件元信息.


Mar*_*ler 3

对于@Springfield762 指出的示例,每个文件_dfl都有一个有效的 deflate 流,从 300 个奇数字节到距末尾 8 个字节。他们各自解压到存档中相应文件的长度(不带后缀_dfl),但数据并不相同。从解压缩的数据到原始数据需要额外的解码。

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

每个 deflate 流之后的最后八个字节与 gzip 预告片相同,即解压缩数据的 CRC-32(四个字节),后跟按小端顺序排列的未压缩长度。它们都与解压 deflate 流所得到的数据相匹配。

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