Ошибки при обработке цвета: II. 16 бит, гамма 2.2, матричные профили

В предыдущей публикации были рассмотрены ошибки, которые происходят в Color Management Modules (CMM) разных систем при обработке 8-битных данных. Было показано, что такое "неразрушающее" действие как конверсия из RGB в Lab и обратно оставляет от 3-5 значащих бит от восьми.

На сегодняшний день, 8 бит неактуальны, большинство изображений производятся с большей разрядностью. Следовательно, нужно изучить и их.

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

Смена координат

Первые же эксперименты показали, что ошибки при обработке бывают очень большие, тысячи единиц (при диапазоне 65 тысяч), показывать их на линейном графике неудобно. Поэтому пришлось перейти к логарифмической координате по горизонтальной оси, а именно битовой ошибке. На удивление, в этих координатах оказался непоказательным логарифмический масштаб по вертикали.

В целях удобства, повторим график из предыдущей статьи в новых координатах:

rgb8bit-bits.png

Как мы видим, плохость Logo CMM не столь очевидна, как раньше, зато графиком пользоваться удобнее. Например, если нам интересно сколько пикселей имеет битовую ошибку 4 бита и более (т.е. отклонение больше 7 единиц), можно сравнить площади под двумя графиками от отметки 4 и до правого края. Вообще, график стал более интегральным и более интегрируемым.

16 бит

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

Начнем с изображения, занимающего полный диапазон 16-бит-на-канал файла. Для удобства сравнения, возьмем такой же файл, как и в прошлый раз: 16 млн. пикселей, 16 млн. цветов, по каждой из RGB-координат цвет пробегает значения 0..256..512....65280. Как и в прошлый раз, эксперимент состоит из следующих шагов:
  1. присвоить файлу профиль sRGB
  2. преобразовать в Lab (Absolute Rendering Intent)
  3. преобразовать обратно в sRGB
  4. сравнить исходный файл с результатом попиксельно, построив гистограмму отклонений (евклидово расстояние в RGB-пространстве).

Участники забега

  1. Adobe Photoshop CS3 10.0.1 на PC и на Mac со всеми тремя CMM (Adobe на PC и Mac, ColorSync на Mac, Microsoft на PC). Сразу хочется сказать, что Adobe CMM на PC и Mac работает практически одинаково.
  2. ColorSync Utility снята с дистанции за неумение сохранять 16-битные файлы.
  3. iQueue снята с дистанции за падения при обработке 16-битных файлов (буду пробовать еще)
  4. LCMS
  5. Argyll CMS вернулась в число участников забега т.к. на 16-битных данных артефактов преобразования цвета нет.

Результаты

Собственно, график (гистограмма отклонений):
rgb16bit-full-bits.png

В зависимости от наших предпочтений (минимизация пиковой ошибки или средней), лидерами можно назвать, на выбор:

  • Adobe CMM: максимальная ошибка составляет 7 бит (всего 4 пикселя из 16 млн), для 99.85% пикселей ошибка в пределах 5 бит). ColorSync сработала чуть хуже, выбросы для отдельных пикселей до 13 бит, но 99.7% пикселей имеют ошибку в 5 бит и менее.
  • Argyll может быть назван лидером по количеству пикселей с минимальной ошибкой. В пределах 2 бит у Argyll находятся 86% всех пикселей, а у Adobe и ColorSync - только 67%.
Для LCMS и Microsoft переход на 16 бит не увеличивает качественно точность, ошибки тоже растут примерно на 7-8 бит.

16 бит, половина диапазона

Очень часто коррекцию экспозиции (недодержки) фотографы переносят на этап редактирования изображения. Давайте посмотрим, что будет, если взять в качестве исходного файла такой, где использована только половина диапазона: опять 16 мегапикселей, опять 16 млн. цветов, но компоненты цвета лежат в диапазоне 0..32640 (256 шагов по каждой компоненте с шагом 128). Для гаммы 2.2 это соответствует фотографической недодержке примерно в 2.3 стопа.

Смотрим график:

rgb16bit-128-bits.png

В исходном файле у нас всего 15 бит данных, поэтому 13 бит ошибки нас совсем не устраивают. Microsoft и LCMS вычеркиваем, хотя MS CMM уменьшила максимальную ошибку на тот же один бит (подозреваю, что за счет того, что в исходных данных старшего бита нет, потому и дельта меньше). Из оставшихся лучше всего себя повел ColorSync: выросло количество пикселов с маленькой ошибкой (0-2). Поведение Adobe и Argyll не изменилось (хуже от этого они не стали, абсолютная ошибка такая же, а вот относительная выросла за счет особенностей исходника).

16 бит, 1/16 диапазона

Возьмем почти экстремальный случай: занято 1/16 диапазона файла (от 0 до 4080, шаг 16). На удивление, инструмент Curves позволяет растянуть диапазон на полный без видимой постеризации, а вот что будет с CMM:
rgb16bit-16-bits.png
Всего у нас 12 значащих бит, Microsoft CMM и LCMS смогли для части пикселов дать 12 бит ошибки. Смешно. Все остальные лидеры сохраняются, при этом:
  • количество больших ошибок у Argyll подросло;
  • преимущество ColorSync над Adobe тоже стало больше.

