Адекватность матричных профилей

[Samsonov]

В продолжение вопросов, затронутых в [THREAD=31661]топике про «2K»[/THREAD] — а именно про расхождение матричной модели монитора с реальным поведением устройства.

Вроде бы считается, что матричные профили достаточно хорошо описывают устройства отображения. То есть, хотя исходных XYZ-координат по ним не восстановить, можно сделать более-менее точное приближение по 3×3-матрице кардинальных стимулов и 3-м яркостным TRC. И пусть даже цветность xy каждого кардинала в отдельности будет оставаться на максимальном насыщении, пока не упрётся в абсолютный чёрный, считается, что переход в L*a*b* сделает разницу несущественной. То есть xy-разница будет расти по мере падения интенсивности стимулов, но зависимость a*b* от светлоты, наоборот, будет делать её всё меньше и меньше.

Но насколько это действительно так? Я попробовал прикинуть (см. Excel-таблицу в аттаче), и результат, мягко говоря, «превзошёл все ожидания». Мало того, что с падением светлоты dE только и делает, что растёт, так ещё и достигаемые ею значения — 9–20 единиц. Причём я перепроверил по разным цветовым каналам совершенно разных устройств (3 проектора DLP/LCD и 1 монитор LCD) и разными приборами (Spyder2 и i1Pro) — картина одна и та же. Правильность вычислений подтверждена ColorLab.

Пояснения к содержимому таблицы:

• 4 листа: shades_G — зелёный канал LCD-проектора с высокой яркостью белой точки (460 кд/м²), shades_B — синий канал DLP-проектора с относительно низкой яркостью (160 кд/м²), shades_R — красный канал LCD-проектора с высокой яркостью (570 кд/м²), shades_G2 — зелёный канал LCD-монитора с низкой яркостью (60 кд/м²). Таким образом, покрывается широкий диапазон входных значений. В последнем случае измерения проводились спектрофотометром Eye-One Pro, чтобы снять сомнения в точности результатов колориметра Spyder2.
• На каждом листе приведены исходные данные промеров (Real display device). По ним вычисляются координаты цветности и насыщенность; для пущей наглядности, они также изображаются на графиках в левой нижней части листа.
• Чуть правее идут вычисления матричной модели устройства (Matrix model). Иллюстрировать тут особо нечего, так как цветность всегда в одной точке, а насыщенность всегда максимальная.
• Затем всё это переводится в L*a*b* и сравнивается. По графику в осях L*-C* может показаться, что линии очень близки друг к другу. Но кривая dE* наглядно показывает, что абсолютная величина погрешности весьма и весьма недетская.

Какие будут комментарии? У меня есть только одна гипотеза: если дело не в измерительной аппаратуре, значит виноваты сами устройства. Будь у них чёрный потемнее (то есть если бы «прожекторы» лучше запирались), насыщенность действительно могла бы оставаться более высокой; впрочем, контаст DLP-проектора превышает 500:1, а всё туда же. Возможно, следовало бы проверить ЭЛТ с их ещё более высоким контрастом, но у них такие сильные зависимости между участками экрана, что трудно воспринимать пиксели и даже целые области как самостоятельные элементы. К тому же ЖК всё сильнее наступают по всем фронтам, так что вопрос адекватности матричных профилей для них вполне уместен без оглядки на ЭЛТ.

 

[BlackRed]

Ответ: Адекватность матричных профилей

LCD устройства никогда не отличались идеальной линейностью. Я для LCD мониторов, даже очень приличных, всегда строю Large профайл.

 

[sabos]

Ответ: Адекватность матричных профилей

про расхождение матричной модели монитора с реальным поведением устройства.

Поддержу ваше стремление проверять теорию практикой. Это абсолютно необходимое качество для любого исследователя.

Но увы, снова вынужден констатировать, что у нас проблема с формулировкой вопроса. В этой сумятице мыслей так и не смог понять, в чем собственно трудности.

Давайте снова произнесем базовые вещи. База первая - мы отталкиваемся от физмодели. Перед тем, как считать ошибку - оговариваем модель. Предлагаю за основу взять Грассмана (и не пытаться выдумывать свою математику).

Что есть "падение светлоты" в этих фундаментальных понятиях. Согласно принципу пропорциональности, доля любого стимула есть сумма долей его кардиналов. Это определение! Поэтому 50% "red" = 0.5Xr+0.5Yr+0.5Zr. Любое устройство цветового синтеза, подчиняющееся законам Грассмана, выполняет это условие по определению.

В тоже время мы понимаем (если мы нашли время изучить урок), что xy-координаты в таком случае должны быть неизменны. Напомню, XYZ - энергетически линейные величины, и очевидно, что по мере снижения мощности (энергии) излучения они будут падать. Для того, чтобы отвязаться от зависимости по яркости/энергии - мы вычисляем относительные величины xy. Выполняем деление X/(X+Y+Z), Y/(X+Y+Z). Полученные относительные величины xy принято называть xy-хроматическими координатами (именно xy, ибо бывают и другие хроматические координаты). Но измерения на реальном мониторе говорят о другом. xy-координаты по мере снижения мощности стягиваются в некую точку. Это ошибка науки? Или мой урок с ошибкой?

Нет. Это погрешность модели. Мы не учли паразитную засветку монитора. Даже в случае идеально закрытых прожекторов внутрь трубки проникает внешний свет, и он не полностью поглощается внутри кинескопа. Часть (небольшая) внешнего света попадает в измеритель. И, что важно, эта часть независима от прожекторов. Т.е. мы её можем учесть через Грассмановский принцип аддитивности. Стимул(XYZ)=Прожектор(XYZ)+Паразит(XYZ). Такая физмодель называется "матрицей с учетом черной точки".

Теперь выберем матаппарат для этой модели. Их несколько. Можно модифицировать модуляцию rgb, перейдя к функции вида ax+b (т.е. введя понятия r0b0g0-цвета). Порой удобнее применить shift-matrix (3x4) перехода. Но не станем углубляться в глубины векторной алгебры. Просто договоримся - у нас такая модель "с учетом черной точки". Повторим расчет и оценим ошибку модернизированной модели (см. аттач). Насколько она высока? Насколько CRT-монитор "исполняет Грассмана"?

Не по теме:
И позволю себе совет (непрошенный). Или даже просьбу. Уделите внимание терминологии. Крайне тяжело понимать собеседника с "цветностями" (фраза "цветность xy каждого кардинала в отдельности"), правильно ли я понимаю ваш термин "максимальном насыщении"? Вы имеете ввиду сигнал максимальной мощности, выдаваемый неким аппаратом? Что есть "xy-разница" во фразе "xy-разница будет расти по мере падения"? И почему она должна "расти по мере падения"? И следствие первого - оформляйте свои мысли буквами (мои студенты также этим страдают). В нашей среде не принято обмениваться потоками сознания. По этой причине анализ вашего аттача выполнить не смог. Не понимаю, что в файле есть "white", где там измерения и где вычисления по модели. Точнее, я вижу некие "Real display device" и "Matrix model" - но не вижу ни промеров, ни матриц, ни кардиналов, ни логики чисел.

 

[Samsonov]

Ответ: Адекватность матричных профилей

Уважаемый sabos! Если вы думаете, что изъясняться намёками — это очень круто, и несказанно повышает доходчивость мыслей, боюсь, у меня для вас плохие новости.

