Почему CIECAM02 не укладывается в логику ICC

теоретические и практические аспекты колориметрии, системы управления цветом
Ответить
Аватара пользователя
mihas
Администратор
Сообщения: 1368
Зарегистрирован: 18 авг 2004, 16:58
Откуда: Москва
Контактная информация:

Почему CIECAM02 не укладывается в логику ICC

Сообщение mihas »

Методов хроматической адаптации много хороших и разных: Bradford (используется в Фотошоп), von Kries, CAT02, CMCCAT2000, Sharp и так далее. Все названные методы объединены тем, что используют матричные уравнения 3x3 и различаются лишь тем, что используют разные коэффициенты матрицы и, соответственно, обратной матрицы. Не будем здесь обсуждать фундаментальные основы того, как были разработаны эти коэффициенты. Речь пойдет немного о другом. Кстати, не надо путать CAT02 с CIECAM02, первая безусловно является производной от второго, но CIECAM02 - это новый огромный алгоритм хроматической адаптации с управлением всеми параметрами а CAT02 - все та же традиционная матрица 3x3 на его основе, результаты вычислений по которой немного не сходятся с CIECAM02 ни при каких параметрах.
Что же заставляет нас держаться за эти матрицы 3x3, а не перейти всем вместе на такой продвинутый CIECAM02? Да просто спецификация ICC использует именно матрицу и не скоро от нее уйдет. Что же хорошего в матрице, чего не достает CIECAM02? Есть ответ и на этот вопрос. Представим обычную для ICC задачу, взять к примеру из файла данные с осветителем A, конвертнуть их в стандарт sRGB с осветителем D65 и при этом правильно представить на мониторе, откалиброванном на 8000К. То есть мы единовременно имеем три разных значения Lab, которые в каждом из трех вариантов отображаются и записываются в файл верно. Это достигается так просто, потому что все варианты общаются через Profile Connection Space (PCS), где для всех трех вариантов единомоментного представления цвета созданы равные правила: из любого пространства цвет адаптирован к D50 и в нем хранится в каждом из профилей. При этом при матричных уравнениях практически не имеет значения, сколько раз будет производиться хроматическая адаптация, 1, 2, 3 или больше. Погрешность между адаптацией напрямую из нашего файла A к иллюминанту монитора 8000K или не напрямую а через D50 PCS и D65 пространства sRGB ничтожна и происходит лишь из недостаточного количества знаков после запятой в вычисленной матрице адаптации. Погрешность составляет приблизительно в среднем для обычных офсетных красок 0.02 средняя и 0.06 максимальная delta E. То есть столь незначительные расхождения вообще никак не влияют на колориметрическую точность. Эти данные я посчитал для жесткого примера A->D65 против A->D50->D65 для всех матриц, с другими осветителями все то же, ошибка ничтожна. Таким образом в логике ICC матричные преобразования работают безошибочно. Однако с более сложным методом CIECAM02 ситуация чуть хуже, разница в хромадаптации A->D65 против A->D50->D65 составляет 0.6 средняя и 0.9 максимальная delta E для офсетных красок. А такие разночтения уже нельзя полностью игнорировать, хотя они по-прежнему достаточно малы, чтобы увидеть эти различия глазом. Таким образом, для корректного использования CIECAM02 нам лучше отказаться от логики ICC и использования PCS, упрощающего жизнь компьютеру: надо показать образец из файла с источником A на мониторе с температурой 8000К - изволь посчитать хромадаптацию от A к 8000K. Надо при этом произвести конверсию в стандарт sRGB - изволь и тут заново посчитать хромадаптацию от А к D65. Для многих задач такое расходование ресурсов компьютера будет критично, то ли дело когда матрицы перехода к PCS D50 посчитаны еще при изготовлении цветовых профилей ICC и компьютеру вообще остается только несложная операция по преобразованию из PCS по матрице из профиля к иллюминанту этого профиля, вычисления сокращаются в разы, а учитывая сложность алгоритма CIECAM02 - во многие разы. Однако, для решения научных задач, конечно, самая точная на сегодня модель хроматической адаптации человеческого зрения разумется CIECAM02 и не использовать ее потенциал не простительно. Просто надо понимать, что техника еще не догнала CIECAM02 и в общепринятую логику ICC и современного цифрового колорменеджмента он не совсем укладывается.

