#image-processing #colors #rgb #dicom
Вопрос:
Файл DICOM может содержать либо несжатые пиксельные данные, либо сжатые пиксельные данные. Это PhotometricInterpretation (0028,0004) может быть МОНОХРОМ1/МОНОХРОМ2/RGB/ЦВЕТ ПАЛИТРЫ/YBR и т.д. Существует также страница Pydicom о цветовом пространстве.
Но с этих страниц или с любых других сайтов DICOM мне непонятно, как получить глубину цвета.
Относится BitsAllocated (0028,0100) ли BitsStored (0028,0101) тег или или к глубине цвета? Может ли его глубина цвета отличаться от этих двух значений тегов?
Как надежно получить глубину цвета пиксельных данных DICOM?
Ответ №1:
Bits Stored это количество битов, используемых для фактических данных о цвете или оттенках серого, поэтому оно, по крайней мере, связано с глубиной цвета. Bits Allocated всегда кратно 8, так как данные всегда организованы в байтах, где некоторые верхние биты могут не использоваться для данных (за исключением битовых данных, где это 1).
Получение битовой глубины не так просто, как может показаться. В то время как количество битов, используемых для данных , в основном может быть определено, разрешение данных (например, расстояние между соседними значениями) также может зависеть от Photometric Interpretation и, конечно, от разрешения, предоставляемого самой модальностью.
Самый простой случай-монохромные данные ( Photometric Interpretation is MONOCHROME1 или MONOCHROME2 ), где глубина цвета напрямую определяется Bits Stored типичными значениями 12, 14 или 16. Те же, в основном, справедливо для RGB данных (например, данных изначально записан как RGB), и хотя это правда, что Bits Stored могут иметь разные значения для JPEG2000, закодированных изображений, как правильно упомянул @kritzel_sw, мне еще предстоит увидеть какие-либо RGB данные с Bits Stored отличается от 8. Обновление: я до сих пор не видел этого, но обнаружил, что RTDOSE изображения могут иметь до 32 бит хранится.
Для цветовых данных в цветовом пространстве YBR ( Photometric Interpretation is YBR_xxx ) это менее ясно. Это в некоторой степени зависит от вашего определения глубины цвета. Учитывая, что используется цветовое пространство МБР, а не в RGB, а количество битов, используемых для каждого компонента может быть различным (например YBR_FULL_422 , которая используется для некоторых сжатые JPEG-изображения, 2 канала Наш уменьшено), полученное изображение при преобразовании в RGB с (что в основном) использует 8 бит для каждого компонента цвета, но фактическое число возможных значений меньше 256 по этой причине. Поэтому, если ваше определение глубины цвета зависит от количества битов, используемых на канал RGB, в этом случае ответ, вероятно, будет равен 8, но если вы определяете глубину цвета на канал YBR, ответ может быть другим и зависит как от Photometric Interpretation и Bits Stored .
Особым случаем является PhotometricInterpretation вариант of PALETTE COLOR , где возможные цвета определены в таблице цветов. В этом случае количество цветов на цветовой компонент определяется в первом значении Дескриптора Таблицы поиска цветов палитры (0028,1101-1104), которое равно для всех 3 таблиц (например, для Красного, Зеленого и Синего компонентов). Фактическая глубина цвета должна быть получена из этого значения.
Учитывая все это, ответ, вероятно, таков: это зависит от обстоятельств. Я также добавлю примечание @kritzel_sw, что многие из IOD значительно ограничивают степень свободы кодирования данных пикселей, что сузит возможности глубины цвета для любого конкретного типа изображений.
Мне интересно, есть ли у кого-нибудь более прямой ответ.
Комментарии:
1. По общему признанию, очень маловероятно найти такие изображения в реальности, но теоретически неверно, что фотометрическая интерпретация = RGB означает «8 бит на канал». Смотрите здесь: dicom.nema.org/medical/dicom/current/output/html/…
2. Спасибо — вы, конечно, правы. Я немного адаптировал ответ, и с каждой поправкой он становится все более расплывчатым… Я, возможно, посмотрю еще раз позже, так как на самом деле это немного сложно. Вопрос также в том, для чего используется/требуется результирующая глубина цвета.
3. Добро пожаловать в удивительный мир пиксельного кодирования данных в DICOM. Чтобы отказаться от всей сложности, я хотел бы упомянуть, что многие из IOD значительно ограничивают степень свободы в том, как кодируются пиксельные данные. Поэтому, если вопрос не возникает в контексте средства просмотра общего назначения, существует большой потенциал для упрощения за счет сужения поддержки для различных типов изображений.
4. О «необработанные пиксельные данные могут использоваться независимо от LUT». Я склонен не соглашаться. Существуют некоторые крайние случаи, описание которых в стандарте DICOM может вводить в заблуждение. Например, см. groups.google.com/g/comp.protocols.dicom/c/qr_A0vUYrJs. Однако это не относится к фотометрической интерпретации ЦВЕТА ПАЛИТРЫ — просто для того, чтобы избежать большей путаницы, чем это неизбежно необходимо 😀 @scaramallion: Можете ли вы указать ссылку в стандарте, на котором основывалось ваше утверждение?
5. @kritzel_sw извините, да, я думаю, что вы правы. Я думал о пиксельной презентации и таких вещах, как программная копия psuedo-color IOD