Почему я должен вычитать значения пикселей изображения dicom из 2 ^ 15, когда я использую dcmtk?

Я использую dcmtk для чтения изображений dicom, и у меня есть следующий атрибут с новыми образцами:

(0028,0004) Photometric Interpretation: MONOCHROME2
(0028,0010) Rows: 512
(0028,0011) Columns: 512
(0028,0030) Pixel Spacing: 0.4688\0.4688
(0028,0100) Bits Allocated: 16
(0028,0101) Bits Stored: 16
(0028,0102) High Bit: 15
(0028,0103) Pixel Representation: 1
(0028,0106) Smallest Image Pixel Value: 0
(0028,0107) Largest Image Pixel Value: 2732
(0028,1050) Window Center: 1366
(0028,1051) Window Width: 2732

Я использую getOutputData(16) для чтения данных int16_t. Это меня удивило, потому что значения отрицательны около -1 * (2 ^ 16), и когда я вычел значения на 2 ^ 15, все кажется в порядке, и я могу видеть изображения! :-(

Теперь у меня два вопроса:

  1. Почему я должен вычесть значение 2 ^ 15, и все будет в порядке? На изображении нет значения заполнения!
  2. В документе getOutputData говорится о отображаемых пиксельных данных всегда без подписи.. Что это означает, когда данные моего изображения подписаны, потому что атрибут (0028,0103) говорит мне об этом? Если этот метод не подходит, могу ли я получить реальные данные с помощью dcmtk?

person mf mf    schedule 28.05.2013    source источник
comment
getOutputData возвращает void * и (как вы сами упомянули) согласно документации выходные данные всегда беззнаковые. Так не следует ли вместо этого преобразовать выходные данные в uint16?   -  person Anders Gustafsson    schedule 29.05.2013
comment
Не могли бы вы включить значения (если они есть) для Наклон изменения масштаба (0028,1053) и Пересечение масштаба (0028,1052), как предложил Паоло?   -  person jap1968    schedule 29.05.2013


Ответы (5)


Ключом является элемент данных Pixel Representation (0028,0106).

PixelRepresentation = 0 -> unsigned
PixelRepresentation = 1 -> signed

В вашем случае у вас есть значение «1», поэтому вы должны читать и интерпретировать значения как целые числа со знаком.

Дополнительную информацию можно найти здесь.

person jap1968    schedule 29.05.2013
comment
Я знаю это. Но это не ответ на мой вопрос! Прочитал там дополнительную информацию. Нет ничего о том, почему я должен вычитать с 2 ^ 15. - person mf mf; 29.05.2013
comment
Это операция для вычисления дополнения до двух для 16-битного числа. Я имею в виду, что это операция преобразования числа, интерпретируемого как целое число без знака, в такое же число, интерпретируемое как целое число со знаком. Посмотрите раздел Вычитание из 2N. - person jap1968; 29.05.2013


Согласно документации getOutputData применяет VOI презентации перед рендерингом, поэтому вы всегда получаете неподписанные данные. Итак, если вы запросите 16-битные данные, вы получите пиксели в диапазоне от 0 до 65535, независимо от минимального и максимального значений, указанных в наборе данных; это потому, что возвращаемые данные предназначены для отображения, а не исходные данные, хранящиеся в изображении. Я думаю, вам следует просто сдвинуть значения вправо на 8 бит или просто запросить 8-битные данные (даже если изображение 16-битное): я не думаю, что ваша графическая карта все равно может обрабатывать 16-битные оттенки серого.

person Paolo Brandoli    schedule 31.05.2013

заголовок DICOM говорит, что данные хранятся в файле DICOM как значение со знаком, но похоже, что документация говорит, что getOutputData преобразует его в значение без знака. поэтому попробуйте прочитать вывод getOutputData как uint16_t вместо int16_t.

person michael pan    schedule 01.06.2013
comment
Возможно, причина в том, что исходные значения являются отрицательными. - person jap1968; 01.06.2013
comment
uint_16 имеет диапазон от 0 до 65 535. int_16 имеет диапазон от –32 768 до 32 767. если сохраняемые значения превышают 32767, будет установлен 16-й бит. вот почему, если вы int_16, он будет отображаться как отрицательный. - person michael pan; 01.06.2013

Я нашел ответ. Это объяснили здесь хорошие официальные разработчики. См. стр. 2. Это полностью связано с набором инструментов DCMTK.

person mf mf    schedule 09.06.2013