Если переформулировать сказанное совсем коротко то по хорошему CIECAM02 не нужен PCS D50, это первое, ICC позволяет "ключ раскодировки" записать в профиль только в виде матрицы и никак иначе, это второе, однако при этом позволяет софту при раскодировке использовать иные матрицы, что может приводить к катастрофическим цветовым ошибкам, это третье. Под кодировкой я подразумеваю хроматическую адаптацию для данных в профиле, они не хранятся в лабах с реальным иллюминантом, а закодированные в D50 по матрице. Применение иной матрицы (как например делает Фотошоп, используя лишь Брэдфорда, даже если профиль посчитан с иной матрицей) приводит к серьезной цветовой ошибке. Вы можете сами убедиться в справедливости моих слов, просто построив два тестовых профиля с иллюминантом A и хроматической адаптацией по Брэдфорду в одном варианте и CMCCAT2000 в другом. По абсолюту дельта между профилями будет зашкаливать в фотошопе до 20-30! Просто потому что фотошоп в дурной логике ICC не обязан при раскодировке данных в профиле CMCCAT2000 использовать матрицу этого профиля. То есть с одной стороны матричные уравнения должны железно защищать от математических ошибок, с другой стороны обязательное использование непременно матрицы из профиля как верного ключа раскодировки не регламентировано ICC. Поэтому PCS получается не строго регламентированным пространством общения профилей а простите, помойкой, куда каждый профиль и программа вольна передать что угодно. Пока все близко к D50 - ошибок не видно, они просто малы. Но это не значит, что ошибок нет!

Чтобы не быть голословным и для тех кому лень построить профили и убедиться - вот пожалуйста пример. Вот RGB данные в спектрах фотобумаги Fuji Gloss (нам нужны именно спектры в расчетах отраженки, чтобы безупречно применить к ним любой опорный адаптирующий иллюминант):
А вот два профиля по этим замерам посчитаны с иллюминантом A (это важно что не D50 или свет близкий к нему, на близком ошибка не столь заметна) и отличающиеся лишь хроматической адаптацией, более ничем:
В фотошопе профили будут выдавать разные лабы, просто потому, что в обоих случая он раскодирует их по Брэдфорду не взирая на то, что в одном из профилей совсем иная матрица раскодировки прописана.

Вот из профиля bradford матрица хромадаптации в теге chad:
0.8779-0.0915 0.2567
-0.1117 1.0924 0.0852
0.0502-0.0838 2.3998
А вот матрица хроматической адаптации в теге chad профиля cmccat:
0.8890-0.0885 0.2142
-0.0835 1.0731 0.0524
0.0031 0.0284 2.2296
Каждая из них безупречно и без потерь возвращает по-разному "зашифрованные" D50-данные о цвете к исходному иллюминанту A. Фотошоп же в обоих случаях использует для "расшифровки" не нужную матрицу из профиля, а свою матрицу, максимально приближенную к первой таблице (ибо алгоритм ее расчета - Bradford - один и тот же, что в фотошопе, что в любых других программах).

Другими словами, вот схема "упаковки" цвета под иллюминантом A к Profile Connection Space D50 содержимому профиля:
Illuminant A -> chad cmccat2000 -> D50 PCS
Вот схема верной безупречной распаковки из профиля:
D50 PCS -> chad cmccat2000⁻¹ -> Illuminant A
А фотошоп во всех случаях распакует по-своему профиль с любыми таблицами chad, для нашего примера:
D50 PCS -> chad bradford⁻¹ -> Illuminant A
Отсюда и ошибка с дельтой под 20-30, если мы не использовали для фотошопа профиль с матрицей хромадаптации, посчитанной исключительно по Брэдфорду.
Аватара пользователя
mihas
Администратор
Сообщения: 1368
Зарегистрирован: 18 авг 2004, 16:58
Откуда: Москва
Контактная информация:

Re: Почему CIECAM02 не укладывается в логику ICC

Сообщение mihas »

Мне задают в личку два важных вопроса по поднятой теме:
1) Как узнать из профиля по какой матрице в нем посчитана хроматическая адаптация?
2) Как узнать, что фотошоп "раскодирует" адаптированные данные именно по Брэдфорду?


Ответы есть.