Мы понимаем, что xy-координаты должны быть неизменны. Но измерения на реальном мониторе говорят о другом: xy-координаты по мере снижения мощности стягиваются в некую точку. Это погрешность модели: мы не учли паразитную засветку монитора. Мы её можем учесть через Грассмановский принцип аддитивности: Стимул(XYZ) = Прожектор(XYZ) + Паразит(XYZ) — такая физмодель называется «матрицей с учетом черной точки».

Уже хотя бы по графикам можно было догадаться, что учёт чёрной точки там был: светлота не уходила в ноль. Другое дело, что этот учёт выполнялся неправильно, и отсюда набегала такая большая ошибка. Именно потому, что в голове вертелась мантра «xy-координаты должны быть неизменны», я взял и целиком промасштабировал каждый измеренный прожектор по яркости. Почему-то взбрело мне в голову, что мы имеем только информацию по яркости, хотя, то что в тэге bkpt хранится полноценный XYZ, я, естественно, осведомлён. Ну, вот так вот стормозил. То есть в нуле у меня получился «зелёный» чёрный, «синий» чёрный и «красный» чёрный — с яркостью чёрной точки и с теми же xy, что на максимуме. Таким образом, я сам себе противоречил.

Уж больно притупили бдительность столь малые величины: казалось бы, ну какое влияние могут оказывать значения порядка 0,5 по XYZ на фоне единиц и десятков? А вот оказывается, именно в них вся соль. Особенно, когда их вообще не учитывают — как раз тот случай, который заставляет продолжить топик.

Анализ вашего аттача выполнить не смог. Не понимаю, где там измерения и где вычисления по модели. Точнее, я вижу некие «Real display device» и «Matrix model» — но не вижу ни промеров, ни матриц, ни кардиналов, ни логики чисел.

Ну, ваша табличка — тоже не подарок.

На самом деле не обязательно так мудрёно делать, как вы, симулируя весь процесс валидации профиля по произвольной тест-карте. Для данного случая было вполне достаточно изучить поведение одного единственного прожектора — они же просто складываются. Поэтому и нет у меня никаких матриц и кардиналов. А промеры есть — не из головы же я числа придумал. К тому же, моя «однопроходная» симуляция позволяет абстрагироваться от неточности измерительного прибора и нюансов программного обеспечения. Благодаря этому, у меня в точке 255 погрешность всегда равна нулю, тогда как у вас там положительное число. И, заметьте, мои подопытные устройства даже не калиброваны — ни о какой скалярной величине «гамма-r/g/b» здесь и не требуется знать, равно как и о вытекающих отсюда заморочек с линеаризацией RGB.

Итак, в аттаче — обновлённый и исправленный расчёт. Вспомогательные поля снабжены комментариями, но, право же, они вторичны.

На базе листа shades_G2, который теперь называется shades_G20 и оставлен исключительно для истории, создано три новых модели:

• shades_G21 — правильная модель с учётом точки чёрного,
• shades_G22 — правильная модель без учёта точки чёрного,
• shades_G23 — правильная модель с учётом предполагаемой точки чёрного.

shades_G21 показывает, что чёрт действительно не так страшен, как я его сперва намалевал. Отклонение ΔE*ab едва переваливает за 2,0, и равно нулю в 0 и 255, как и положено.

shades_G22 демонстрирует поведение модели, если чёрный полагается равным нулю. Собственно говоря, а многие ли программы поступают иначе? Многие ли генераторы профилей сохраняют тэг bkpt? Уж точно не PM5 и i1Match3, даже в режиме ICCv4. Точно не MonacoOptix2 (насчёт MonacoProfiler не в курсе). Точно не Spyder2/3. Вот разве что Huey — тот да, сохраняет (это к вопросу о «кошерности» и «снобизме», кстати). Любительские программы в расчёт не берём, ибо всякий Вася Пупкин может понаписать чего угодно, но это не показатель в общемировом масштабе.

Короче, без учёта чёрного получается ещё более страшненько, чем у меня изначально в неправильной модели, — до 35 dE ближе к чёрному. Хотя, казалось бы, в области малых светлот все отклонения должны быть меньше один другого.

shades_G23 изображает ситуацию, когда информации о чёрном нет, но программа пытается действовать в соответствии с рекомендацией ICC, исходя из динамического диапазона 2,4 D (контраст 250:1). Тут уж всё зависит от того, насколько монитор соответствует этому соотношению. Например, в моём примере оно вдвое ниже — 130:1 (2,1 D), и отклонение достигает 18 dE. А вот если вписать в формулу в ячейке R3C12 число 2,085 (именно так, а не 2,120), то всё будет просто шоколадно — 1,6 dE максимум.

Так что вопрос остаётся открытым, ибо последние два сценария мне представляются наиболее распространёнными. Решает не Грассман, не ICC и тем более не Вася Пупкин — решает реальный софт, пользующийся популярностью.

 

[sabos]

Ответ: Адекватность матричных профилей

Уважаемый sabos! Если вы думаете, что изъясняться намёками — это очень круто, и несказанно повышает доходчивость мыслей

Помилуйте, какие намеки. Я отлично вижу, что вы интересуетесь прикладной стороной вопроса. И лишь показал, как решает эти вопросы наука. Надеюсь, это поможет исправить ошибки и "встретить теорию и практику".

Уже хотя бы по графикам можно было догадаться

Глядя на ваши расчеты, я смог догадаться, что ваша проблема в учете черного. Собственно, и пояснение давал исходя из этого. Но развернуто "поцепляться" не рискнул, разве можно построить нормальную критику на догадках?

я взял и целиком промасштабировал каждый измеренный прожектор по яркости.

И это я заметил. Да, вы правы, если опираться на принцип пропорциональности, то вполне можно так масштабировать. При условии, что прожектор этот принцип исполняет. Но вы не хуже меня знаете, что это бывает не всегда (не во всех цветосинтезирующих технологиях). Однако такой упрощенный подход не позволит проверить аддитивность, а для subj "Адекватность матричных профилей" это не менее важно. Кстати, с аддитивностью есть проблемы даже в CRT.

Уж больно притупили бдительность столь малые величины: казалось бы, ну какое влияние могут оказывать значения порядка 0,5

Очевидно, что если малые величины делить на малые величины - имеем немалую погрешность.

моя «однопроходная» симуляция позволяет абстрагироваться от неточности измерительного прибора

Здесь рискну еще одно напоминание - прибор также должен безукоризненно "исполнять Грассмана". Насколько точно прибор есть linear-light domain?

ни о какой скалярной величине «гамма-r/g/b» здесь и не требуется знать, равно как и о вытекающих отсюда заморочек с линеаризацией RGB.

Совершенно верно. Пока вы не станете изучать полную модель цветосинтеза, ваши упрощения вполне возможны.

Рассуждения о черной точке и погрешностях, которые при этом возникают, требуют уточнения. Дабы пояснить, почему практически никто не использует модель с учетом черной точки в RGB-синтезе (для display), почему тег bkpt так и стал использоваться в реальном софте, нужно как минимум раскрыть преобразования gamut mapping. Точнее, tone mapping (и tone clipping). Это непростой разговор. Лишь тезисами:
1. Существует понятие unreal colors. Например "L0a-30b12" (из вашего расчета Shades_G22_Y5Z5) - типичный unreal. Такие "цвета" гибнут (приводятся к норме) во время gamut mapping.
2. Некоторые программы во время display compensation учитывают ограничение динамического диапазона . Предполагая контраст дисплея на уровне 2D (1-100 кд/м2). Почему "черный" считают за 1 кд/м2?
Обычный "калибратор" не измеряет отраженную (от поверхности дисплея) компоненту. Хоть это и "малые величины", но их роль мы уже оценили.
Точка черного дисплея зависит не (с)только от внешнего освещения. Прожекторы противопоказано полностью закрывать, яркость не должна уводить черный в отсечку (clipping). С LCD подобная ситуация, только там иной подход, там не bias, там стратегии neutral or contrast.

 