Выводы

  • Фотошоп рулит. И Adobe CMM и Colorsync дают более чем приемлемое качество для 16-битных изображений. Ошибка уменьшается вместе с диапазоном и остается в пределах полностью невидимого.
  • ColorSync под фотошопом работает несколько лучше в сложных случаях , хотя в использованной схеме эксперимента обнаружить визуальную разницу не получится. При накоплении ошибки она может проявиться.
  • Argyll вполне достойное средство для использования в собственных программах. Надо им баг репорт про 8 бит заслать.

И на закуску. Усиленная карта разницы между исходником и результатом работы Microsoft CMM для последнего случая. На всякий случай: каждая точка исходного файла имела свой цвет, градиенты по R и G везде были одинаковыми. На мой взгляд, мы видим результаты работы кусочно-линейного интерполятора.

ms-difference-d16.png

Comments

Имею размышления следующего плана:

Мысль #1: Вы неоднократно утверждаете, что "sRGB был выбран по той причине, что все цвета sRGB входят в Lab, следовательно, при абсолютной точности преобразований, вышеописанное преобразование не должно приводить к потере данных". На мой взгляд это утверждение ошибочно.

Доводы: Пространство Lab не только вмещает все пространство sRGB, но и имеет существенно больший гамут... Однако количество бит, выделенное для описания пространства цветов sRGB и Lab одинаково - 3 канала по 8 бит. Следовательно, в пространстве Lab весь гамут sRGB описывается меньшим количеством бит, чем 8*3... Кроме того, sRGB и Lab связаны друг с другом нелинейным преобразованием, которое само по себе даже при равном количестве бит на цвет и абсолютно корректных математических вычислениях легко вносит сколько-то бит погрешности...

Вывод: преобразование sRGB-Lab-sRGB даже при абсолютной точности вычислений, но фиксации результатов перевода sRGB-Lab в 8-битном пространстве, ни в коем случае не может считаться преобразованием без потерь...

Мысль #2: Наименьшие потери точности при преобразовании sRGB-Lab-sRGB вовсе не означают, что цвета будут корректнее представлены в Lab пространстве...

Пример: преобразуем L=R, a=G, b=B, R=L, a=G, b=B...
Результат: Абсолютно точно преобразование sRGB-Lab-sRGB, однако в пространстве Lab они не будут представлены хоть сколько-нибудь корректно... Как только мы делаем какую-либо работу в пространстве Lab (мы ведь не просто так в это пространство переводили), так сразу при обратном преобразовании мы получаем абсолютную потерю точности...

Мысль #3: Все сложнее, чем кажется на первый взгляд, но Ваши исследования тем ни менее весьма познавательны :)

Илья,

совершенно верно, ошибка должна быть. Давайте ее оценим:
* при идеальной точности вычислений ошибка на первом шаге должна быть не больше бита (ошибка округления). Если она больше (профиль матричный, ошибок интерполяции таблицы нет), CMM надо выкидывать
* Теперь обратное преобразование. Опять, я согласен потерять битик и еще один битик за счет усиления ошибки, внесенной на первом этапе. Итого - 3 бита за два этапа.

А вот все бОльшие ошибки округления - это либо результат округлений где-то по дороге, либо просто неверная работа CMM.

Да, я целиком и полностью согласен с тем, что "все сложнее", вся работа затеяна вообще для другого - определить размер бедствия и не нужно ли для конкретных преобразований переходить к плавающей точке. Но до этого места я еще не добрался, сначала нужно изучить более очевидные случаи.

" (хуже от этого они не стали, абсолютная ошибка такая же, а абсолютная выросла за счет особенностей исходника)."

Нутром чую, что одна из двух абсолютных -- таки "относительная"

Откуда знаешь ?

Спасибо, процесс исправления уже идет :)

мне кажется, нужно озвучить одно практически важное следствие:
если вы имеете jpg (8 bit) или raw (12-14 bit) файл с камеры. то первоначальная конвертация в 16 bit защищает от большинства проблем с потерей точности при цветовой обработке.
и наоборот, не рекомендуется делать обработку в 8 bit режиме.

По духу:
мы говорим пока исключительно о конверсии CMM, а не о "большинстве проблем".
То что я вижу в инструменте Curves наводит меня на грустные мысли, не зря многие знакомые делают крупные коррекции специальными профилями, считая что CMM engine точнее.

По букве:
если человек имеет jpeg, то разве его интересует точность ?
С raw тоже не все так просто, там же исходно гамма 1, а до этого места, равно как до табличных профилей, я еще не дошел.

ок, не буду торопить события. ждемс про raw.
интересно, а 32 бит кто-нибудь реально использует?

32 бита как внутренний формат работы - наше ближайшее будущее.

Тем более, что на современном железе оно как бы не быстрее, чем в целых числах

маргулис реабилитирован (посмертно)

Add new comment