Что же заставляет нас держаться за эти матрицы 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 (нам нужны именно спектры в расчетах отраженки, чтобы безупречно применить к ним любой опорный адаптирующий иллюминант):
Вот из профиля bradford матрица хромадаптации в теге chad:
| 0.8779 | -0.0915 | 0.2567 |
| -0.1117 | 1.0924 | 0.0852 |
| 0.0502 | -0.0838 | 2.3998 |
| 0.8890 | -0.0885 | 0.2142 |
| -0.0835 | 1.0731 | 0.0524 |
| 0.0031 | 0.0284 | 2.2296 |
Другими словами, вот схема "упаковки" цвета под иллюминантом 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, если мы не использовали для фотошопа профиль с матрицей хромадаптации, посчитанной исключительно по Брэдфорду.