Ошибки при обработке цвета: часть IV, линейная гамма

Это уже четвертая публикация на тему ошибок при преобразованиях цвета, мы постепенно приближаемся к реальным задачам. Список предыдущих серий: постепенно мы приближаемся к реальным задачам....

Из опыта известно, что цифровой шум в тенях чаще всего возникает при обработке данных с линейной «гаммой», а это те изображения, которые мы получаем с линейных сенсоров: цифровых камер и сканеров. Давайте посмотрим, что будет с ошибками на тестовых примерах.

Полный диапазон

Постановка задачи та же самая: изображение 4096x4096 содержащее 16 миллионов цветов, цикл обработки:
  1. присваиваем профиль BetaRGB с gamma установленной в 1.0;
  2. конвертируем в Lab;
  3. конвертируем обратно в BetaRGB-gamma1;
  4. смотрим попиксельную разницу, строим гистограмму.
Часть цветов исходного файла не влезает в охват (gamut) пространства Lab, поэтому смотрим где может быть клиппинг и эти пиксели не учитываем (подробнее написано в предыдущей публикации, там же можно взять тестовый файл и посмотреть на пример clipping mask).

Участники забега те же самые:

  • Adobe Photoshop CS3 (10.0.1) с тремя доступными CMM (Adobe, Apple, Microsoft)
  • Argyll CMS 0.7 beta 7
  • LCMS 1.17

Результат показан на гистограмме:

betargb-gamma1-full.png
Результаты довольно любопытные
  • Argyll: явный лидер. Я еще в в первом тексте ожидал, что OpenSource уделает коммерческий софт, дождался. Результат лучше и по среднему и по максимальному отклонению.
  • Adobe и Apple: результат близкий, но Adobe несколько лучше, тоже без вопросов. 3-4 бита ошибки для линейного пространства - много, но жить можно.
  • LCMS ничего выдающегося не показывал никогда, тут тоже ничем не выделяется.
  • Microsoft CMM всегда был одним из худших в моих тестах, там и остался.

12-битные данные

Линейные 12-битные данные - это то, что мы в реальной жизни имеем со средней руки сканера или с хорошей цифровой камеры (ставить 14-битные АЦП начали совсем недавно, да и смысл их неочевиден). Поэтому результат обработки таких данных особенно интересен, это часть работы RAW-конвертора.

В забеге принимают участие только трое, показавшие себя разумнее всего: Apple, Adobe, Argyll (хорошая CMM пишется с буквы А ?). Смотрим гистограмму битовых ошибок:

betargb-gamma1-12bit-log.png
Если честно, смотреть неудобно, поэтому то же самое, но в линейной шкале ошибок:
betargb-gamma1-12bit-linear.png
Результаты:
  • Argyll: 307 пикселей из 16 миллионов имеют ошибку в 1, у всех остальных ошибка нулевая;
  • Adobe: 789 тысяч пикселей с ошибкой 2, остальные с нулевой;
  • Apple: 42 килопикселя с ошибкой 3, 2.86 млн с ошибкой 2, остальные - нулевая ошибка.
Вообще, на 12-битных исходных данных ошибка в 2 единицы снижает динамический диапазон с 12 до 10 стопов, другими словами это БОЛЬШАЯ ошибка.

Выводы

Опенсорс рулит (я уже сомневался, что напишу эти слова про софт для обработки изображений). Если для преобразования данных достаточно матричного профиля, то Argyll - однозначный лидер (из того, что пробовали). В реальной жизни, конечно, чаще используются табличные... следите за анонсами.

Comments

Александр, у меня вообще по прочтению вопрос появился по методике оценки.
почему вы расчитываете отклонение в пространстве ргб. ведь эта система неравноконтрастна,
почему вы не считали отклонение при конвертировании лаб-- ргб--лаб ?

(я Алексей :)

Да, неравноконтрастна. Но пока отклонения маленькие - это неважно.

Чтобы делать Lab-RGB-Lab без клиппинга нужно очень широкое RGB-пространство, а это удаляет эксперимент от жизни.

<blockquote>Вообще, на 12-битных исходных данных ошибка в 2 единицы снижает динамический диапазон с 12 до 10 стопов, другими словами это БОЛЬШАЯ ошибка.</blockquote>

действительно ли _большая_ ? Так чтобы глазом увидеть на 8-ми битном мониторе?
Ну взять реальную (портрет, цветок, etc) картинку, как-то реально обработать в фотошопе с разными CMM , и визульно сравнить результирующие картинки.

Проблема возникает раньше, чем доходит до "фотошопа с разными CMM". Нужен raw-конвертор с разными CMM, а таких нету по-моему.

Тут вся боль в линейной гамме - шумы в тенях (от процессинга, например) будут
а) усилены при переходе в гамму 2.2
б) если картинка исходно была с большим ДД и его хочется сохранить (оставить и света и тени), то либо у нас будет local contrast (ну хоть shadow-highlight), который еще усилит шум в тенях, либо просто обратная S-кривая, которая тоже усилит.

Если проблема возникает в конверторе, то эти RGB-LAB-RGB тесты не имеют особого смысла, просто еще одна демонстрация накопления ошибки.

Фотография должна быть полностью готова на выходе из raw-конвертора, возня в фотошопе - это экстремальное спасение плохого кадра.

Вопрос номер один - с какой точностью работают конверторы - 16 bit, 32 bit или float?
Adobe Camera Raw должен использовать (по идее) тот CMM, который указан в фотошопе?

"усилит шум в тенях" ... ну вот есть у нас полезная точка (10,10,10) и рядом паразитный шум (1,1,1). После подтягивания теней они стали (20,20,20) и (2,2,2). Шум стал более виден, но соотношение сигнал/шум осталось тем же?

По порядку.
1) Это же не единственный тест. Для gamma 2.2 конверсия RGB-Lab-(editing)-RGB имеет очевидный смысл.
Для gamma 1 - естественно нормальная ситуация это RGB(g1)-Lab (как PCS) -> RGB (gamma 2.2), но так не получается сравнить исходник и результат.

2)Было бы странным ожидать от конвертора всех возможностей фотошопа, например операций с масками с использованием в качестве маски канала K. Проще относиться к конвертору как к проявке.

3) Конверторы используют разное. У ACR, как я понимаю, свои профили. C1 использует какой-то обычный CMM. В плавучке работают из известных мне только RPP и RMLite.

4) Шум. Вот у тебя был сигнал, скажем 2,3,4 у трех разных пикселей (разница на стоп в линейном пространстве). После конверсии должно стать 10,12,14 (для простоты, gamma 2), а стало например 12,13,14 (цифровой шум +2, +1, +0). Из стопа стало полстопа.
А "усилит шум в тенях" какой-то тул с local contrast, тот же S/H