Калибровка против управления цветом

Статус
Закрыто для дальнейших ответов.

Samsonov

Участник
Топикстартер
Сообщения
886
Реакции
89

Не по теме:
У меня кризис тупости. '%)'


Никак не могу сообразить: возможно ли так калибровать монитор с достаточно широким охватом, чтобы он точно эмулировал другой произвольный монитор с меньшим охватом? Допустим, у нас есть монитор, заведомо перекрывающий sRGB, да ещё с программируемой LUT, — возможно ли привести его в такое состояние, чтобы картинка в точности соответствовала sRGB без дополнительного управления цветом на компьютере?

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

С другой стороны, не помешает ли на самом деле эта нелинейность при уравнивании базовых стимулов разной цветности? Будь всё линейно — это одно, будь цветность совпадающая — это другое, но когда ни то, ни другое — тут уже всё не так очевидно. CMS-то вон как действует: при фиксированных значениях цветового тона и, во вторую очередь, светлоты, пытается подобрать насыщенность. А в случае с калибровкой мы оперируем только r/g/bXYZ и r/g/bTRC на этапе построения LUT и лишь одними TRC на этапе использования. Если бы одного этого было достаточно, мне кажется, CMS имели бы какой-нибудь специальный упрощённый режим для мониторов, а не корячились бы с L*-C*, страдая от эффекта «blue turns purple» на дисплеях с узким охватом.

Возможно, ответ нашёлся бы после построения симуляции в Excel, но мне в голову ничего не приходит — с какой стороны подступиться? Для этого надо как минимум представить себе хотя бы в общих чертах алгоритм той самой калибровки.


Упреждая традиционный вопрос «зачем?» — чтобы понять намерения мониторов и средств калибровки. Понятно, что в большинстве случаев выбор режима «sRGB» в меню монитора просто означает «2,2/6500» (какими их себе представляют разработчики). То же касается и программных средств, причём не только в контексте параметров обычной калибровки, но и когда обещается сопряжение нескольких мониторов, и в том числе когда эталонные параметры выуживаются из готового профиля. Но тут у меня появилась одна фирменная программка специально для аппаратной калибровки монитора с широким охватом, которая смахивает на полноценную эмуляцию, включая RGB-цветность. Даром что она почти не настраивает TRC, поэтому строгих претензий к ней предъявлять нельзя. Однако интересно, возможно ли выполнить подобные обещания хотя бы чисто теоретически?
 

sabos

Участник
Сообщения
1 909
Реакции
285
Ответ: Калибровка против управления цветом

Samsonov сказал(а):
Никак не могу сообразить: возможно ли так калибровать монитор с достаточно широким охватом, чтобы он точно эмулировал другой произвольный монитор с меньшим охватом?
Произвольный - нельзя. Можно эмулировать лишь такой, primaries которого совпадают с нашим монитором (как минимум по hue).

На простом примере. Пусть некоторый монитор для сигнала (пиксела) r0g0b200 дает X0.1069Y0.0526Z0.5560. Если мы хотим этот XYZ излучить на мониторе с большим охватом, но идентичными primaries, то понадобится сигнал r0g0b179. Преобразование b200->b179 несложно сделать через LUT (или TRC). Если мы хотим этот XYZ излучить на мониторе с большим охватом, но иными primaries, то понадобится (пусть) r20g7b194. Такое преобразование потребует т.н. 3D LUT. В обычных мониторах такое преобразование отсутствует (недоступно пользователю). При этом в самой примитивной CMS такое преобразование есть - оно там называется матричное.

Samsonov сказал(а):
По идее, вроде бы можно, если принять теорию о том, что любой монитор — это визуальный колориметр, и что один колориметр всегда можно выразить в координатах другого колориметра.
Совершенно верно. Только координаты у нас - это вектор. Дабы без потерь такие координаты переносить - нужен 3D. Кроме того, не забываем, что при преобразовании возможно появление отрицательных чисел. Такую ситуацию мы называем "не хватает охвата".
 

Samsonov

Участник
Топикстартер
Сообщения
886
Реакции
89
Ответ: Калибровка против управления цветом

Да мне тоже потом так подумалось, что нельзя. Например, мы уравниваем цветность красного с помощью уровня запирания синего и зелёного — допустим, получилось. Но тогда уже цветность зелёного придётся уравнивать только за счёт запирания красного, а цветность синего — по остаточному принципу. То есть уже как минимум на уровне базовых стимулов получится разве что приблизительное уравнивание. Чего уж говорить про смесевые комбинации.

