В теории всё очень красиво и как бы понятно. Мол, если охвата колориметра не хватает, то мы подмешиваем немного «белого» к тестовому стимулу, а после уравнивания вычитаем — и так получаются отрицательные координаты. Но то в теории. А что с этим безобразием делать на практике?
Наверняка все сталкивались со случаями, когда фотоэлектрический колориметр (не являющийся, конечно, визуальным колориметром) возвращает отрицательные XYZ-координаты. Спрашивается, как такое происходит? Ведь стимулы XYZ специально были подобраны, чтобы полностью охватывать HVS, то есть никогда не давать отрицательных величин. Чисто по-человечески понятно, что сие есть результат ухода нуля датчика ниже того значения, что было зафиксировано при калибровке прибора. Но это аппаратная проблема, низкоуровневая. Зачем эти «бракованные» значения возвращать пользователю? Какой в них смысл?
Мне приходит на ум только один способ утилизации подобных результатов — многократное усреднение в надежде на то, что там где был минус, появится плюс, и они друг друга подавят. Но в том-то и дело, что надежды оправдываются далеко не всегда. И чем выше повторяемость результатов у прибора, чем дольше время измерения, тем меньше шансов, что мы имеем дело со случайной погрешностью, которая может быть легко устранена. Напротив, иногда складывается впечатление, что погрешность очень даже системная (во всяком случае в рамках текущего сеанса измерений). Причём яркость может быть заметно выше нижнего порога доверия, но вот X или Z безнадёжно застревают в минусе. В некоторых случаях спасает перемещение датчика в другую область экрана — из-за неравномерности последнего; но это предполагает интерактив с пользователем. А как же быть с чисто программной точки зрения? Какой логикой руководствуются сами производители, когда допускают появление отрицательных XYZ?
Не менее интересная ситуация с визуальными RGB-колориметрами. Тут [THREAD=16090]уже поднимался[/THREAD] этот вопрос: что делают отрицательные значения красного в референсах серии ColorChecker? Сформулированные Алексеем Шадриным соображения — это первое, что приходит в голову, учитывая теоретические предпосылки. Однако тогда так никто и не смог назвать абстрактный колориметр, в контексте которого должны применяться эти аппаратные координаты. А вот попробуйте-ка найти такой, чтобы данные совпадали с эталонными Lab-значекниями (например, для ColorCheckerSG в каталоге i1Match имеется спектральный референс, тогда как RGB-значения приведены в ProfileMaker \ Reference \ Others). Я перепробовал все типичные варианты — никаких совпадений, причём не только при переходе от RGB к Lab, но и в обратном направлении. Более того, в случае Lab→RGB не возникает никаких отрицательных значений красного — в ColorLab (LogoSync, ICM) имеем минимум нули, а то и 50–100. И по зелёной и синей координатам тоже нет соответствия, кроме весьма приблизительного подобия.
Потом, выглядит нелепо сама попытка использовать широкий охват. Ведь тот же ColorChecker (обычный на 24 патча) — сплошь скопище умеренных образцов. С какой стати городить этот огород ради двух патчей? Не говоря уже о том, что сия штука может быть использована просто как тест-карта принтера, без оглядки на физический оригинал. В таком случае, даже если принтер готов к управлению цветом, до него дойдут «обрезанные» данные, ибо системы печати популярных операционок оперируют только 8-битными беззнаковыми целыми. Да и на уровне приложения мы ничего не сможем сделать, потому что, опять же, не знаем, какое пространство тут подразумевалось. (А даже если бы и знали, принтер без режима «no color management» всё равно ожидает sRGB или Adobe RGB.)
По поводу «стандартных» пространств. Алексей, не совсем понятен тот ваш пассаж про sRGB в 1961 году. Его вроде бы «изобрели» в конце 90-х Hewlett-Packard и Microsoft, последней из которых в 1961 г. ещё и в планах не было. И уж тем более сомнительно, что sRGB было «родным» для ColorLab, если у него вообще есть «родное» пространство. Да и потом, разве на ColorLab свет клином сошёлся? Это всё-таки вспомогательная утилитка, но не «эталон», по которому можно проверять гипотезы в отношении «стандартов» и «подразумеваний».
Особняком стоит проблема с «нереальными» координатами L*a*b*, потому что тут критерии не такие простые как «положительные / отрицательные». Но раз виновник торжества не хочет касаться [THREAD=36394]этой темы[/THREAD] до следующего года, придётся смиренно ждать. Мы терпеливые.
Наверняка все сталкивались со случаями, когда фотоэлектрический колориметр (не являющийся, конечно, визуальным колориметром) возвращает отрицательные XYZ-координаты. Спрашивается, как такое происходит? Ведь стимулы XYZ специально были подобраны, чтобы полностью охватывать HVS, то есть никогда не давать отрицательных величин. Чисто по-человечески понятно, что сие есть результат ухода нуля датчика ниже того значения, что было зафиксировано при калибровке прибора. Но это аппаратная проблема, низкоуровневая. Зачем эти «бракованные» значения возвращать пользователю? Какой в них смысл?
Мне приходит на ум только один способ утилизации подобных результатов — многократное усреднение в надежде на то, что там где был минус, появится плюс, и они друг друга подавят. Но в том-то и дело, что надежды оправдываются далеко не всегда. И чем выше повторяемость результатов у прибора, чем дольше время измерения, тем меньше шансов, что мы имеем дело со случайной погрешностью, которая может быть легко устранена. Напротив, иногда складывается впечатление, что погрешность очень даже системная (во всяком случае в рамках текущего сеанса измерений). Причём яркость может быть заметно выше нижнего порога доверия, но вот X или Z безнадёжно застревают в минусе. В некоторых случаях спасает перемещение датчика в другую область экрана — из-за неравномерности последнего; но это предполагает интерактив с пользователем. А как же быть с чисто программной точки зрения? Какой логикой руководствуются сами производители, когда допускают появление отрицательных XYZ?
Не менее интересная ситуация с визуальными RGB-колориметрами. Тут [THREAD=16090]уже поднимался[/THREAD] этот вопрос: что делают отрицательные значения красного в референсах серии ColorChecker? Сформулированные Алексеем Шадриным соображения — это первое, что приходит в голову, учитывая теоретические предпосылки. Однако тогда так никто и не смог назвать абстрактный колориметр, в контексте которого должны применяться эти аппаратные координаты. А вот попробуйте-ка найти такой, чтобы данные совпадали с эталонными Lab-значекниями (например, для ColorCheckerSG в каталоге i1Match имеется спектральный референс, тогда как RGB-значения приведены в ProfileMaker \ Reference \ Others). Я перепробовал все типичные варианты — никаких совпадений, причём не только при переходе от RGB к Lab, но и в обратном направлении. Более того, в случае Lab→RGB не возникает никаких отрицательных значений красного — в ColorLab (LogoSync, ICM) имеем минимум нули, а то и 50–100. И по зелёной и синей координатам тоже нет соответствия, кроме весьма приблизительного подобия.
Потом, выглядит нелепо сама попытка использовать широкий охват. Ведь тот же ColorChecker (обычный на 24 патча) — сплошь скопище умеренных образцов. С какой стати городить этот огород ради двух патчей? Не говоря уже о том, что сия штука может быть использована просто как тест-карта принтера, без оглядки на физический оригинал. В таком случае, даже если принтер готов к управлению цветом, до него дойдут «обрезанные» данные, ибо системы печати популярных операционок оперируют только 8-битными беззнаковыми целыми. Да и на уровне приложения мы ничего не сможем сделать, потому что, опять же, не знаем, какое пространство тут подразумевалось. (А даже если бы и знали, принтер без режима «no color management» всё равно ожидает sRGB или Adobe RGB.)
По поводу «стандартных» пространств. Алексей, не совсем понятен тот ваш пассаж про sRGB в 1961 году. Его вроде бы «изобрели» в конце 90-х Hewlett-Packard и Microsoft, последней из которых в 1961 г. ещё и в планах не было. И уж тем более сомнительно, что sRGB было «родным» для ColorLab, если у него вообще есть «родное» пространство. Да и потом, разве на ColorLab свет клином сошёлся? Это всё-таки вспомогательная утилитка, но не «эталон», по которому можно проверять гипотезы в отношении «стандартов» и «подразумеваний».
Особняком стоит проблема с «нереальными» координатами L*a*b*, потому что тут критерии не такие простые как «положительные / отрицательные». Но раз виновник торжества не хочет касаться [THREAD=36394]этой темы[/THREAD] до следующего года, придётся смиренно ждать. Мы терпеливые.