[Samsonov]

Ответ: Адекватность матричных профилей

Существует понятие unreal colors. Например "L0a-30b12" из вашего расчета — типичный unreal. Такие "цвета" гибнут (приводятся к норме) во время gamut mapping.

Там не совсем такая комбинация — там L*=7. Не могу точно проверить «реальность» за неимением [THREAD=32941]HVS.icc[/THREAD], но если верить линдблюмовским картинкам для L*=10, оно вполне может оказаться в рамках фигуры.

Но проблема даже не в «реальности», а как раз в клиппинге. Ведь у начального и конечного устройства могут быть одинаковые модели охвата. Например, мы воспроизводим sRGB-картинку на мониторе. При этом профиль монитора не содержит информации о чёрном, и профиль sRGB.icc её тоже, разумеется, не содержит. С чего бы тогда взяться усечению, особенно если программа не строит никаких предположений?

Некоторые программы во время display compensation учитывают ограничение динамического диапазона, предполагая контраст дисплея на уровне 2D (1-100 кд/м2), потому что лбычный "калибратор" не измеряет отраженную (от поверхности дисплея) компоненту.

Насчёт засветки я в курсе, и даже оцениваю её несколько выше: единицы кд/м² при скромной освещённости рабочего стола (100 лк). Интересно, что программы намеренно противоречат спецификации ICC, и не без оснований. Почему же в спецификации заложено такое далёкое от реальности число? Хотя, наверное, правильнее было бы спросить, почему генераторы профилей так не уважают bkpt?

Прожекторы противопоказано полностью закрывать, яркость не должна уводить черный в отсечку.

Что мешает? Не, ну абсолютный чёрный всё равно никому не нужен, и с точки зрения математики может быть даже неудобен. Но разве кому-то могут помешать 3–4 D или даже пресловутые 6 D в мифических OLED? Вот разве что с точки зрения «прибор vs глаз» — ну так а кто сказал, что надо обязательно прислонять прибор к экрану? Давайте измерять мониторы как проекторы, на некотором удалении от экрана.

 

[sabos]

Ответ: Адекватность матричных профилей

Там не совсем такая комбинация — там L*=7.

Не хитрите . Не нужно сочинять XYZ из двух частей, "real" Y + "matrix" XZ.

Не могу точно проверить «реальность» за неимением [THREAD=32941]HVS.icc[/THREAD]

Собственно там я и пытался подсказать, что «реальность» проверяется не через HVS.icc. Способов проверки «реальности» несколько, они обычно прячутся внутри алгоритма gamut mapping. Стоит упомянуть как табличные методы (например ICC), так и аналитические (например Lab-gamut boundary). Более детально ознакомится с ними можно с помощью "библии", но если теория не интересна, то рекомендую посмотреть внутрь реализации gamut mapping какого CMM. В любом варианте вопрос непростой, это полноценная геометрия. Ключевые слова для поиска решений "indexed vertex list of the hull of the device gamut", "gamut boundary", "gamut shell", "gamut vertex and edges algorithms".

Впрочем, это я увлекся. Если ограничивать себя прикладной задачей, то можно много проще. Вывод какого sRGB на монитор (без gamut mapping) есть преобразование RGB1->PCS(XYZ)->RGB2. Нетрудно видеть, что оно легко вырождается в матричный переход RGB1->RGB2. Попробуйте свой анализ теней в такой модели. Ну и как dE? ;-).

Оба способа дадут вам ответ на вопрос "почему генераторы профилей так не уважают bkpt?". И почему программы, оборудованные display compensation, "так не уважают bkpt". Ибо пользы от этого тега в визуализации на мониторах немного. Кстати, в других ситуациях - много.

Но проблема даже не в «реальности», а как раз в клиппинге.

Вы правы. Отсечки возникают не всегда. Но часто. Например в вышеупомянутом RGB1->RGB2.

Кстати, давайте здесь разделять реальность и модель. Клиппинг (и tone mapping) в реальности отличается от модельных ситуаций.

Давайте измерять мониторы как проекторы, на некотором удалении от экрана.

Я бы перефразировал - давайте измерять черный/тени на мониторе, как для проектора. Только повторюсь, смысла в этом немного.

Что мешает?

Допуски, девиации, реальная жизнь. Даже если вы безупречно установите r0=Y0, r1=Y0.2, r2=Y0.4, то через пять минут будете иметь r1=Y0, r2=Y0 и даже r10=Y0. Т.е. отсечку.

 

[Samsonov]

Ответ: Адекватность матричных профилей

Вывод sRGB на монитор (без gamut mapping) есть преобразование RGB1->PCS(XYZ)->RGB2. Нетрудно видеть, что оно легко вырождается в матричный переход RGB1->RGB2. Попробуйте свой анализ теней в такой модели. Ну и как dE?

Охотно допускаю, что в реальности эмуляция одного монитора другим автоматически сводит к минимуму несоответствие между реальным устройством и его аналитической моделью с нулевой чёрной точкой. Поскольку здесь результат оценивают только наши глаза, то всё нормально.

Но что, если оценка выполняется не на глаз? Например, при валидации профиля монитора. Взять хоть тот же способ, описанный у Френкеля-Шадрина, — с помощью ColorLab. Как и большинство программ, ColorLab чихать хотел на тэг bkpt в профиле (от выбора CM-модуля это не зависит). Соответственно, максимальные отклонения получаются такими же, как и у меня в первом случае — 15–20 dE76 — и все они находятся в области теней, каким бы бредовым это ни казалось. Да, понятно, что именно так профиль «видят» почти все программы. Но профиль-то не виноват, что его бездарно используют.

Понятно также, что вместо ColorLab для генерации расчётных значений можно использовать Excel. Но как-то это нелогично, да и много ли народу станет так поступать?

 

[sabos]

Ответ: Адекватность матричных профилей

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

 

[Samsonov]

Ответ: Адекватность матричных профилей

[HIGHLIGHT]Примечание.[/HIGHLIGHT] Тема получила продолжение в топике «[THREAD=37682]Регулировка точки черного на дисплее[/THREAD]», начиная с постингов № [POST=421073]16[/POST]–[POST=421110]21[/POST] и затем бурно развиваясь в постингах № [POST=421244]25[/POST]–[POST=429682]60[/POST].

Резюме той дискуссии.