Однако! Похоже, что эта штука всё-таки работает каким-то чудом. Может, там в мониторе цифровой процессор? А почему бы и нет, собственно? Всякие «улучшайзеры», динамически обрабатывающие FullHD-картинку в реальном времени, уже никого не удивляют. Почему бы там не быть полноценному матричному конвертированию? При разрешении 1920×1200 и частоте 60 Гц имеем около 140 Мпикс/с; каждый пиксель требует трёх действий (линеаризации, умножения на матрицу и обратной гамма-коррекции), которые легко выполняются аппаратно и к тому же распараллеливаются по RGB-каналам. Сейчас, когда рядовая видеокарта обладает терафлопным потенциалом (10^12 оп/с), наш жалкий миллиард операций не выглядит такой уж фантастикой.


Я бы своим глазам не верил, но приборы показывают вроде то же самое — см. приложенный архив.

В каждом тесте измерялись оба режима — с родной цветностью (native) и с эмулируемым узким охватом (narrow); заданный диапазон яркости был одинаковым в обоих случаях. Сначала тестировался очень узкий охват: и не только по цветности, но и по яркости (1,5…60 кд/м²) — в приложенной Excel-табличке это лист emu1. Как нетрудно видеть, xy-треугольник эмулируемого охвата (оранжевый контур) действительно очень близок к заданным параметрам (светло-голубой контур). Для дополнительной проверки, в тест-карту были включены некоторые бинарные сочетания (лишь потом я догадался, что толку от именно этой проверки мало, поскольку цветность лежит аккурат на границе охвата), а также 50%- и 25%-ная заливка серым для сверки гаммы.

Примечание. Как я уже отмечал выше, гамму оно на самом деле не очень-то пытается регулировать (ибо практически не измеряет промежуточные градации), поэтому и совпадение — «плюс-минус километр»: вместо заданной величины 1,4 имеем около 1,6, вместо 1,8 — где-то 2,0. А вот небольшое несовпадение заданных и результирующих цветностей RGB и White можно объяснить тем, что калибровка выполнялась с помощью комплектного Eye-One Display 2, тогда как все перепроверки проводились исключительно в спектральном режиме с использованием Eye-One Pro. Потому-то и яркость чёрного я сразу задрал повыше, дабы разногласия в тенях были слабее.

Потом подумал, что эксперимент недостаточно чистый, так как эмулируемая цветность образует треугольник, подобный нативному и даже повёрнутый почти на тот же угол. Поэтому для второго теста была подобрана другая цветность — так чтобы красный походил на пурпурный, синий близился к голубому, а зелёный тяготел к жёлтому. Площадь xy-охвата слегка расширилась, и диапазон яркости увеличился до 1,0…100 кд/м², но зато подобие исчезло. То есть теперь уже точно нельзя сказать, что эмулируемый охват получается просто-напросто путём тупого понижения насыщенности всех каналов сразу. Результаты этого опыта представлены на листе emu2. Там же и модифицированные вспомогательные патчи, лежащие полностью внутри границы охвата, — как видно, образуемые ими фигуры «подобны» (относительно фигур собственно охвата). Нейтраль, хоть и гуляет по шкале градаций, но всё же находится довольно близко к заданной цветовой температуре.

В силу того, что говорить о гамма-приводке здесь не получается, сгенерированный фирменным калибратором профиль априори не будет валидным. К сожалению, режима Profile only в имеющемся у меня софте для гретаговских приборов не имеется, а создавать профиль в ProfileMaker тоже бессмысленно, так как он предполагает скалярную (не табличную) TRC. Тот софт, где подобная функция есть, работает только с другими приборами, показания которых не согласуются с гретаговскими. Поэтому пришлось выполнить «программную» калибровку (через LUT видеокарты) с помощью i1Match и всё того же i1d2 под одинаковые параметры — гамма 2,2, температура 5000 К (ближайшая к эмулируемой). На листе emu2c можно видеть, что линия нейтрали в эмулируемом режиме гуляет не более, чем в родном. Разброс между чёрным и белым тут значительно выше, нежели без вмешательства i1Match, потому что оный регулирует только точку белого. А вот картина охватов и вспомогательных проверочных патчей полностью аналогична той, что наблюдается в режиме без дополнительной калибровки (emu2).

Валидация emu2c-профиля с узким охватом по тест-карте TC2.83 показывает среднее отклонение 10 dE76, тогда как профиль с широким охватом даёт всего лишь 5,5 dE76. Но тут, во-первых, не надо забывать, что калибровка и валидация осуществлялись принципиально разными, пусть и родственными, приборами (может, переделаю как-нибудь, если лень не помешает). А во-вторых, если бы это была не эмуляция, а профанация, мне кажется, отклонения были бы несравнимо больше — десятки DeltaE.


Какие будут мнения? Ну да, я понимаю, что если там действительно видеопроцессор с матричным преобразованием или вовсе 3D-LUT (что сомнительно), то это уже не совсем «калибровка». Но насколько такое реально? Кто-нибудь что-нибудь слышал о планах производителей в этой области? Официальная документация на сей счёт хранит абсолютное молчание.
 

