Ошибки при обработке цвета: I. 8-битные изображения, матричные профили

Все, кто работает с цветом, догадываются, что любая операция редактирования немножко разрушает изображение за счет округления дробных результатов вычислений до целых значений. Вот например, наложили вы кривую, таким образом, что значение 1 должно стать 1.8, а 2 — 2.2. После округления, оба результата будут округлены до 2, отчего вместо двух разных цветов получатся два одинаковых.

Неявно предполагается, что отклонения от идеала при цифровом редактировании невелики и влияют только на младшие биты значений, что практически незаметно на глаз. В то же время, мне никогда не попадались количественные исследования. Да, на практике я знаю, что инструмент Levels в фотошопе полностью разрушает тени, а остальные инструменты ведут себя приличнее, но это единственное знание, накопленное за 8 лет работы с цветом.

Неточность работы всех средств редактирования затрудняет корректную постановку задачи: нет идеала с которым можно было бы сравнивать. По счастью, задачу можно корректно поставить для преобразования, которое должно быть минимально разрушающим: преобразование цветовых пространств в ситуации, когда мы не выходим за gamut.

Bruce Lindbloom подошел к проблеме вплотную и показал, что для специального синтезированного изображения со всеми возможными цветами (16 млн цветов в 8-битном RGB-изображении) цикл конверсии sRGB->LAB->sRGB оставляет только 2 млн разных цветов из исходных 16 млн.

Простые упражнения с фотошопом (прогнать картинку по циклу RGB->LAB->RGB, а потом посмотреть разницу через Image—>Calculations) показали, что разница по красному каналу достигает 24 единиц т.е. речь идет о 5 битах ошибки в 8-битном изображении.

Дальнейшие упражнения потребовали создания инструментальных средств и аккуратной постановки эксперимента.

Инструментальные средства

Потребовалось написать несколько программ:
  • Генерация тестовых изображений с нужным количеством цветов и с нужным шагом по цвету.
  • Сравнение двух файлов, идеального и результатов редактирования с построением гистограммы отклонений.
  • Подсчет числа цветов в файле, с целью сравнения с с результатами Брюса.
С использованием libtiff, это оказалось простой задачей, 15 килобайт на C и все готово. Если есть интерес, пишите и я выложу в общее пользование.

Постановка задачи и участники

Задача определяется стандартной схемой работы с изображением в пространстве LAB:
  1. входное изображение в RGB (для определенности, в sRGB);
  2. преобразуем в Lab;
  3. ....редактируем... (в моем эксперименте этого шага нет);
  4. возвращаем в sRGB;

В идеальном мире, после шагов 1,2,4 (без редактирования) изображение не должно отличаться от исходного побитово. В реальном мире я готов допустить небольшие отклонения (из общих соображений, ошибка в одном младшем бите на каждом шаге - реальность), скажем в 2-3 младших битах.

При всех цветовых преобразованиях используем Absolute Rendering intent: никакие операции сжатия gamut нам, очевидно не нужны.

Уменьшенный в 8 раз (по каждому направлению) тестовый файл выглядит так:

RGB16Million-resized8.png

В файле полного размера содержатся 224 разных цветов и столько же пикселей.

Участники

  • Adobe Photoshop CS3 (версия 10.0.1, апдейт от 17 ноября 2007). Photoshop позволяет указать модуль работы с цветом (Adobe и Microsoft на PC, Adobe и ColorSync на Mac);
  • LCMS версии 1.07, утилита tifficc в режиме повышенной точности.
  • Gretag (X-Rite) iQueue. Позволяет работать с собственной CMM (Logo) и с системной (Microsoft).
  • ColorSync Utility (Mac OS X Leopart 10.5.1)
  • Argyll CMS версии 0.7 (утилита cctiff).
Везде задавался Absolute Rendering Intent и (при наличии выбора) максимальная точность. В качестве исходного пространства файлу присваивалось sRGB (которое целиком покрывается LAB). Все преобразования делались в два этапа, сначала в LAB-файл (8 бит), потом обратно в sRGB.

Результаты и их обсуждение

Первым сошел с дистанции Argyll CMS. Артефакты, которые получились в области с B-компонентой равной 255 просто чудовищны. Все остальные участники выдали разумный по внешнему виду результат.

