Понимание BPP внутри изображений DICOM

Я работаю с файлами DICOM уже несколько дней, используя FO-DICOM.

Я использую набор файлов dicom для своих тестов и печатаю значения "Фотометрическая интерпретация" и "Образец на пиксель", чтобы лучше понять, с какими изображениями я работаю.

Результатом было "MONOCHROME2" для фотометрической интерпретации и "1" для выборки на пиксель.

Что я понял, прочитав часть 3 стандарта, так это то, что MONOCHROME2 представляет серую шкалу, начиная с черного для ее минимальных значений.

Но что такое Sample Per Pixel? Я думал, что это представляет количество байтов (а не бит) на пиксель (что было бы логично иметь 8 бит на пиксель для шкалы серого, верно?)

Но моя проблема здесь в том, что на самом деле мои изображения, кажется, имеют 32 bpp. Я работаю с изображениями 512*512 пикселей, и я преобразовал их в байтовые массивы. Поэтому я ожидал массивы 512*512=262144 байта. Но я получаю массивы 1048630 байт (что немного больше, чем 4*262144)

У кого-нибудь есть объяснение?

РЕДАКТИРОВАТЬ:

Вот некоторые из моих данных:

PhotometricInterpretation=MONOCHROME2
SamplePerPixel=1
BitsAllocated=16
BitsStored=12
HighBit=11
PixelRepresentation=0
NumberOfFrames=0
Источник

1 ответ

Решение

Атрибут (0028,0002) SamplesPerPixel относится только к цветным изображениям и сообщает вам количество плоскостей, которые присутствуют на изображении (например, 3 для RGB), поэтому у вас есть

PhotometricInterpretation=RGB
SamplesPerPixel=3

С 8 битами на пиксель (я вернусь к BPP ниже). Пока у вас есть PhotometricInterpretation = MONOCHROME1 или MONOCHROME2, вы можете ожидать SamplesPerPixel быть 1 и ничего больше.

То, что вы должны принять во внимание, это количество бит на пиксель:

BitsAllocated (0028,0100)
BitsStored (0028,0101)
HighBit (0028,0102)

Они говорят вам, сколько битов используется для кодирования значения пикселя (BitsAllocated) и какие из этих битов действительно содержат информацию в градациях серого (BitsStored, HighBit). HighBit начинается с нуля и обычно, но не обязательно = BitsStored-1

Пример, чтобы проиллюстрировать это: Для изображений CT очень часто выражают значения серого в единицах поля hounsfield, которые находятся в диапазоне от -1000 до +3000. Они представлены 12 битами, которые хранятся с 2-байтовым выравниванием, поэтому

BitsAllocated (0028,0100) = 16
BitsStored (0028,0101) = 12
HighBit (0028,0102) = 11

Еще одна степень свободы PixelRepresentation которая сообщает вам, если данные пикселя закодированы без знака (0) или в дополнении 2 с (1). Я видел оба для изображений CT, однако данные пикселей со знаком довольно необычны для типов изображений, отличных от CT.

В вашем примере я бы предположил, что Bits Allocated == 32 или (не очень вероятно), что у вас есть набор данных, содержащий несколько изображений ('frames'), поэтому NumberOfFrames (0028,0008) > 1. Если количество кадров отсутствует, можно смело предполагать, что он имеет только один кадр.

Здесь я немного упрощен, особенно в отношении цветных изображений, но я думаю, что это достаточно сложно;-). По сути, DICOM предлагает любую мыслимую степень свободы для кодирования данных пикселей и описания кодирования в заголовке.

Я думаю, что я рекомендовал вам взглянуть на DCMTK в недавнем посте. Класс DicomImage имеет приятный интерфейс (getInterData()), который заботится обо всем этом и предоставляет данные пикселей, считанные из файла DICOM в нормализованном формате.

[РЕДАКТИРОВАТЬ]: Не стесняйтесь публиковать DICOM-дамп вашего набора данных здесь, я бы посмотрел на него и рассказал, как интерпретировать данные пикселей.

Источник
Другие вопросы по тегам