Question

我有一个像这样开始的DICOM文件，并且根据规范第5、6和10部分，大多数文件对我来说都是有意义的，但是File Meta Information Version元素（0002,0001）使我感到困惑。

00000000: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000010: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000020: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000030: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000040: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000050: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000060: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000070: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000080: 4449 434d 0200 0000 554c 0400 ce00 0000  DICM....UL......
00000090: 0200 0100 4f42 0000 0200 0000 0001 0200  ....OB..........
000000a0: 0200 5549 1e00 312e 322e 3834 302e 3130  ..UI..1.2.840.10
000000b0: 3030 382e 352e 312e 342e 312e 312e 3737  008.5.1.4.1.1.77
000000c0: 2e31 2e36 0200 0300 5549 3800 312e 322e  .1.6....UI8.1.2.

这是我不明白的地方：

00000090: 0200 0100 4f42 0000 0200 0000 0001

前四个字节是（0002,0001）标记，后两个字节是VR 4f42 = OB。我希望值长度（2个字节）为0200，版本为0001，但是两者之间的两组0000是什么？

我在这里没有找到任何关于填充的规范，无论如何，我在规范中发现的所有关于填充的内容都只延伸到填充两个字节的边界，从来没有四个或更多。

如果零在32位数量中领先于零，那么我希望它们会出现在0200和0100之后，而不是之前。当然，长度必须是0400，而不是0200。

该文件由Orthanc DICOM产品的一部分OrthancWSIDicomizer.exe创建。

我想念什么？（除了显而易见的一点：对DICOM的深刻理解！）

Answer 1

我在这里没有找到任何填充规范，

数据元素已正确编码：在小尾数显式VR传输语法中，根据数据元素的值表示形式，存在填充。根据{{3}}，如果VR是“ OB”，“ OD”，“ OF”，“ OL”，“ OW”，“ SQ”，“ UC”，“ UR”，“ UT”之一，或“ UN”，然后两个VR字节后跟“保留（2个字节），将其设置为0000H的值” ，并且元素的长度定义为4个字节，而不是2个字节。在这种情况下，这些是位置0096处的字节。 0098后面的4个字节代表元素的长度：0200 0000（2的小尾数）。

带头的完整数据元素为14个字节长：0200 0100 4f42 0000 0200 0000 0001，（0002,0001）文件元信息版本OB，值为1。

DICOM文件元信息版本用零填充

1 个答案: