Некорректные цвета CIELAB при крайних L

[ENVdovin]

Нарисуем 2 серых пикселя в модели Lab: L=20 и L=80, уменьшим картинку до 1 пикселя, получим L=50. Проделаем то же самое в модели RGB - получим пиксел L=52. Фотошоп не может даже проделать простого масштабирования правильно в формате RGB - перевирает цвета.

Пример, мягко говоря, не уместный. Когда мы работаем в режиме LAB, все операции считаются в режиме LAB, в том числе, масштабирование, поэтому, в этом случае для L будет ПРАВИЛЬНОЕ значение 50, но при этом для R,G,B будет НЕПРАВИЛЬНОЕ значение 118. Когда мы работаем в режиме RGB, все операции считаются в режиме RGB, поэтому, L будет иметь НЕПРАВИЛЬНОЕ значение 53, но зато ПРАВИЛЬНОЕ значение R=G=B=124. Так что, Photoshop здесь все делает правильно. (Небольшая разница в значениях обусловлена выбранным методом децимации)

Что касается L=0 и L=100 при высокой хроме. Разумеется цвет 100:100:100 существует - засвети в глаз красным фонарем - ощущуения будут именно такими. А вот 0:100:100 не существует, тем не менее цифры такие Lab ввести позволяет но их невозможно увидеть, их нет, наложим на лаб фигуру HVS и увидим, какие цвета есть а какие за пределом цветовой модели.

Тут пора определиться, что такое цветовое пространство, и что такое цветовой охват. Теоретически в пространстве LAB существуют точки с любыми координатами. Никто не спорит, что цвет 100:100:100 видим человеком, а 0:100:100 невидим, тем не менее в пространстве они есть. Одного из них (второго) нет в цветовом охвате HVS. Их обоих нет в цветовом охвате sRGB. Причем, когда я писал о "цветовом теле CIELAB", я приравнивал это понятие к цветовому охвату sRGB внутри пространства CIELAB.

 

[_MBK_]

На самом деле, любое цветовое пространство - не более, чем математическая абстракция, сферический конь в вакууме. Причем, все так или иначе привязаны к человеческому цветовосприятию глаза - отсюда их трехмерность. Реальная цветовая модель должна быть бесконечномерной (надеюсь, понятно, почему?)
Поэтому, существование реального цвета, отвечающего за конкретную точку в каком-либо пространстве - это спор об ангелах на кончике иглы. Точка любого цветового пространства, какой бы широкий охват у него не был - не более, чем проекция реального цвета на некий набор допущений. Проецируется точка (0:100:100) на не черный цвет? Надо не возмущаться этим фактом, а принять его как данность - да, существующий алгоритм построения цветовой модели Lab ставит эту точку подобным образом. Если б ставил по другому, то это была бы другая цветовая модель. Кстати, модели Lab и так, как минимум, две разные.

 

[ENVdovin]

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

Как трехмерность цветового пространства связана с цветовосприятем глаза - в силу трихроматического зрения или в силу того, что мы воспринимаем наше пространство трехмерным? Да и не все цветовые пространства трехмерны, есть и двухмерные (при дихроматическом зрении например) есть и одномерные и многомерные - те же grayscale и CMYK или multichannel в Photoshop. Да, согласен, что все это лишь идеализированные модели, каждая из которых с определенной долей успеха аппроксимирует человеческое цветовосприятие. Тут можно много философсововать.
А почему реальная цветовая модель должна быть бесконечномерной (извиняюсь за невежество)?

 

[_MBK_]

У цветных моделей базовых координат все таки три. Это связано с количеством чувствиткльных клеток на сетчатке. Цветоразностные модели сохраняют трехмерность для удобства алгебраических преобразований чтобы количество уравнений совпадало с количеством неизвестных. Кстати, причина кажущейся трехмерности окружающего мира столь же банальна - строение косточек вестибулярного аппарата. Реальное представление цвета ьесконечномерно потому что любую волну можно разложить (кажись через Фурье) на бесконечное число гармоник.

 

[ENVdovin]

А, теперь я понял, что Вы имеете в виду только аддитивные/субтрактивные модели, такие как RGB и CMYK, но не перцепционные, такие как LAB (т.е. базируетесь-таки на трихроматическом цветовосприятии человека). Тогда согласен, для бесконечномернохроматического человека (супергерой вроде супермена) пространство стоило бы делать бесконечномерным. А для обычных людей, хоть частот вокруг и бесконечное множество, рецепторов все-таки три.

 

[ENVdovin]

Хотя перцепционные модели тоже имеют три составляющие - яркость, оттенок, насыщенность. Тут я согласен, некая "троица" обычно присутствует.

 

[_MBK_]

Тут я согласен, некая "троица" обычно присутствует.

Еще раз повторюсь - количество базовых составляющих цвета в восприятии человека - три. Соответственно, все производные цветовые модели тоже имеют такую же размерность. Дополнительный канал в CMYK введен искусственно и относится, скорее, к технологии воспроизведения, чем к цветовосприятию.
А по поводу супермена - внимательно перечитайте мой исходный пост. Я имел в виду реальное представление цвета. А не ого упрощенную проекцию на трихроматическое восприятие. К примеру, цвет, который мы воспринимаем как красный, может на самом деле быть представлен бесконечным множеством совершенно различных цветов разной структуры.

 

[mihas]

Когда мы работаем в режиме RGB, все операции считаются в режиме RGB, Так что, Photoshop здесь все делает правильно.

К счастью, не все операции для файлов в режиме RGB фотошоп выполняет с каналами RGB. Chroma и hue он честно поправляет, пересчитывая цвет в LCh и потом обратно в RGB. А операцию масштабирования он делает направильно по цвету, просто не учитывает, что RGB как правило еще имеет гамму, отличную от единицы. Нельзя так вычислять среднее в RGB не учитывая гаммы, тем не менее фотошоп это делает к сожалению. Lab - это цвет, RGB - это не цвет. Если цифры Lab неправильные, то операция масштабирования по цвету выполнена некорректно. Некоторые дизайнеры интуитивно это чувствуют и поправляют контраст изображения RGB после его уменьшения.

 

[ENVdovin]

Нельзя так вычислять среднее в RGB не учитывая гаммы, тем не менее фотошоп это делает к сожалению. Lab - это цвет, RGB - это не цвет. Если цифры Lab неправильные, то операция масштабирования по цвету выполнена некорректно. Некоторые дизайнеры интуитивно это чувствуют и поправляют контраст изображения RGB после его уменьшения.

Очень интересно, никогда не задумывался над этим. Беру свои слова обратно, фотошопу есть, куда расти. Опцию "Blend RGB Colors Using Gamma" сделали, но с масштабированием она не работает.
Однако, мне не ясно, как можно поправить контраст изображения уже после его уменьшения? Ведь некорректные цвета будут встречаться неравномерно по всему изображению, т.е. некоторые пиксели (их будет немало) будут посчитаны правильно (например, те, которые сложились из пикселей одного цвета). Но, что более важно, RGB-значения одного "правильного" и другого "неправильного" пикселя могут быть одинаковыми, значит последующее редактирование уровней не имеет смысла. Так?

 

[mihas]

Так. Попытка поправки - неосознанная и интуитивная. Вооруженный знанием дизайнер что же на самом деле не так - перейдет в лаб при уменьшении. Или дождется того фотошопа, который древнюю смешную ошибку все же исправит.

 

[_MBK_]

древнюю смешную ошибку все же исправит.

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

 

[ENVdovin]

Внимательно изучил программный код реализации преобразования LAB->XYZ->RGB, соответствующий используемому в Photoshop, и выяснил, что клиппинг происходит на самой последней стадии уже в пространстве RGB. Т.е., если значения RGB вываливаются за пределы [0..1], то они соответственно обрезаются. На сколько я понимаю, это не соответствует никакому линейному преобразованию в пространстве LAB, и никакому определенному типу gamut mapping. Другими словами, никакого gamut mapping не применяется (по крайней мере, ничего похожего на то, что я рисовал на иллюстрации). Получается, Photoshop еще раз оказался глупее, чем мы о нем думали?

Я также пробовал в Photoshop переводить такие цвета из LAB в sRGB путем преобразования профиля, но ни один из методов rendering intent (перцепционный / насыщенность / относительный / абсолютный колометрический) не дал какого-либо иного результата. Это уже кажется мне странным.

 

[_MBK_]

выяснил, что клиппинг происходит на самой последней стадии уже в пространстве RGB.

Вообще-то, это именно то, о чем я вам говорил еще в сообщении №4

Возможно. Там двойное преобразование Lab->XYZ->RGB
На этапе XYZ->RGB похоже, они и обрезаются.

Я, конечно, понимаю, что все надо проверить самому, но ведь это совершенно очевидная вещь.

по крайней мере, ничего похожего на то, что я рисовал на иллюстрации

Разумеется, и об этом я вам тоже говорил:

Вы ж не прообраз пространства RGB в область допустимых значений Lab рассматриваете , а прообраз RGB в XYZ. А там картина несколько другая получается и образы осей L, a и b направлены весьма причудливым образом.

Получается, Photoshop еще раз оказался глупее, чем мы о нем думали?

На самом деле, фотошоп тут не при чем, повторяю, это теория такая и алгоритмы соответствующие. Если вам что-то не нравится - создайте более совершенную теоретическую модель представления цветов, которая отвечала бы вашим требованиям. Вот вы все время говорите какой фотошоп тупой, а ведь вам самому понадобился без малого месяц, чтобы понять основополагающие вещи, которые, при том, вам объясняли три человека.

 

[ENVdovin]

Каюсь. Признаться, не мог поверить, что все происходит так просто. Но в фотошопе, все-таки люди характерной специфики работают. Я коснулся данного вопроса, имея мало опыта в теории цвета. Просто думал взяться писать программу, реализующую то, с чем я тут месяц к Вам пристаю. А идея-то простая: редактор уровней яркости, более-менее соответствующей человеческому восприятию, но без пресловутых «недосвеченных насыщенных остатков», которые, как мы выяснили, неизбежны при стандартном подходе к преобразованию пространств.

Вернусь к делу, пока не передумал. Выход я пока вижу такой – корректировать координаты LAB еще до преобразования LAB->XYZ->RGB, т.е. «втискивать» цвета, вышедшие из гамута sRGB, в этот гамут. Для этого, скорее всего, понадобится переходить в LCh и «подбирать» максимально возможную хрому (лежащую в гамуте RGB) при неизменных светлоте и оттенке. По какой формуле это делать я пока не знаю. Не подскажете?

Вообще-то этим должны заниматься системы CMS. Однако, как я уже написал выше, мне не удалось получить иных результатов через преобразование профилей внутрифотошоповскими модулями Adobe ACE и Microsoft ICM. Не разъясните мне этот момент?

 

[_MBK_]

Я коснулся данного вопроса, имея мало опыта в теории цвета. Просто думал взяться писать программу

Вам не режет слух сама постановка данного предложения? Вы, имея мало опыта в теории цвета, беретесь писать программу, которая будет лучше, чем фотошоп, написанный профессиональными индусскими кодерами? К тому же, за все время существования (при всей своей нелепости и багонасыщенности, которой я, увы, не отрицаю) он накопил весьма существенный опыт теории цветовоспроизведения, а вы хотите РРАЗ! и свежим взглядом все окинуть и написать лучше. Мой вам совет - поучите сначала матчасть, возможно, желания писать что-то новое весьма поубавится.

Вернусь к делу, пока не передумал.

Вот именно, подумайте хорошенько.

Выход я пока вижу такой – корректировать координаты LAB еще до преобразования LAB->XYZ->RGB, т.е. «втискивать» цвета, вышедшие из гамута sRGB, в этот гамут.

Это чертовски сложно именно по той причине, что преобразование двойное. Попробуйте для начала сделать из него прямое Lab->RGB хотя бы теоретически, если это вообще возможно, а потом, каким нибудь координатным спуском (алгоритм стопроцентно будет итерационный) подгонять точки пересечения. Но, сразу предполагаю, даже если и реализуете, польза от этого будет близка к нулю, ибо работать будет медленно, а результат получится совершенно непредсказуемый и совсем не тот, на который вы рассчитываете, затевая все это. Думаю, данный метод будет, скорее хуже существующего, не могу сходу сказать чем, просто чувствую.

Вообще-то этим должны заниматься системы CMS.

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

 

[ENVdovin]

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

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

Это чертовски сложно именно по той причине, что преобразование двойное. Попробуйте для начала сделать из него прямое Lab->RGB хотя бы теоретически, если это вообще возможно, а потом, каким нибудь координатным спуском (алгоритм стопроцентно будет итерационный) подгонять точки пересечения. Но, сразу предполагаю, даже если и реализуете, польза от этого будет близка к нулю, ибо работать будет медленно, а результат получится совершенно непредсказуемый и совсем не тот, на который вы рассчитываете, затевая все это. Думаю, данный метод будет, скорее хуже существующего, не могу сходу сказать чем, просто чувствую.

Я уже придумал, как сделать НЕ ЭТО, НО ТО ЖЕ САМОЕ неитерационным способом. Сейчас попытаюсь объяснить.
Согласен, что скорее всего такой перенос точки в пространстве LAB возможен только итерационным способом.
Однако я изучил визуально кривизну пространства LAB в системе координат RGB и пришел к весьма радостному выводу:
возможен способ переноса точки в пространстве RGB, который будет абсолютно эквивалентным переносу в пространстве LAB.
Для этого необходимы всего два условия:
1) ось L должна быть прямой в пространстве RGB,
2) любая плоскость AB должна быть плоской в пространстве RGB.
Оба этих условия выполняются.
Следует отметить, что далеко НЕ ВСЯКИЙ перенос в пространстве LAB можно воспроизвести в пространстве RGB. Но именно ТАКОЙ перенос возможен.
Я попытаюсь это запрограммировать и отпишусь о результатах, если интересно.

Система CMS - простое табличное преобразование одних значений цвета в другие, промежуточные данные интерполируются.

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

 

[_MBK_]

1) ось L должна быть прямой в пространстве RGB,
2) любая плоскость AB должна быть плоской в пространстве RGB.
Оба этих условия выполняются.

