DCMTK: мин-макс-окно, мин-макс-окно-n и гистограмма-окно

Я хотел бы преобразовать набор экземпляров DICOM (CT, MR, X-Ray в основном) в JPEG (обычные 8-битные оттенки серого с потерями). Я рассматривал варианты из dcmj2pnm:

Я совершенно уверен, что --use-window 1 является правильным вариантом, когда входной экземпляр DICOM предоставляет одно значение для (0028,1050) центра окна и (0028,1051) ширины окна. Чего я не понимаю, так это того, какой правильный вариант выбрать (когда WC / WW отсутствует):

  1. --min-max-window,
  2. --min-max-window-n (что означает extreme values?),
  3. --histogram-window 5 (найдена ссылка здесь)

Существуют ли какие-либо эмпирические правила при обработке изображений DICOM CT (Pixel Padding Value)? МР изображения? Рентгеновские снимки?


person malat    schedule 24.06.2020    source источник


Ответы (1)


Будучи автором этого инструмента DCMTK, я должен быть в состоянии ответить на ваши вопросы.

Я вполне уверен, что --use-window 1 является правильным вариантом, когда входной экземпляр DICOM предоставляет одно значение для (0028,1050) центра окна и (0028,1051) ширины окна.

Это верно, по крайней мере, в том случае, если сохраненное окно VOI правильное (т. е. соответствует сохраненным данным пикселей).

Чего я не понимаю, так это того, какой правильный вариант выбрать (когда WC / WW отсутствует):

Как правило, --min-max-window (вычисление окна VOI с использованием алгоритма минимума-максимума) обычно дает хорошие результаты. Если на изображении есть экстремальные значения (очень низкие и/или очень высокие значения пикселей), которые не относятся к медицинскому контенту, их можно игнорировать: опция --min-max-window-n игнорирует минимальное и максимальное значения (и использует следующее более низкое/более высокое значение в данных пикселей в качестве границ окна VOI), опция --histogram-window [n] вычисляет гистограмму значений пикселей, используемых в изображении, и игнорирует n процентов как нижних, так и высоких значений (при вычислении окна VOI).

person J. Riesmeier    schedule 24.06.2020
comment
Было бы неплохо уточнить поведение в отношении Pixel Padding Value - person malat; 24.06.2020
comment
Pixel Padding Value не принимается во внимание. См. проблему DCMTK № 141: support.dcmtk.org/redmine/issues/141. - person J. Riesmeier; 24.06.2020