1) Открываем профиль в ICC Profile Inspector. Смотрим содержимое тегов wtpt и chad. В первом белая точка профиля в адаптированном к D50 виде, во втором - матрица хромадаптации, по которой из адаптированных D50 можно получить данные о цвете под его иллюминантом. Иллюминант профиля прописан у i1P в теге view:
тег view в профиле i1Profiler содержит данные об иллюминанте профиля
тег view в профиле i1Profiler содержит данные об иллюминанте профиля
• 111.91 КБ • 5510 просмотров
Идем в спектральный калькулятор http://cielab.xyz/spectralcalc.php, вводим там любые данные в поле Input (например кнопочкой "Пример 1"), разворачиваем спойлер "Параметры хроматической адаптации", не задумываясь жмем по кнопкам "Скопировать значения XYZ" и "Ввести произвольные XYZ" (это позволит нам отключить вычисление белой точки чтобы ввести ее вручную). Вводим белую точку из тега wtpt профиля в поле Viewing Conditions White Point XYZ и в поле Capture Conditions White Point XYZ - белую точку профиля без хроматической адаптации - те самые значения из тега view отмеченные волнистой линией на скриншоте выше. Они в разной размерности в профиле - не пугаемся, приводим их все при вводе в калькулятор просто к одной размерности, не к 100 а к единице. Я в примере ввел посчитанную иначе белую точку под осветителем A но эта разница не принципиальна, можете тоже посчитать, придется попыхтеть, но все возможно. Вот собственно иллюстрация к этой несложной инструкции для тестовых профилей предыдущего поста:
сверяем матрицы спектрального калькулятора и матрицу из тега chad
сверяем матрицы спектрального калькулятора и матрицу из тега chad
• 468.63 КБ • 5481 просмотр
Выбираем в селекторе хроматическую адаптацию которую будем тестировать. После того как все ввели - жмем вычисление цвета и как только вычислится - жмем кнопку "Показать матрицу адаптации". Как только мы выберем адаптацию, совпадающую с адаптацией профиля - матрицы "кодировки" практически полностью совпадут. Смотрим их по диагонали на предмет совпадения. Так как вариантов хромадаптации в i1P не так много - перебрать 4 матрицы и определить наиболее близкую к тегу chad не сложно. Я не знаю с какой именно точностью производятся внутренние вычисления в i1P поэтому посчитать матрицу строго точно так же до 6-7 знака пока не могу, но до второго знака достаточно точно можно понять, что это именно та или иная хромадаптация. Замечу лишь для желающих добиваться высокой точности, что i1P записывает в профиль wtpt не XYZ иллюминанта, а освещенную этим иллюминантом самую белую точку профиля. Что он точно записывает в view не могу сказать, так что значение Capture Conditions White Point XYZ лучше самому рассчитать для белой точки или просто ввести туда XYZ иллюминанта, все равно будет видно, какая матрица хромадаптации ближе к записанной в профиле. Можно даже еще проще - просто заполнить иллюминантами профиля и D50 поля XYZ спектрального калькулятора, даже так видно, по какой именно матрице посчитан профиль.

2) Делаем профили-обманки. Тем более что некоторые программы вообще не плодят ошибок с иллюминантами и все считают строго под D50, как например Color Tool от Heidelberg. Берем спектральные characterization data по которым будем строить профиль с заданным иллюминантом, тащим данные в спектральный калькулятор http://cielab.xyz/spectralcalc.php, вычисляем с заданной хроматической адаптацией от этого иллюминанта к D50 лабы, строим по этим лабам в любой программе профиль со светом D50. В спектратльном калькуляторе по умолчанию адаптация производится к D50, если только специально кнопкой не ввести иной иллюминант в поле Viewing Conditions White Point XYZ. То есть лабы наши будут на самом деле не D50 а заданный иллюминант, адаптированный к D50 по известному нам алгоритму. Я сверил так профили-обманки с посчитанной в спектральном калькуляторе адаптацией Bradford и CMCCAT2000: при релативной колориметрии результат профиля-обманки Bradford совпал с профилем i1Profiler c Bradford. А профиль-обманка CMCCAT2000 с профилем i1Profiler CMCCAT2000 не совпал в фотошопе. Зато если эти данные A->CMCCAT2000->D50 раскодировать обратно в спектральном калькуляторе по схеме как D50(CMCCAT2000) -> Bradford -> A то они сходятся с фотошопом для профиля i1Profiler CMCCAT2000.