Да ну?????

Да. Но система CMS предоставляет 4 разных метода "вмещения запредельных" цветов в пределы целевого гамута при преобразовании.

В смысле?

 

[ENVdovin]

Да ну?????

Ну да

В смысле?

Вот выдержка одной из статей на тему gamut mapping и систем CMS:
1. Цвета, выходящие за цветовой охват, приводятся в соответствие ближайшим, находящимся на границе цветового охвата и имеющим либо ту же яркость, либо ту же насыщенность, что и цвета за пределами цветового охвата. Такой способ пересчета реализован в таблицах Colorimetric Rendering Intent и Saturation Rendering Intent соответственно.
2. Все цвета, выходящие за цветовой охват и входящие в цветовой охват, равномерно смещаются в сторону ахроматической оси. Другими словами, происходит равномерное сжатие всего аппаратно-независимого пространства в цветовой охват конкретного устройства. Такой способ пересчета реализован в таблице Perceptual Rendering Intent.
Оригинал

 

[TRANTOR]

почему в фотошопе все эти четыре метода дают одинаковые результаты

При конвертации это зависит от профиля. В нем указаны допустимые методы гамут-мапинга.

Ну да

Почитайте, все же, литературу. У Вас наблюдается пробел в этой области. Начните с "Джадд Д., Вышецки Г. — Цвет в науке и технике"

 

[mihas]

А идея-то простая: редактор уровней яркости, более-менее соответствующей человеческому восприятию, но без пресловутых «недосвеченных насыщенных остатков»,

Ну вы вряд ли изобретете колориметрически верный алгоритм взамен матричным уравнениям CIE RGB->XYZ и степенным преобразованиям XYZ->Lab. Вы же просто уперлись в гамут-маппинг с этим странным примером с L=0 и насыщенными цветовыми каналами при этом. Задали в фотошопе несуществующий цвет из некорректных цифр за охватом HVS и хотите чтобы он корректно пересчитался в RGB? Вот здесь http://www.brucelindbloom.com/iPhone/ColorConv.html вы можете все по быстрому прикинуть без клиппинга и маппинга, если взять ваш красный или синий цвет Lab с нулевой светлотой например 0 30 -40 и пересчитать в RGB - получите отрицательное значение в зеленом канале -18. Что делает фотошоп с отрицательными значениями в каналах? Приводит их к нулю. Возможно он делает не просто клиппинг а маппинг, то есть еще и пересчитывает в минус два других канала но факт фактом - отрицательных значений в модели RGB для существующих цветов нет. Теперь пересчитайте из RGB с нулем в канале и положительными значениями в двух других каналах отображение на экране - L будет уже не ноль. Клиппинг отрицательного значения в цветовом канале до нуля приводит к тому, что светлота начинает отличаться от нуля.
Когда мы по каким-то причинам вычисляем RGB значения меньше 0 или больше 1 (255) - что делать программисту? Причем это может быть и не дурацкий пример с цветным черным а просто цвет не вписывается в охват того или иного пространства RGB. Самое простое - клиппинг, все меньше 0 приравниваем к нулю и все больше 1 (255) - приравниваем к 1. Видим не пойми чего при этом но так проще всего. Можно усложнить - будет маппинг, не просто приведем отрицательные к нулю но и по какому-то алгоритму двинем еще и два других канала. В идеале в вашем примере с несуществующим цветным черным надо два других канала привести тоже к нулю. Сделать это не сложно, просто фотошоп здесь не стал делать условия для очевидных глупостей, как бы смапить несуществующий цвет lab в несуществующий цвет RGB: поверьте, написать у словие, что при L=0 все RGB-каналы должнгы быть тоже ноль вне зависимости от каналов a и b - несложно. Фотошоп делает маппинг, можете сравнить с калькулятором линдблума результат, увидите, что он меняет все три цветовых канала а не только приравнивает к нулю отрицательные. Это уже не колориметрия а волюнтаризм но тем не менее так оно работает: а что делать, если пользователь на обычном мониторе хочет картинку AdobeRGB - посмотреть: настоящих цветов он не увидит но как-то ему их смапить удобоваримо - почему нет?
Третий вариант, который мне по душе в моих инструментах - сделать клиппинг или маппинг но при этом еще и предупредить об этом. Не вписался в охват - напиши об этом, чтобы пользователь понимал, что отображаемый цветовой патч за границей корректных вычислений. Так я сделал например при подборе смесевых красок, находящихся за охватом принятого в WEB пространства sRGB: http://rudtp.pp.ru/assortment/ Часть печатных красок действительно не укладывается в маленький охват sRGB - ну так и пишу что не укладывается. Вон даже триадный голубой и то не укладывается, не говоря уж о более хроматичных спотовых красках.