Ответ: Регулировка точки черного на дисплее
Nikolay_Po сказал(а):
В реальных условиях для одновременного сравнения отпечатка с изображением на экране действительно может понадобиться регулировка точки чёрного, так как учесть фактор внешней засветки приборами так точно, как это делает наше зрение, очень трудно. Вопрос в том, как вносить коррекцию в профиль? Тэг bkpt обычно содержит значение координат точки, привязанное к результатам измерений прибором, а нам нужна коррекция по восприятию.
Сам по себе цветовой профиль не должен выполнять никакой «коррекции», но лишь отражать поведение устройства. Хотите учитывать засветку — отодвиньте прибор от экрана. Любые нетривиальные модели восприятия должны реализовываться софтом, ответственным за отображение конкретной картинки.
А мне вчера было откровение.
Как в том анекдоте про подстреленного лося: «Вот я всё пью и пью из ручья, а мне почему-то всё хуже и хуже». Сколько ни делаю промеров, итог почти одинаковый. Уже начал было делать далеко идущие выводы о том, что табличные профили совсем не ахти, как обратил внимание, что результаты их валидации ну очень подозрительно похожи (хотя и не всегда) на результаты матричной валидации в ColorLab, то есть априори без учёта точки чёрного. Пригляделся — и точно: чёрный по нулям.
Сначала подумал, что это ProfileMaker виноват. Мол, какие данные ему ни подсовывай, сначала всегда строит матричную модель, причём без учёта чёрного, а потом на её основании рассчитывает всю трёхмерную LUT. Но потом заглянул в профиль и увидел, что там есть и то, и другое, — и матричные данные, и табличные. Видимо, ColorLab, когда видит достаточный набор тэгов матричного профиля, больше ни на что не обращает внимания.
Так что возникает вопрос, как получить правильные предсказания по табличному профилю. Про Argyll догадываюсь, но там формат не совсем «нашенский», и, главное, шкала RGB от 0 до 100. Да и профили под него придётся все переделывать, так как он упорно не понимает ICCv4.
Параллельно встал и вопрос, как получить точный матричный профиль. Отсутствие bkpt — решаемая проблема, а вот с TRC беда. ProfileMaker и i1Match упорно сохраняют скалярное значение, даже если выбрать Native gamma. И всё бы ничего, ведь мы же только профилируем, и никто нам не мешает выполнить калибровку заблаговременно. Но в том-то и дело, что i1Match норовит обнулить LUT перед началом измерений. А при калибровке под конкретную гамму его не заставишь промерять всю шкалу: подсунутую тест-карту он использует только для профилирования, калибровку же выполняет по каким-то предварительным итеративным замерам серого. То бишь идеальной гамма-коррекции от него получить нельзя в принципе, и профиль априори будет иметь погрешности.
Можно, конечно, матричный профиль и самому сконструировать, благо дело вроде бы нехитрое. Однако не всё так просто, как кажется. Если создать профиль «по-честному», то есть непосредственно по результатам измерений, валидация показывает худший результат, чем для профиля из традиционных программ. Нет, проблема не в chad. И не в дискретизации — хроматические данные
xy в «честном профиле» сохраняются с точностью до пятого знака, тогда как у «обычных» профилей с этим делом на пару порядков хуже.
Создаётся впечатление, что стандартные профилировщики намеренно вносят какие-то корректировки. Потому что по валидации (с учётом чёрного, да и без него тоже, равно как и с подменой на валидационный замер) получается, что максимальное отклонение имеет место для чистых R/G/B-цветов с пиком на 255-й градации. И в каждом случае сильнее других «страдает» какой-нибудь один цветовой канал: например, красный или синий. Тогда как в «честном» профиле всё наоборот: наибольшие погрешности — на смесевых цветах средней светлоты. Мистика прям какая-то.