• ЖК-дисплеи в той или иной мере нарушают принцип аддитивности с точки зрения управляющего сигнала, то есть цветность промежуточных R/G/B-градаций отличается от цветности в максимуме.
• Это приводит к заведомой неадекватности профилей матричного типа, который применяется для мониторов в большинстве ситуаций.
• Профили табличного типа, во-первых, чисто теоретически, требуют в разы большего количества измерений для построения профиля той же точности. Во-вторых, не всякая программа умеет строить табличные профили, а даже те, что якобы умеют (например, ProfileMaker), могут выдавать фальшивку — табличный профиль на основе всё той же матричной модели.
• Под вопросом также, какова та доля погрешности, которую матричный профиль получает за счёт методологических аспектов: за счёт дрейфа характеристик экрана (особенно во время большого количества измерений), за счёт неточности измерительного прибора, за счёт грубой калибровки (ведь многие программы записывают в профиль целевое скалярное значение гаммы вместо массива точек реальной передаточной кривой), а также за счёт подгонки цветности R/G/B (видимо, в попытке компенсировать ту самую неидеальность ЖК, из-за которой весь сыр-бор).
• Не меньше вопросов вызывают сами средства проверки точности профиля, ведь даже именитые программы могут, например, игнорировать информацию о чёрной точке, что само по себе выводит их из игры. Ну и, конечно, многие профили попросту не содержат этой информации о чёрном.
• Наконец, нет ясности в вопросе, а стоит ли вообще беспокоиться? Ибо конечные приложения (графические редакторы) могут игнорировать любую информацию или даже намеренно подменять её какой-то другой информацией, чтобы имитировать более реалистичную для наблюдателя-человека картину.

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

 

[sabos]

Ответ: Адекватность матричных профилей

Хорошо копаете, коллега. Даже отгадали мою (давнюю) загадку про расчет primaries. Зачет .

 

[Samsonov]

Ответ: Адекватность матричных профилей

Как и обещал ранее, в обычный матричный профиль (с таблично-заданными передаточными характеристиками) попробовал дописать информацию о цветности промежуточных градаций. То бишь как бы результаты исходных измерений R/G/B-градиентов, но отфильтрованные от примесей соседних каналов.

Не по теме:
Причём, в отличие от стандартной яркостной TRC, мой формат рассчитан на массив произвольных, неравноудалённых друг от друга градаций. То есть если померили 24 точки, 18 из которых [почти] равноудалены, а ещё 6 добавлены по краям шкалы для повышения точности, то и сохраняем только 24 точки, а не все 256 интерполированных значений. Дело в том, что даже если существует неединичный наибольший общий делитель всех расстояний между точками, спецификация ICC почему-то предполагает только линейную интерполяцию, что при раскодировании даёт совсем уж негодный результат, коли честно следовать стандарту.

Фактически, один этот тэг способен заменить все другие, как то r/g/bXYZ, r/g/bTRC, wtpt и bkpt, кроме lumi и chad. Однако, если в профиле сохранена яркостная TRC с заметно большим числом значений, либо параметрическая TRC, то можно использовать эту информацию для интерполяционного уточнения тех моих данных.


Результат превзошёл все ожидания. Тогда как обычная модель с чисто яркостной TRC может давать погрешности, например, 5 dE76 в среднем и 10–15 максимум, усовершенствованная модель («eTRC») работает почти идеально — что-то вроде 0,02 dE76 в среднем и 0,10 максимум.

Не по теме:
Причём и это микроскопическое расхождение может быть следствием погрешности округления (увы, это имеет место даже при использовании 64-битных чисел с плавающей точкой), либо из-за экспорта-импорта формата ICC (там тоже есть свои особенности с округлением), либо ещё из-за каких-то моих мелких ошибок реализации. Ибо разница между профилями, построенными по 24 точкам на градиент и по 256 точкам, почти нулевая, а то и даже отрицательная (то есть 256-точечный профиль оказывается капельку хуже, что, разумеется, неправильно).


Осмелюсь даже предполагать, что модель eTRC годится для прогнозирования поведения устройства после калибровки с помощью LUT — путём перемещения тех же откликовых данных на новые точки (с уточнением яркости для дискретного входного сигнала). Собственно, для этого оно и создавалось — чтобы сравнивать характеристики некалиброванного дисплея с калиброванным, но без проведения самой калибровки, дабы сократить трудозатраты и не привязываться к конкретной калибровочной программе.

Но также возможно применение и для более привычных целей: сначала измеряем некалиброванный дисплей, вычисляем калибровочные значения (vcgt) для баланса белого, чёрного и приводки гаммы, а затем сохраняем профиль без повторного профилирования. Вообще-то многие программы так и поступают — выполняют калибровку и профилирование за один проход (иногда проводя мини-валидацию в самом конце) — но это же неправильно, ведь обычная модель не позволяет перерасчитать точные значения хотя бы тех же r/g/bXYZ. (Одно «но»: здесь не имеется в виду аппаратная калибровка с изменением низкоуровневых параметров самого дисплея, а также хотя бы просто изменение многобитной LUT монитора, — там такой фокус не пройдёт.)



Принципиальный вопрос возникает только относительно обратного преобразования, точнее, «прямого» (в терминологии ICC) — из пространства связи XYZ в пространство устройства RGB. Ведь точность прогноза отклика (XYZ) нужна только для валидации профиля, а в обычной жизни основной задачей профиля монитора является именно подыскивание оптимальных значений RGB для воспроизведения нужного XYZ-стимула. Эта операция не сказать чтоб тривиальна даже в случае обычной матричной модели, но всё же чётко формализована и однозначна. Когда же мы усложняем модель до практически табличной, то и сопоставление цвета, по-хорошему, требует «табличного» подхода.

Возможно даже, что конечному приложению следует динамически создавать табличную модель по тем самым «усовершенствованным матричным» данным, и уже затем применять стандартные 3-мерные алгоритмы поиска нужной R/G/B-комбинации. А может, ничего этого и не надо: может, и обычного «матричного» поиска достаточно, — ведь всё равно же отображение на экране будет происходить с реальными цветовыми характеристиками. Главное, что в профиле по-прежнему достаточно хранить небольшой набор данных, и что для построения этого профиля достаточно сделать такое же количество замеров, как и для обычного матричного, — не сотни и не тысячи.

Кто-то скажет, что вообще-то и расчёт отклика тоже перестаёт быть тривиальным действием, и что даже применение таблично-заданной TRC уже выходит за рамки простых программок и скриптов для Excel. Но, во-первых, ручные расчёты в Excel для выполнения валидации — это не более чем свидетельство недоразвитости программных средств, потому что валидацию должны выполнять готовые программы. Во-вторых, использование eTRC, наоборот, проще для конечной программы: она лишь единожды выполняет интерполяцию под нужную разрядность устройства (например, 3x256), и далее пользуется готовыми значениями — ничего не считает, а тупо заглядывает в таблицу, как видеокарта в свою LUT. Для современных компьютеров не составляет проблемы хранить в памяти 768 значений XYZ.



А теперь открою главный секрет, как получилась столь высокая точность профиля. Это была симуляция. Использовались замеры не реального колориметра, повешенного на реальный монитор, а виртуального датчика, как будто измеряющего дисплей с заданными характеристиками.

Сначала я пытался использовать реальные данные, и получалось не ахти. Убил кучу времени на ловлю ошибок в своих вычислениях, потому что было совершенно не ясно: то ли это монитор / проектор действительно себя так ведёт, то ли i1Pro / Spyder2 глючит (первый дико нестабилен, второй колориметрически неточен), то ли я где-то напортачил. Возникали бредовые ситуации, что расширенная модель оказывалась даже немного хуже (по max(dE), но не по средней ошибке), чем обычная, или даже чем профиль с подогнанной цветностью и фиксированной скалярной гаммой, не имеющей ничего общего с реальной передаточной характеристикой.
Вот поэтому и решил провести чистый эксперимент, дабы не зависеть от дрейфа дисплея и погрешности датчиков. Создал виртуальный колориметр, который изображал монитор с заданными свойствами:

• цветность R/G/B-стимулов нелинейно (но плавно) переходит от одного значения в максимуме к другому в минимуме;
• каждый R/G/B-канал имеет свою передаточную кривую: например, у одного обычная показательная гамма, у другого — sRGB, у третьего — Lstar;
• помимо того, что серый несбалансирован по всей шкале (вследствие предыдущих пунктов), ещё и цветность чёрного отличается от цветности белого.

Как видите, имеем «полный букет» неидеальностей. И результат, повторюсь, идеальный, тогда как обычная матричная модель даёт ожидаемо плохие предсказания — именно из-за хроматического отклонения.



Какие будут выводы?

• Расширенная модель, добавляющая к яркостной TRC также информацию о цветности, теоретически, позволяет очень точно описывать любой дисплей, даже с непостоянной R/G/B-цветностью на протяжении шкалы градаций. Здесь я исхожу из предположения, что в реальном устройстве отклик меняется так же плавно (не гигантсткими скачками), как и в идеальной симуляции.
• В реальности, увы, мы вынуждены иметь дело с неточными измерительными приборами. Нет смысла измерять 256 градаций, если в половине случаев прибор выдаёт меньшее значение X/Y/Z для более высокой градации и т. д. Аналогично, нельзя ожидать точности от любого профиля и от валидационной тест-карты, если измерительный прибор обладает систематической погрешностью: например, имеет нелинейный отклик датчиков или неточно имитирует колориметрические спектральные чувствительности.
• То же самое верно в отношении измеряемых объектов. Даже если датчик тратит на каждый патч всего по 1–2 секунды, на промер 256 точек по всем каналам уйдёт немало времени, за которое яркость лампы подсветки неизбежно упадёт (или будет меняться волнами, если в монитор встроен датчик для стабилизации). А если колориметр медленный, требует по 5–22 секунды на патч, то и вовсе опасно делать слишком много замеров — это всё равно как «измерять рулеткой расстояние до движущейся цели» © Фрейзер.
• Остаётся открытым вопрос об обратном вычислении — о поиске оптимальных R/G/B-значений для заданного XYZ-цвета. Это, конечно, возможно с помощью «табличного» подхода, но интереснее было бы придумать простой, «почти матричный» алгоритм. И, главное, насколько бы такой подход был бы лучше обычного «матричного» с точки зрения конечного результата — изображения на экране.

Прилагаю архив с демонстрацией. Там сам профиль (юзабельный в обычных программах; только не пытайтесь валидировать в ColorLab), и два набора тест-карт, в каждом из которых есть оригинальные «измеренные» значения и результаты предсказания по обычной модели и по усовершенствованной. Одна тест-карта содержит градиенты, по которым был построен профиль: если загрузить в ColorLab и переключиться в режим XYZ, то в трёхмерном виде хорошо заметен уход цветности, тогда как восстановленные по обычной модели значения имеют форму прямых линий. Вторая тест-карта — обычная валидационная TC2.88 для общей оценки точности.

 

[sabos]

Ответ: Адекватность матричных профилей

Sorry, пока не смогу внимательно посмотреть на eTRC, но постараюсь выкроить время as soon as possible. Лишь вспомню свои старые эксперименты с табличными профилями монитора. Такой технологией увлекалась известная (в узких кругах) компания Linocolor, они предлагали одноименное ПО, способное работать с табличными профилями и свой профилировщик ViewColor (убогонький, если честно).

Особого эффекта по сравнению с матричным профилем не обнаружил (для CRT). Делать эксперименты для LCD в те времена смысла не видел, ибо там цвет в зависимости от угла менялся катастрофически.

 

[Nikolay_Po]

Ответ: Адекватность матричных профилей

Как и обещал ранее, в обычный матричный профиль (с таблично-заданными передаточными характеристиками) попробовал дописать информацию о цветности промежуточных градаций. То бишь как бы результаты исходных измерений R/G/B-градиентов, но отфильтрованные от примесей соседних каналов.

"С таблично-заданными" имеется ввиду заданными в одномерных таблицах (TRC)?
Как можно дописать в матричный профиль информацию о "цветности промежуточных градаций? Может, вы имели ввиду не в профиль, а в данные для профилировщика? IMHO, в профиль можно записать только компенсационные кривые (gamma или shaper). "Цветность" там только в координатах wpt, bkpt, rXYZ, gXYZ и bXYZ. Как туда "допсать" какие бы то ни было "промежуточные градации"?
Да, и как "отфильтровать примеси соседних каналов? Что имелось ввиду?

Не по теме:
Причём, в отличие от стандартной яркостной TRC, мой формат рассчитан на массив произвольных, неравноудалённых друг от друга градаций. То есть если померили 24 точки, 18 из которых [почти] равноудалены, а ещё 6 добавлены по краям шкалы для повышения точности, то и сохраняем только 24 точки, а не все 256 интерполированных значений. Дело в том, что даже если существует неединичный наибольший общий делитель всех расстояний между точками, спецификация ICC почему-то предполагает только линейную интерполяцию, что при раскодировании даёт совсем уж негодный результат, коли честно следовать стандарту.

Понятно. ArgyllCMS, к примеру, делает TRC из 512 точек (режим "ультра"). Не думаю, что линейная интерполяция в таком случае приводит к заметным погрешностям.

Не по теме:
Фактически, один этот тэг способен заменить все другие, как то r/g/bXYZ, r/g/bTRC, wtpt и bkpt, кроме lumi и chad. Однако, если в профиле сохранена яркостная TRC с заметно большим числом значений, либо параметрическая TRC, то можно использовать эту информацию для интерполяционного уточнения тех моих данных.

Так и не понял, что значит "яркостная TRC"? Имеется ввиду классическая кривая "Tonal Response Curve" для каждого канала отдельно, или общая TRC для всех трёх? Как я начинаю понимать, Вы создали свой формат профиля, принципиально несовместимый с ICC и ваши кривые трёхмерны - по одной на канал, но 3D XYZ(R) при G=B=0, XYZ(G) при R=B=0 и ZYX(B) при R=G=0?

Принципиальный вопрос возникает только относительно обратного преобразования, точнее, «прямого» (в терминологии ICC) — из пространства связи XYZ в пространство устройства RGB. Ведь точность прогноза отклика (XYZ) нужна только для валидации профиля, а в обычной жизни основной задачей профиля монитора является именно подыскивание оптимальных значений RGB для воспроизведения нужного XYZ-стимула. Эта операция не сказать чтоб тривиальна даже в случае обычной матричной модели, но всё же чётко формализована и однозначна. Когда же мы усложняем модель до практически табличной, то и сопоставление цвета, по-хорошему, требует «табличного» подхода.

Интересно. Фактически, Вы разрабатываете свою модель CMS для устройств с аддитивным способом образования смесевых цветов. Да, можно согласится (если я понимаю правильно), что такая модель компактна, как матричный профиль и точна, как профиль LUT. Что ж, фундаментально. Заслуживает уважения. Однако, это большая работа алгоритмизировать обратное преобразование. Прямое, я вижу, вы реализовали. Правда, Вы не указали, как ведутся расчёты смесевых цветов? Просто складываем три тройки XYZ в прямом преобразовании и получаем результирующую XYZ? Действительно просто...

... Во-вторых, использование eTRC, наоборот, проще для конечной программы: она лишь единожды выполняет интерполяцию под нужную разрядность устройства (например, 3x256), и далее пользуется готовыми значениями — ничего не считает, а тупо заглядывает в таблицу, как видеокарта в свою LUT. Для современных компьютеров не составляет проблемы хранить в памяти 768 значений XYZ.

Всё же я так и не понял, как выполнять обратное преобразование XYZ2RGB?