Вложения

  • gamut_emulation.rar
    106.2 КБ · Просм.: 326

Samsonov

Участник
Топикстартер
Сообщения
886
Реакции
89
Ответ: Калибровка против управления цветом

Samsonov сказал(а):
Валидация emu2c-профиля с узким охватом по тест-карте TC2.83 показывает среднее отклонение 10 dE76, тогда как профиль с широким охватом даёт всего лишь 5,5 dE76.
Мой склероз, как всегда, не позволил вовремя вспомнить о необходимости white-нормировки измеренных и предсказанных данных. После проведения этой нехитрой процедуры, валидация дала следующие результаты:
  • среднее отклонение, dE00 — 2,4 в режиме эмуляции, 1,6 с родной цветностью;
  • среднее среди 90 % лучших, dE00 — 1,5 / 1,0;
  • среднее, dE76 — 3,0 / 3,5;
  • среднее среди 10 % худших, dE76 — 11,2 / 13,1;
  • максимальное, dE76 — 12,8 / 18,5.
Полагаю, при таком раскладе можно уверенно говорить о самой настоящей эмуляции.


Не по теме:
Тут мне подсказывают, что в настройках i1Match можно выбрать не только «Native temperature», но и «Native gamma». Действительно, последнего пункта в длиннющем списке я доселе не замечал. Но, увы, это всё равно не позволяет создать профиль неприведённого по гамме монитора — значение гаммы всё равно записывается скалярное (одним числом). Так что без калибровки — никак.
 

idontbite

12 лет на форуме
Сообщения
593
Реакции
393
Ответ: Калибровка против управления цветом

Samsonov сказал(а):
Никак не могу сообразить: возможно ли так калибровать монитор с достаточно широким охватом, чтобы он точно эмулировал другой произвольный монитор с меньшим охватом? Допустим, у нас есть монитор, заведомо перекрывающий sRGB, да ещё с программируемой LUT, — возможно ли привести его в такое состояние, чтобы картинка в точности соответствовала sRGB без дополнительного управления цветом на компьютере?
Wide Color Gamut vs. sRGB – colours brought to heel
http://www.prad.de/en/monitore/specials/color-space.html
 

Samsonov

Участник
Топикстартер
Сообщения
886
Реакции
89
Ответ: Калибровка против управления цветом

idontbite сказал(а):
Простая эмуляция с помощью регулировки RGBCMY-каналов монитора по насыщенности и цветовому тону.
Это уже не калибровка в том узком смысле, что какие-либо коррекции производятся через N одномерных LUT. Тут уже имеет место некое колориметрическое преобразование — пусть даже не gamut mapping, а лишь цветокоррекция, — главное, что результирующие значения RGB рассчитываются не независимо друг от друга, а вместе, влияя друг на друга.

Даже более того. Настоящая эмуляция — по сути, процесс «дубовый»: мы просто берём и перемножаем вектор-столбец на матрицу; другими словами, всё это можно реализовать чисто аппаратно и выполнять за один такт (при очень большом желании). Напротив, 6-канальная коррекция требует сначала определить, в какую область цветового круга попадает RGB-сигнал, — здесь нужен целый ряд сравнений и логических операций, а потом ещё и собственно сама коррекция. Так что коррекция может быть даже более ресурсоёмким алгоритмом, нежели настоящая эмуляция. Другое дело, что коррекция может вестись прямо в 8-битных числах, в то время как эмуляция требует линейного сигнала и оттого минимум 12 бит. Но ещё вопрос, сколько доступных градаций (или сколько 3-мерных комбинаций) мы потеряем при 8-битной коррекции.


Кстати, я тогда при проверке, действительно ли имею дело с эмуляцией, проводил тесты «соблюдения законов Грассмана»: если серия точек (xy или u'v') образует прямую линию в исходном пространстве, то прямая должна получаться и при эмуляции. В общем случае, если нарисовать какой-нибудь контур в рамках хроматического охвата и добавить на его стороны контрольные точки, то внешний вид фигуры и принадлежность дополнительных точек должны сохраниться в эмулируемом режиме. Единственно что — яркость тестовых значений не должна быть слишком низкой, чтобы не выползли ошибки из-за неучёта чёрного. Короче, см. аттач в постинге № 3.

Вообще, не обязательно так мудрить — можно провести обычную валидацию, опять же, избегая тёмных патчей. Но в статье в качестве доказательства работоспособности метода приводится только рисунок совпадающих охватов. Да, скорее всего, столь близкое совпадение границ охвата в L*a*b* и в самом деле может свидетельствовать о достаточно точной эмуляции (с точностью до гамма-калибровки, которую на фигуре охвата никак не увидишь), но всё-таки удостовериться не помешало бы. А то проверка по 7 точкам RGBCMYW — это как-то несерьёзно.
 
Статус
Закрыто для дальнейших ответов.