Для каждой точки результата была посчитана гистограмма отклонений от идеала (исходного файла), использовалась формула евклидова расстояния в RGB-пространстве. Отклонение для каждой точки:

    delta = sqrt ( ΔR2+ΔG2+ΔB2)

Сведенные в гистограмму, отклонения от идеала для разных CMS выглядят так:

cms-8bit-matrix-g22.png
Как обычно, по вертикальной оси у меня логарифмический масштаб, смотрите на оси внимательно!

Как мы видим, есть три группы участников по величине ошибки:

  • Photoshop со своей CMM и с ColorSync. Отклонения от идеала меньше всех. С другой стороны, отклонение на 20 единиц - это 4 бита ошибки, что достаточно много (хотя такие отклонения есть только для отдельных пикселов). Для десятков тысяч пикселов отклонения достигают трех бит, что в пределах ожидаемой ошибки и почти приемлемо по качеству.
  • Вторая группа: Photoshop с Microsoft CMM, lcms, ColorSync Utility. Ошибки до 5 бит. Удивление вызывает попадание в эту группу ColorSync Utility, ведь тот же engine в фотошопе показал себя отлично. Я могу придумать единственное объяснение — эту утилиту писал в Apple стажер, левой ногой и ничего не понимая в проблематике.
  • Последняя группа: iQueue с Logo CMM. Только два бита в изображении "ожидаемые", ошибка достигает 6 бит для 186 тысяч пикселов. Правда у меня далеко не последняя версия, возможно что в версии 1.40 что-то исправили, но ту версию, которая у меня, продавали в 2004-м году за безумные деньги. Справедливости ради нужно отметить, что с Microsoft CMM iQueue показывает результат на уровне второй группы качества.

Чтобы не быть голословным, приведу разницу в красном канале между исходником (идеалом) и результатом работы iQueue (Image -> Calculations -> Difference):

iqueue-red-difference.png
Как мы видим, округлялка в iQueue работает странно.

А зачем все это?

Справедливости ради: на плавных градиентах тестового изображения невооруженным глазом разница видна только для того ужаса, который делает iQueue. 4-5 бит разницы, разбросанные по всему изображению, да еще и в области высоких насыщенностей - не видны пока вы не начали редактировать картинку. Если пользоваться инструментами, повышающими контраст, а особенно - повышающими локальный контраст (Shadow/Highlight, например), то разница сразу становится более чем видимой.

То же относится и к другим сильным инструментам. В частности, картинка с цифровой камеры переводится из линейной гаммы (сенсор ЦФК линеен) в рабочее пространство с высокой гаммой, при этом все ошибки в тенях будут многократно усилены.

Выводы

Суммарно:
  1. Не все Color Management Modules одинаково полезны.
  2. Удивительно, но фотошоп оказался лучше всех. Если честно, не ожидал, предполагал что Open Source выступят, как минимум, на уровне фотошопа.
  3. Платя большие деньги специалистам по цвету (Gretag/X-Rite) вы можете получить полную фигню.
Конечно, 8 бит - не показатель, все сегодня стараются работать в 16-ти битах и постепенно движутся в сторону плавающей точки, поэтому остается анонсировать следующие серии моих экспериментов:
  • 16-битные изображения с гаммой 2.2;
  • 16-битные изображения в линейном пространстве;
  • 16-битные изображения и табличные профили;
следите за анонсами.

Comments

Очень познавательно. Спасибо огромное.

Интересно было бы увидеть результаты для Гимпа

в gimp нет поддержки cie lab

В 2.4 вроде уже есть.

Конечно, надо туда посмотреть, я наверное добавлю gimp в 16-битное исследование, все-таки 8 бит это база, которая в реальности на сегодня не очень актуальна.

Поставил Gimp, загружаю 16-битный файл, он мне пишет, что 16 бит не поддерживает, а округлит все до 8 бит.

LAB тоже не поддерживается (или я не нашел).

Это - не инструмент фотографа, пусть приходят, когда научатся.

ну ты как маленький, честное слово... 16 бит есть в cinepaint, но радости от этого факта всё равно никакой.

http://www.naked.la не смотрел?

А Lab в cinepaint есть ?

Naked Light пораздавал бету 0.1 и перестал. Кто видел, говорят что очень сыро.