А теперь открою главный секрет, как получилась столь высокая точность профиля. Это была симуляция. Использовались замеры не реального колориметра, повешенного на реальный монитор, а виртуального датчика, как будто измеряющего дисплей с заданными характеристиками.

Модель учитывала "rotary dispersion"? То есть, xy координаты "люминофора" менялись по ходу изменения его яркости Y (пространство Yxy)? О чём мы долго почти спорили...
Ага, вижу:

Создал виртуальный колориметр, который изображал монитор с заданными свойствами:

• цветность R/G/B-стимулов нелинейно (но плавно) переходит от одного значения в максимуме к другому в минимуме;
• каждый R/G/B-канал имеет свою передаточную кривую: например, у одного обычная показательная гамма, у другого — sRGB, у третьего — Lstar;
• помимо того, что серый несбалансирован по всей шкале (вследствие предыдущих пунктов), ещё и цветность чёрного отличается от цветности белого.

Как видите, имеем «полный букет» неидеальностей.

Этот пункт мне нравится: "цветность R/G/B-стимулов нелинейно (но плавно) переходит от одного значения в максимуме к другому в минимуме"! Имеестя ввиду переход от одних xy-координат в тенях к другим в светах (пространство Yxy)? Замечательно!

Расширенная модель, добавляющая к яркостной TRC также информацию о цветности, теоретически, позволяет очень точно описывать любой дисплей, даже с непостоянной R/G/B-цветностью на протяжении шкалы градаций. Здесь я исхожу из предположения, что в реальном устройстве отклик меняется так же плавно (не гигантсткими скачками), как и в идеальной симуляции.

Согласен. Ещё необходимо условие аддитивности, что каналы устройства не влияют взаимно друг на друга. Отмечу, пожалуй, что ваше слово "цветность" в контексте не является термином и приводит к недопониманию. Имеются ввиду координаты xy (пространство Yxy - простое аналитическое преобразование из XYZ)?

То же самое верно в отношении измеряемых объектов. Даже если датчик тратит на каждый патч всего по 1–2 секунды, на промер 256 точек по всем каналам уйдёт немало времени, за которое яркость лампы подсветки неизбежно упадёт (или будет меняться волнами, если в монитор встроен датчик для стабилизации). А если колориметр медленный, требует по 5–22 секунды на патч, то и вовсе опасно делать слишком много замеров — это всё равно как «измерять рулеткой расстояние до движущейся цели» © Фрейзер.

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

Пока всё.
Samsonov, спасибо за проведённую работу!
Интересно!

 

[Samsonov]

Ответ: Адекватность матричных профилей

Отгадали мою давнюю загадку про расчет primaries.

Э-э-э… Вы о чём?

Делать эксперименты для LCD в те времена смысла не видел, ибо там цвет в зависимости от угла менялся катастрофически.

Ну, в выложенном ранее файле «промеров» можно видеть, что градиенты R/G/B у симулированного дисплея имеют форму загогулины вместо прямых линий. Не знаю, насколько величина смещения превосходит реальный расклад, или насколько не дотягивает до него — трудно судить, когда имеющиеся измерительные приборы работают абы как. Тем не менее, при валидации хорошо видно, что обычная матричная модель даёт «реалистичную» ошибку 5–15 dE, тогда как усовершенствованная — 0,02–0,10 (и размер этой ошибки для eTRC-модели, похоже, не очень-то зависит от величины ухода).

«С таблично-заданными» имеется ввиду заданными в одномерных таблицах (TRC)?

Да. Только вот TRC — это любая передаточная характеристика, будь то заданная аналитически или в виде выборки значений. И то, и другое сохраняется в тэгах под названием r/g/bTRC — только тип значения этого тэга различается. Кстати, вопреки наличию специального типа для аналитически заданных TRC, почти все программы сохраняют скалярное значение гаммы в виде таблично заданной TRC — для этого есть специальное правило: если таблица содержит всего 1 значение, то это не таблица, а скалярная величина гамма-коррекции. Более того, многие конечные приложения не поддерживают по-настоящему аналитически заданные TRC, даже если там записана та же самая гамма, а не какая-либо более сложная функция.

Как можно дописать в матричный профиль информацию о «цветности промежуточных градаций»? Вы создали свой формат профиля, принципиально несовместимый с ICC?

Вот так вот и можно дописать. Кто ж нам запретит, если мы сами пишем этот профиль? Туда чего только ни пихают: например, в спецификации ICC v4.2 нет ни слова о тэге vcgt (калибровочные данные для загрузки в LUT видеокарты) или DevD/CIED (исходные данные замеров), — однако ж их пишут многие программы.

Так почему бы не добавить ещё один тэг eTRC? Разумеется, о нём никто не будет знать, и никто не будет им пользоваться, — будут считать через обычную модель, все данные для которой хранятся в обычных тэгах. Ну и что? Тэгом bkpt тоже мало кто пользуется, принимая его за нуль даже когда он есть, в том числе если пытаться валидировать профили в ColorLab, или выводить изображение в Фотошопе. И что же теперь, всем тоже выполнять неправильную валидацию?

Имеющиеся в профиле данные eTRC лишь дополняют обычную информацию. Повторюсь, если в профиле записана аналитическая TRC или таблица с большим числом элементов, чем в eTRC, то эти данные можно и нужно использовать для уточнения eTRC. Тэг eTRC — это компактный способ записать больше информации, чем в TRC даже большего размера. Например, в выложенном ранее профиле тэг eTRC, содержащий по 24 точки для каждого канала, при том что каждая точка хранит 32-битное XYZ-значение, занимает меньше места, чем суммарный размер трёх обычных TRC с 256 точками по 16 бит информации о яркости в каждой. И эти 256 точек дают ровно тот же результат, ибо получены путём интерполяции всё тех же 24-х, но те 24 точки мы не можем записать в обычную TRC, потому что они не равноудалены. А ведь eTRC ещё и несёт информацию о цветности, между прочим.

Однако компактность не была моей целью — целью был уход от 3D-LUT, которые в принципе не могут быть компактными. Согласитесь, вы не заходите иметь профиль с 512 точками по каждому из трёх направлений — максимум 12–32. А с таким подходом линейная интерполяция точно неуместна. Да и вообще, 3-мерная интерполяция — не самая очевидная штука.

ArgyllCMS, к примеру, делает TRC из 512 точек (режим «ультра»). Не думаю, что линейная интерполяция в таком случае приводит к заметным погрешностям.

А вот это я считаю большой глупостью. Потому что ни 512, ни 1024, ни даже 4096 шагов не являются «кратным» клином для устройства с 256 возможными градациями. Другими словами, если мы сохраняем таблично заданную TRC для точек 0, 1/511, 2/511, … 510/511, 511/511, то всё время промахиваемся мимо точных реальных значений 1/255, 2/255, … 254/255. Точно попасть во все 256 точек можно только при размере таблицы не менее 65536 элементов, если уж на то пошло. Это как раз тот случай, когда больше — не значит лучше: для устройства с 256 градациями необходимо ровно 256 точек.

Ваши кривые трёхмерны? То есть по одной на канал, но 3D — XYZ(R) при G=B=0, XYZ(G) при R=B=0…

Да, там хранятся XYZ-значения для каждой градации того или иного R/G/B-канала. Только это ни в коей мере нельзя назвать трёхмерной кривой — это три одномерные таблицы с трёхмерными значениями. Кстати, когда доходит до интерполяции, то эти трёхмерные значения всё равно обрабатываются как три массива со скалярными числами. И лишь когда нам надо уточнить промежуточное eTRC-значение по более точному TRC-значению, то мы вспоминаем о трёхмерной сущности: от XYZ переходим к xy (точнее, к xz), меняем яркость, и затем снова возвращаемся к XYZ.

