У меня есть файл DICOM, который начинается примерно так, и для меня это имеет смысл, основываясь на частях 5, 6 и 10 спецификации, но элемент версии метаинформации файла (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. Я ожидаю 0200 для длины значения (2 байта) и 0001 для версии, но каковы два набора 0000 между?
Я не нашел здесь никакой спецификации заполнения, и в любом случае все упоминания о заполнении, которые я нашел в спецификации, распространяются только на заполнение двухбайтовыми границами, а не четырьмя или более.
И если бы нули были ведущими нулями в 32-битных количествах, то я ожидал бы, что они придут после 0200 и 0100, а не раньше. И, конечно, тогда длина должна быть 0400, а не 0200.
Файл был создан OrthancWSIDicomizer.exe, частью предложения Orthanc DICOM.
Что мне не хватает? (Помимо очевидного: глубокое понимание DICOM!)