неа, нету конечно.
а 0.1 опять раздают: http://www.naked.la/light/light-b01.zip

Посмотрел 0.1 и вообще ничего не понял. Где они такую траву берут ?

Интересно. lcms на текущий момент - 1.17.
http://www.littlecms.com/downloads.htm

<i>предполагал что Open Source выступят, как минимум, на уровне фотошопа.</i>

Гхм. Это всерьез сказано?

Да, конечно.

В фотошопе я был под впечатлением инструмента Levels, который есть полное и окончательное уродство. ImageMagick какой-нибудь просто на голову выше в этом месте.

А про остальные места фотошопа у меня не было мнения.

интересное исследование.
а какая будет ошибка в 8 битном изображении, если я перед преобразованиями делаю 8->16, а в конце 16->8?
насколько такой нехитрый трюк защищает от ошибок?

Я подозреваю, что фотошоп делает примерно это.

Возможно, этим и объясняется его точность. Сравнение 16-битных преобразований должно ответить на этот вопрос.

Объясняется, блин...

Пересчет (s)RGB->Lab - это формально две операции
а) пересчет в линейный XYZ
б) пересчет в нелинейный Lab

Если кто-то у себя внутре делает еще и округление до 8 бит на полдороге, то его надо убивать в младенчестве.

Зачем округление? Число изначально 8-битное, в нем и считаем . ;-)

Если это в два приема, причем на этапе линейного XYZ тоже 8 бит, то место такому CMM в мусорной корзине.

Вот оно что. А я никак не мог понять почему Shadow/Highlight так себя странно ведет... а оказывается у меня уже 5 бит 8)) Хыхыхы. Спасибо огромное за статью!

снимаю шляпу!
слежу за анонсами!!
Маргулиса с ЛАБом в топку !!! ;)
P.S. так блин тебя почитаешь и всю фотографию забросишь :)

Ну это же предварительный подход к сняряду 'CMM в floating point'.
Изучение вопроса "а есть ли проблема"

Естественно, не со всеми функциями, а только с теми, которые нужны для RAW-конвертора.

ну я шутю конечно, впрочем преобразование АRGB->LAB->АRGB с обработкой посредине (правда в 16 битах) у меня в процессе подготовки карточек присутствует.

И 16 бит тоже сведем к тому же, к чему всю остальную физику.

Я бы поостерегся так про Маргулиса И LAB говорить. Здесь чисто теоретическая математическая часть приведена о том, что идеала нет. Здесь же (а так же у нелюбимого вами Маргулиса) написано, что визуальной разницы при преобразовании нет. Более того, сам Маргулис в книжке пишет, что даже если 25 раз туда-обратно конвертнуть файл в LAB, ничего не изменится. Я уважаю мнение Алексея, я уважаю мнение Дэна, но тем не менее, не нахожу в них противоречия (один говорит про отклонения при округлении циферок, другой про визуальные отличия... между прочим, математически 2х2 тоже не четыре).

LAB - очень удобное пространство, в котором оба из указанных выше авторитетов собаку съели. Я еще в этом лох, но мне LAB очень нравится своим подходом - удобный и быстрый. Я им пользоваться буду, равно как буду слушать Маргулиса. Хотя информация Алексея тоже очень полезная, в том плане, что надо знать, какую цену платишь за качество.

Ошибку iQueue, например, просто видно визуально.

Ну а дальше все зависит от. Если мы, например, увеличиваем контраст в каком-то канале, то и ошибку тоже увеличим, она из невидимой вполне может стать видимой.

А есть ли смысл в таких изысканиях? На чем нужно печатать снимки, чтобы эти ошибки были заметны глазу?

Разница между Logo и Фотошопом будет видна на любом разумном оборудовании. Это по букве.

По духу. Конечно, 8 бит, если интересен цвет, сейчас не очень интересны. Исходники обычно 12-16 битные. Поэтому будет и второй подход к снаряду. Но все это нужно для понимания, например, откуда берутся "цифровые шумы" при обработке кадров с цифровой камеры. А они - берутся и их много.

Чтож. Тема интересная. Будем ждать продолжения. :)

В 16 битах под фотошопом у MS CMM - жопа. А у Адобовской - 7 бит ошибки, что для 16 бит всего - приемлемо.

Остальное доделаю за сегодня, я надеюсь.

Add new comment