Вообще, я сначала хотел сохранять именно xy-значения, дабы не только сократить объём информации, но и лишний раз подчеркнуть, что целью eTRC является дополнение знаний о цветности, тогда как яркость всё равно так или иначе записана в TRC. Но в формате ICC нет готовой рекомендации касательно хранения xy, поэтому я решил не плодить сущности и писать просто XYZ. Всё равно ж компактно получается, да и программе так меньше мороки. А конкретный формат хранения не суть важен — да пусть хоть u'v' или a*b*.

Как «отфильтровать примеси соседних каналов»? Что имелось ввиду?

Имелось в виду, что измеряем мы не «чистый синий», а «синий + запертый зелёный + запертый красный» — близко, но не совсем то же самое. А в профиль надо записать именно чистые цвета, чтобы в сумме они давали аккурат белый (как и получается на самом деле).

Не знаю, как вычисляют чистые R/G/B-компоненты другие программы. Мне видится только один способ: положиться на то, что дисплей таки соответствует матричной модели, и что цветность запертого канала не отличается от цветности полностью открытого. Тогда, вычтя измеренный чёрный из измеренного значения R/G/B, мы получим стимул с той же цветностью, что и у любого чистого компонента (что, конечно же, не так в реальности). После чего остаётся применить «угадывание» интенсивности R/G/B-компонент с данной цветностью, которые в сумме дают белый с измеренной цветностью. Аналогичное «угадывание» проводится и для разложения измеренного чёрного на R/G/B-компоненты, чтобы определить нижнее значение каждого eTRC-канала.

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

Фактически, вы разрабатываете свою модель CMS для устройств с [не]аддитивным способом образования смесевых цветов.

Да ну ладно уж прямо-таки «свою модель CMS». Тут всё та же матричная модель, только с уточнением цветности. Собственно, я поначалу в своей программе так и хотел назвать эту процедуру «Уточнение цветности» — то есть сначала считаем всё как обычно, а потом, по желанию, уточняем согласно дополнительным данным. Но оказалось, что проще и быстрее действовать в лоб: если в профиле есть eTRC, то интерполируем её на 256 точек и далее тупо смотрим в готовую таблицу, вместо того, чтобы что-то считать, а потом уточнять.

Как ведутся расчёты смесевых цветов? Просто складываем три трёхстимульных значения (XYZ) и получаем результат (XYZ)?

Конечно. Всё как и в обычной модели.

Однако это большая работа — алгоритмизировать обратное преобразование.

Мне это представляется той же самой задачей, что и при расчёте 3D-LUT профиля любого устройства вывода. Поэтому и говорю, что, возможно, для поиска оптимального RGB-кандидата для воспроизведения заданного XYZ-стимула необходимо использовать какие-то схожие алгоритмы. Но не исключено, что и обычное матричное вычисление в большинстве реальных случаев будет давать адекватный результат. Это, конечно, требует отдельного исследования.

Симуляция монитора учитывала rotary dispersion? То есть, xy-координаты «люминофора» менялись по ходу изменения его яркости Y? О чём мы долго спорили…

Да, модель имела именно такой характер — и не важно, чем он вызван: rotary dispersion, «фундаментальными свойствами нашей вселенной» или ещё чем. Как я уже выше написал sabos'у, мои приборы не очень-то позволяют наглядно убедиться в существовании такого эффекта, поэтому я просто решил проверить вашу гипотезу.

Ещё необходимо условие, что каналы устройства не влияют взаимно друг на друга.

Полагаю, что в ЖК этим, наверное, можно пренебречь. А то ещё давайте начнём забивать себе голову, что из-за утечек одни участки изображения могут влиять на другие и т. п. Непонятно, как мы вообще профилями ЭЛТ-мониторов пользуемся.

 

[Samsonov]

Ответ: Адекватность матричных профилей


Не по теме:
И снова вынужден отметить, что ограничение на 10'000 знаков в сообщении — это несерьёзно.



Не по теме:

Ваше слово «цветность» в контексте не является термином и приводит к недопониманию. Имеются ввиду координаты xy?

Да, в частности — xy. Вообще — любая хроматическая информация, будто u'v' или ещё что. То есть всё, кроме ахроматической информации — яркости, светлоты и т. п. Не знаю, чем вам с sabos'ом не нравится слово «цветность», — это chromaticity по-русски. То же самое, что мы изображаем на диаграмме цветности (chromaticity diagram) — это и есть то, что я называю цветностью. Абсолютно в том же самом значении, если не ошибаюсь, употребляет это слово Алексей Шадрин в переводе книги Ферчайлда.

То, что похожее слово chroma обычно обозначает насыщенность — это не ко мне претензии.

 

[sabos]

Ответ: Адекватность матричных профилей

чем вам с sabos'ом не нравится слово «цветность»

Ой, а я что, придирался? Уже и забыл. Вроде нормальное слово. Вот саму chromaticity diagram не люблю.

 

[Samsonov]

Ответ: Адекватность матричных профилей

Возникла идея по поводу обратного преобразования (из XYZ в RGB) с учётом дополнительной информации о цветности. Причём не нужно никаких «табличных» подходов — опять же делаем всё «по-матричному, с небольшим усовершенствованием».

1. Вычисляем подходящие RGB-координаты привычным матричным способом.
2. Берём цветность R/G/B в найденных координатах и заменяем ею оригинальную цветность кардинальных стимулов (ну, которые записаны в r/g/bXYZ).
3. Повторяем шаги 1–2, пока не достигнем нирваны.

Самое интересное, конечно, происходит на шаге 3, где необходимо определить критерий достаточной точности.

• Разумеется, если на какой-то итерации мы получили те же самые RGB-координаты, что и на предыдущей, то можно остановиться. А ещё бы хорошо помнить всех ранее подобранных кандидатов, дабы исключить глубокое зацикливание; либо просто ограничивать максимальное число итераций весьма скромным значением.
• В противном случае можно либо ориентироваться на достижение приемлемой DeltaE (что не всегда выполнимо), либо рассматривать тенденцию изменения этой дельты — по сравнению с одной прошлой итерацией (что может приводить к неоптимальному кандидату) или по сравнению со всеми предыдущими, чтобы после нескольких всё менее и менее удачных попыток откатиться назад к наиболее предпочительному варианту.

Но перво-наперво надо бы просто оценить, а стоит ли вообще заморачиваться — может, погрешности «чистого матричного» способа не такие уж большие, чтобы требовать итеративной подгонки. Затем провести сравнительное тестирование, что предложенный способ действительно позволяет добиться существенно лучших результатов.


Видится один недостаток по сравнению с «табличным» подходом. Тамошний gamut mapping обычно нацелен на сохранение цветового тона как наиболее важного атрибута, и потому ведётся строго в плоскости L*C*. Если же ориентироваться просто на DeltaE, то мы будем получать геометрически ближайшую точку, но не факт что визуально лучшую. Впрочем, если порядок величин окажется пренебрежимо малым, то на недостатки можно будет закрыть глаза. В конце концов, зато алгоритм получается максимально простым. Например, чем этот способ проще подгонки цветности и гаммы на этапе профилирования.

