Ошибки при обработке цвета: 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 раз (по каждому направлению) тестовый файл выглядит так:

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

Участники

• 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 ( ΔR²+ΔG²+ΔB²)

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

Как обычно, по вертикальной оси у меня логарифмический масштаб, смотрите на оси внимательно!

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

• 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 работает странно.

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

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

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

Выводы

Суммарно:

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

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

• 16-битные изображения с гаммой 2.2;
• 16-битные изображения в линейном пространстве;
• 16-битные изображения и табличные профили;

следите за анонсами.