Что касается i1Profiler - разобрались. С остальными программами еще проще, Color Tool (Print Open) с хроматической адаптацией не извращается и все считает под D50, ProfileMaker 5 все считает с CAT02 (как впрочем и Measure Tool и ColorLab), MonacoProfiler считал по Брэдфорду. Его и совсем старые PM проверить не могу, так как вроде и ни к чему они мне и нету их. Думаю совсем старый PM тоже считал по Bradford.
Аватара пользователя
mihas
Администратор
Сообщения: 1368
Зарегистрирован: 18 авг 2004, 16:58
Откуда: Москва
Контактная информация:

Re: Почему CIECAM02 не укладывается в логику ICC

Сообщение mihas »

Ну вот чего бы хотелось. Нагенерить, например, уже адаптированных профилей нужной нелинейной адаптацией CIECAM02 под нужный иллюминант и все - они больше никуда не адаптируются, уже все сделали, не отдаем Фотошопу или рипу на откуп.
Ну так просто и правильно сделать ICC вовсе не предлагает. То есть обмануть мы конечно можем, посчитать с адаптацией к D50 а сказать при построении профиля, что это и есть D50. Но это две большие разницы - D50 и что-то адаптированное под D50, а в логике ICC получается - одно и то же. Потому что построить профиль принтера просто PCS D65 безо всякой адаптации мы не можем. Монитор - можем, стандарт sRGB - можем, а принтер - нет. Я не говорю, что это всегда нужно. Я про то, что если бы ICC был более продуман и разделял бы понятия D50 и то что адаптировано к D50 называл иначе - может и логика была бы иная и более продвинутая. А так половина пользователей даже понятия не имела, что Measure Tool им вообще не выдавал никогда никакого D65 а лишь все адаптированное без спроса и без извещения к D50 по CAT02, пока я не докопался.
Ну вот чем был бы плох профиль офсета со светом D65 безо всякой адаптации, если в типографии лампы D65 и стандарт sRGB имеет белую точку D65? Или профиль плакатов для фотовыставки со светом D65 под стандарт sRGB и хроматической адаптацией к лампам накаливания на выставочных стендах? Ну чем черт не шутит, пусть фотовыставка под лампами накаливания, ну чтобы было понятнее, чем просто лампы Philips 950, чтобы нагляднее были утрированные примеры. Мы могли бы без потерь поручить адаптацию от D65 к иллюминанту A по алгоритму CIECAM02 например продвинутому рипу, напрямую, из D65 фотографии в профиль принтера с иллюминантом A. Или в спектральном калькуляторе посчитали по CIECAM02 (поскольку ни один рип пока такого не умеет) профиль с иллюминантом D65 и хромадаптацией к лампе накаливания. Такой пересчет был бы колориметрически идеален - от D65 типичной фотографии к иллюминанту A принтера для фотовыставки. А что сейчас? Ну допустим мы продвинутые, посчитаем сами честные лабы и не в MT (он не умеет честные) с D65, а скажем при построении профиля профилировщику, что это D50, обманем. Значит наш умный рип адаптирует изображение от D50 к А а не от D65 к А - и это будет ошибка! Или мы иначе схитрим, сделаем в спектральном калькуляторе хромадаптацию от D65 к D50 по нашему любимому CIECAM02, построим профиль будто бы он D50. И скормим рипу. Он еще раз - второй уже - проведет хромадаптацию от D50 к A. А это будет менее точно, так как мы выяснили, что D65->A не равен D65->D50->A при использовании CIECAM02. При матричных преобразования равен, а при продвинутом CIECAM02 - нет. Иными словами - ICC не оставил нам правильного выбора для правильного использования CIECAM02 - в обоих приведенных случаях будет цветовая ошибка. Все потому, что нельзя без обмана сказать профилировщику - хочу D65 без хромадаптации и точка. Или с хромадаптацией, но не к D50. Пропиши белую точку D65 в профиль? Что сложного? Так нет. Почему-то стандарт RGB может быть так записан безо всякой адаптации и тегов chad, а профиль офсета и принтера - не может.
Вот даже специально посчитал при дефолтных Фейрчайлдовских установках параметров CIECAM02, алгоритм только что выверен с его экселом на разных иллюминантах, ошибок нет, алгоритм по сравнению с Фейрчайлдом скоростной, и я уже расхвалил автора на форуме http://forum.rudtp.ru/threads/bystryj-ciecam02.60865
Дельта между A->D65 и A->D50->D65 - 1,23 средняя и 1,7 максимальная даже на небольшом офсетном охвате в 300 тысяч всего кубических delta E.
Почему недотумканный профиль ICC с непременной PCS D50 должен красть у меня больше единицы по дельте в точности на пустом месте? Почему я не могу использовать PCS D65 или A в данном примере? Чтобы произвести одну задуманную хромадаптацию по известным правилам а не две по неизвестно каким. Нет, в случае с печатью из фотошопа известно, что sRGB ->PCS D50 будет Брэдфорд. А с рипом? Вы знаете как посчитает ваш рип sRGB ->PCS D50? Я вот пока понятия не имею! А потому и крадет, что не предполагает ничего кроме матриц 3x3 при хромадаптации, которые такой ошибки не дают. Зато дают другую. Алексей Шадрин пишет тут: http://forum.rudtp.ru/threads/matrica-s ... ost-543332 что при адаптации максимально близких друг к другу иллюминантов - это мелочи и "вопрос ни о чем". Но становится серьезным вопросом на мой взгляд, когда иллюминанты явно различаются. Также тему ошибки фотошопа при "раскодировании" адаптированных данных профиля не по матрице из профиля, а лишь только по Брэдфорду я поднимал в этой статье в Курсиве ближе к концу статьи (желтым хайлайтом отметил подзаголовок по ссылке чтобы долго не искать в длинном тексте). Но тот же пример - фотовыставка c лампами накаливания и сами фотки в sRGB. То есть опять D65 печатаем на принтер с иллюминантом A. Хотим зачем-то необычный CMCCAT2000 - ну вот такие мы упертые, вот хотим, промеряли свет, смотрели на мониторе при лампах накаливания - фотограф решил, что именно так идеально. Строим профиль в профайлере с адаптацией CMCCAT2000 для принтера. И печатаем. Что происходит? Рип по какому-то неизвестному нам пока алгоритму (скорее всего Bradford или CAT02) переводит sRGB в PCS D50 а потом по CMCCAT2000 из PCS D50 в иллюминант A. На выходе колориметрический бред, цветовая каша, не похожая ни на Bradford ни на CMCCAT2000. А у этих алгоритмов - Bradford, CAT02, CMCCAT2000 - у каждого своя логика, своя философия, нельзя просто так скрестить ежа с ужом без видимых цветовых ошибок. А ICC скрещивает запросто. А ведь задача решена ну прямо строго в логике ICC, без обманок, с PCS D50. Ну и нравится вам такая логика?