• Он одномерен. При обычной подгонке у нас три независимых величины, тогда как здесь не просто три одномерных процесса, а вовсе один процесс, двигающийся одновременно по трём измерениям.
• Он однонаправлен. Тогда как подгонка цветности, вообще говоря, может двигаться в любом направлении по плоскости, и заранее не ясно, откуда лучше начинать поиски, в предлагаемой модели итерации строго направлены на уточнение предыдущего результата.

Вопрос лишь в том, что считать достаточной точностью, и насколько исходный профиль был испорчен метрологическими огрехами (дрейф, датчик, округление).

К сожалению, у меня прямо сейчас нет времени на подобные исследования. Сам-то алгоритм прост, а вот написать обвязку для проведения сравнения качества — долгое дело, как и всякий пользовательский интерфейс.

 

[Samsonov]

Ответ: Адекватность матричных профилей

Попробовал реализовать идею из предыдущего постинга — путём итеративных приближений выполнять прямое преобразование (XYZ→RGB) при наличии дополнительной информации о цветности промежуточных R/G/B-градаций. Оказалось, что прямое преобразование, в отличие от обратного (RGB→XYZ), — та ещё задачка даже при такой вроде бы простой модели.

1. Обычно точность профиля оценивают по тому, насколько хорошо он описывает происходящее на устройстве при таком-то входном сигнале, — то есть с точки зрения обратного преобразования. Здесь, повторюсь, eTRC позволяет достичь почти идеальной точности, с отклонениями в сотые доли dE76, даже при очень причудливой зависимости цветности от интенсивности и при широком охвате.
2. Но самая главная задача профиля устройства отображения (и, в большинстве случаев, устройства вывода) — это всё-таки прямое преобразование. То есть неплохо бы оценить, насколько близок к требуемому стимулу получился итоговый синтезированный, управляющие сигналы для которого были рассчитаны по нашему профилю.

Второй пункт также касается высказанного ранее тезиса о том, что погрешность от игнорирования исходной и конечной чёрных точек всё равно в итоге сильно сглаживается, потому что реальные охваты конечны — мол, клиппинг «подрезает» ошибки.


Так вот, были построены три профиля ранее упомянутого симулированного монитора-колориметра: обычный «честный», затем он же с eTRC и наконец обычный из PM5 (с подгонкой цветности). По ним были выполнены расчёты для воспроизведения MediaWedge 3.0 CMYK для FOGRA39. Затем эти тест-карты были «отображены» на симулируемом мониторе, и результаты «замеров» подверглись сравнению с эталонными значениями FOGRA.

• обычный профиль — 8,1 / 9,0 / 15,3 / 28,2 (best 90 %, average, worst 10 %, max dE76);
• профиль с eTRC — 0,6 / 1,8 / 10,6 / 28,2;
• профиль из PM5 — 4,8 / 5,8 / 13,3 / 28,4.

Худшие значения не стоит принимать всерьёз: просто Y100 и C100 не вписываются в охват симулированного дисплея — потому-то max(dE) во всех случаях совпадает.

Казалось бы, преимущество дополнительной информации опять налицо. Но мне хотелось проверить модель без оглядки на gamut clipping, и потому параметры симуляции были изменены так, чтобы в верхней части охват напоминал Wide Gamut RGB, а затем нечто похожее было сделано и для теней. Заодно надеялся посмотреть на результат, когда из-за большого охвата и погрешности будут большими. И вот тут ждала засада. Причём, сразу скажу, это уже результаты второй серии замеров, когда исходные данные для FOGRA39 были для пущей надёжности ужаты до возможностей sRGB, и только затем пересчитаны под дисплей.

• обычный профиль — 40 / 43 / 64 / 73 (нет, я не забыл запятые);
• профиль с eTRC — 18 / 22 / 60 / 70;
• профиль из PM5 — 13 / 14 / 23 / 25.

Уже не так весело, правда? И даже чисто визуально в ColorLab видно, что «отображаемый» цвет в последнем случае очень близок к требуемому, тогда как профиль с eTRC частенько нагло врёт даже с цветностью, не говоря уже о светлоте, а обычный «честный» профиль так и вовсе выдаёт непотребщину. При этом, что интересно, ошибки расчёта по профилю с eTRC (и, насколько можно заметить, профилю из PM5) направлены в ту же сторону, что и общий фон расчётов по обычному «честному» профилю. И что самое возмутительное, профиль из PM5 умудряется давать лучшие результаты вопреки своей скалярной гамме, тогда как передаточные характеристики симулируемого дисплея являются разношёрстными функциями — sRGB-кривая, 2,2-гамма, Lstar-кривая; разница невелика, но всё-таки…


Похоже, источник проблемы находится там, где его наличие труднее всего предположить — в критерии окончания итераций. Нет, не в том критерии, который аварийно предотвращает зацикливание. Как раз-таки длинные цепочки, порой до 28 циклов, могут приводить от 30,0 dE76 (на этом результате мы бы остановились при обычной модели) к 0,5–2,0 dE. Поэтому я установил аварийный выход после 5 циклов подряд, в которых результат хуже наилучшего, а также безусловный выход после 70 циклов.

Проблема-то, похоже, как раз в обратном случае — когда циклов слишком мало. В некоторых ситуациях последующее уточнение выводит нас на те же самые RGB-координаты, которые были найдены на одном из предыдущих шагов. Так происходит, скорее всего, потому что информация в eTRC не является «истинным разложением монитора на R/G/B-компоненты» — противореча самой себе, она как раз-таки рассчитывается из того, что цветность постоянна по всей шкале (см. объяснение в постинге № 15). Главное, что после такого дальше двигаться бессмысленно — возникнет петля. Но и очевидно также, что совсем не обязательно хоть один из полученных результатов является оптимальным. Собственно, это и подтверждается успехом профиля из PM5 во втором тесте: при заведомо неблагоприятных для него условиях он обеспечил куда более точное предсказание, чем усложнённая модель.


Алгоритм, конечно, может в качестве запасного варианта проверять также обычную модель (с «подогнанными» данными, как у Gretag), но это не круто. Думаю, надо при обнаружении тупиковых ситуаций делать, как в игре pinball при застревании шарика — встряхнуть столик, то есть «рандомно» слегка скорректировать лучший из найденных RGB-кандидатов, и продолжать итерации дальше. Вопрос только в том, в какую сторону корректировать, и насколько. Ведь у нас три степени свободы, и каждая координата, согласно условию задачи, даёт очень неоднородное изменение цветности.

Какие будут идеи, господа инженеры-математики?

 

[ch_alex]

Ответ: Адекватность матричных профилей

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

Часто рассогласование может иметь несколько минимумов, и в какой попадёт метод спуска - никто заранее знать не может. Важным моментом часто бывает первичное приближение на первом шаге. Если первый шаг неудачен, то он приводит к локальному минимуму.

Например, программа FEMM для расчёта магнито-, электростатических и динамических задач использует метод Ньютона для решения матриц NxN произвольной размерности N. Например, количество узлов может превысить 100 тысяч (!!!). И в то же время за 7 итераций (на это тратится минута процессорного времени INTEL 3GHz и 500 мегабайт операционной системы) решение вычисляется с точностью 1E-8. А может считать и с удвоенной точностью. Но дольше.

ЗЫ. Пока посматриваю в "Математику для электро и радиоинженеров". Там как раз рассматриваются вопросы сходимости решения, приближённое вычисление корней n-й степени и так далее... К сожалению, привести формулы здесь я не могу - это всё равно сто переверстать математический учебник для ВУЗа.