То есть мне видится идеальное колориметрически безукоризненное решение проблемы так: строим профиль нашего процесса - фотки sRGB для выставки с иллюминантом А - таким образом: задаем в спектральном калькуляторе, поскольку другой софт не умеет CIECAM02, иллюминант профиля D65 с хроматической адаптацией к иллюминанту А по CIECAM02, еще и по La обязательно оптимизируем под тусклое окружение выставки относительно высокой яркости sRGB, вычисляем эти лабы, строим профиль в чем угодно, в профайлере например. И печатаем. И все собственно. Просто и красиво и точно.
Но ICC не позволяет сделать ни того ни другого - ни построить профиль с иллюминантом D65 в PCS, ни профиль с хроматической адаптацией от белой точки D65 к иллюминанту A, хотя по науке мы именно это должны сделать: chad D65->A. ICC позволяет только к ->D50. То есть как ни обманывай ICC, а из традиционного для фоток пространства sRGB нам не удастся в один прием идеально произвести хромадаптацию к профилю печати для фотовыставки под лампами накаливания по самой продвинутой модели хромадаптации CIECAM02. Вот я и говорю - не укладывается CIECAM02 в логику ICC. И логика его хромая на обе ноги: упростить вычисления для компьютера, а на правила работы с цветом наплевать.
Ответить

Вернуться в «Колориметрия - наука о цвете: теория и практика»