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

[ENVdovin]

Здравствуйте.
Случайно обнаружил некую особенность пространства CIELAB (или его программных реализаций).
Если в Photoshop у изображения выставить L в минимум (например, залить канал L черным цветом), часть цветов изображения останется - это в основном красные и синие оттенки. Хотя ожидается увидеть полностью черное изображение. Аналогично, при L = максимуму, цветов остается еще больше, там уже присутствуют другие оттенки кроме синего и красного. Но ожидается абсолютно белое изображение.
То же самое я обнаруживал в программных реализациях на C/C++, доступных в интернете.
Что это за особенность CIELAB, и какова ее природа?

 

[_MBK_]

То есть, вы считаете, что все цветовые плоскости (0,a,b) и (1,a,b) должны задавать один единственный цвет? Но это совершенно нелогично, соответственно и формулу перевода подобрали такую, чтобы исключить подобную расточительность.

 

[ENVdovin]

Да, я, честно говоря, думал, что они задают один цвет, как в HSL. Получается, что эти "остатки" - цвета, вышедшие за гамут sRGB, и претерпевшие клиппинг?

 

[_MBK_]

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

 

[ENVdovin]

Но ведь если посмотреть, как выглядит цветовое тело CIELAB, можно сказать, что при значениях L, стремящихся к крайним, площадь сечения тела в плоскости L будет стремиться к нулю. Т.е., грубо, крайние плоскости (0,a,b) и (1,a,b) представлены точками, а следовательно, одним цветом - соответственно, черным и белым. Или я ошибаюсь?
Далее я пытаюсь понять, как ведет себя Photoshop. Цвет, полученный из некоего насыщенного цвета средней светлости при изменении L до значения 1 оказывается в точке пространства, лежащего за пределами цветового тела LAB. Назовем эту точку "G". Получается, что Photoshop (грубо) берет в этом случае цвет, находящийся на пересечении поверхности цветового тела и прямой, проходящей через точку "G", параллельной оси L.
Но логичнее (или более осмысленно) было бы брать цвет, лежащий на пересечении поверхности цветового тела и прямой, проходящей через точку "G", перпендикулярной оси L.
Или я снова ошибаюсь?

 

[_MBK_]

Но логичнее (или более осмысленно) было бы брать цвет, лежащий на пересечении поверхности цветового тела и прямой, проходящей через точку "G", перпендикулярной оси L.

Поясните этот момент, можно графически? Я не совсем понял.

 

[ENVdovin]

Проиллюстрирую попозже, скорее всего, завтра.

 

[TRANTOR]

Это результат работы гамут-мэпинга. Конкретная его реализация в Фотошопе дает вот такой результат. Напишете свой алгоритм, значит будет по-другому.

Про различные реализации гамут-мэпинга можно почитать, например, у Ján Morovič - Color Gamut Mapping.

 

[_MBK_]

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

 

[_MBK_]

Кстати, чтобы убедиться в этом, достаточно фотошопом перевести какой нибудь цвет с L=100 в RGB и обратно. При обратном преобразовании наглядно видно, что граничная точка пересечения лежит вовсе не на прямой параллельной L, а значительно сбоку.

 

[ENVdovin]

Изобразил как обещал:

Это результат работы гамут-мэпинга. Конкретная его реализация в Фотошопе дает вот такой результат. Напишете свой алгоритм, значит будет по-другому.

Про различные реализации гамут-мэпинга можно почитать, например, у Ján Morovič - Color Gamut Mapping.

Спасибо, поизучаю.

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

Насколько я понимаю, так называемый гамут-маппинг делается еще до преобразования из LAB в XYZ и далее в RGB. Поэтому все оси прямые и перпендикулярные.

Я пока еще не разобрался до конца.

 

[_MBK_]

Насколько я понимаю, так называемый гамут-маппинг делается еще до преобразования из LAB в XYZ и далее в RGB. Поэтому все оси прямые и перпендикулярные.

Если бы это было так, то преобразование, описанное в сообщении #10 давало бы граничный цвет с теми же значениями a и b, а этого не наблюдается. Я не вникал в код, но, скорее всего образка происходит именно на этапе XYZ->RGB, именно там происходит сужение цветового дипапзона. Пространство XYZ по идее, шире, чем Lab, а RGB - самое узкое из всех.

 

[ENVdovin]

_MBK_, потестил Ваш эксперимент в Photoshop и пришел к следующим выводам.

Photoshop действительно не использует проецирование параллельно оси L (синий кружок на иллюстрации). Иначе координаты a и b оставались бы неизменными. Но он также не использует проецирование перпендикулярно L (зеленый кружок на иллюстрации). Иначе оставалась бы неизменной координата L. Остается вариант альтернативного проецирования (возможно так, как обозначено желтым кружком на иллюстрации), что примерно подтверждается результатами Вашего эксперимента. Этот вариант также можно считать проецированием с наименьшим отклонением координат. Т.е. берется ближайшая точка, принадлежащая цветовому телу LAB. С этой точки зрения алгоритм работает логично.

Однако получается, что Photoshop не предоставляет инструментов для изменения уровней яркости изображения, в которых изменение некоей величины «яркость» соответствовало бы изменению L, и при этом цвет оставался внутри цветового тела. Инструменты levels и curves работают с координатами текущего цветового пространства, никак не контролируя выход цвета за пределы цветового тела (поэтому, возможны цвета с координатами L=100, a<>0, b<>0). Клиппинг значений каналов цветов происходит при переводе между пространствами, в том числе, при отображении цветов LAB на мониторе. При этом во всех случаях срабатывает один и тот же метод проецирования на цветовое тело.

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

 

[_MBK_]

Не совсем понимаю, как вы видите реализацию этого на практике? Насколько я понимаю, внутри себя фотошоп все цветовые операции делает не в текущей цветовой модели, а во внутреннем представлении цвета (IMHO, это XYZ), затем преобразуя полученное значение к выбранной цветовой модели. Тут то и производится обрезка. Вы ж не забывайте еще про цветовые профиля, которые применяются при этом, поскольку воспроизведение монитора тоже нелинейно. При соблюдении всех этих условий, линейное изменение яркости становится безумно сложной задачей, не факт, что вообще выполнимой.

 

[ENVdovin]

Не думаю, что Photoshop хранит данные в XYZ. Этому противоречит хотя бы следующее.
Пользователь выбирает цветовое пространство, в котором происходят все цветовые операции. Было бы неправильно при каждой операции делать преобразование из XYZ в заданное пространство, затем производить операцию, требующую на входе координаты заданного пространства, затем обратное преобразование, т.к. это каждый раз вносило бы дополнительные ошибки, вызванные процессом квантования. Возможно, количество ошибок было бы минимальным, если бы данные XYZ всегда хранились хотя бы в глубине 16 бит на канал, но глубина цвета промежуточных данных задается пользователем, и по умолчанию это 8 бит. Кроме того, это большой объем лишних вычислений. Поэтому, логичнее всего хранить данные в координатах текущего цветового пространства, да и в файл сохраняются именно они.

Цветовые профиля тут не при чем, т.к. они представляют собой, IMHO, графики нелинейности по каждому каналу RGB, и применяются при отображении на экране. Я не говорю именно о линейном изменении яркости. Безусловно, ее «линейность» будет нарушена на разных мониторах. Я говорю, что когда я хочу, например, выкрутить яркость изображения до максимума, я ожидаю увидеть полностью белое изображение на моем мониторе. И при этом я отдаю себе отчет, что мой монитор не может показать некоторые слишком яркие и одновременно слишком насыщенные цвета. Но лучше, если в этом случае он покажет белый цвет, чем более темный, но насыщенный цвет, потому как по тем же самым оценкам CIELAB, второй вариант будет менее ярким, чем первый. Т.е. для меня в данном случае предпочтительнее сохранить Lightness, чем Chroma.

Реализацию на практике я вижу очень просто – метод проецирования должен быть перпендикулярным L, о чем я писал выше.

 

[_MBK_]

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

 

[mihas]

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

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

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

 

[_MBK_]

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

Ну, если вдуматься, то это еще ничего не значит - возможно, это потери при обратном переводе в более узкое пространство? Хотя, масштабирование, при ближайшем рассмотрении, похоже, оно и вправду в текущей модели делает: при переводе 2 пиксельного изображения (0,0,0) и (254,254,254) получаем четкое (127,127,127) что какбэ намекает.
Тем не менее из Lab в RGB оно переводит все таки через XYZ, причем явно с плавающей точкой, как и многие другие операции и обрезает соответственно

 

[ENVdovin]

Как минимум, все алгоритмы работы с цветом (яркость, контраст, цветовой баланс и т.д.) невозможно реализовать оставаясь в рамках модели RGB.

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

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

Ошибка зависит не от цветового охвата (gamut), а от глубины цвета. Какая разница, измеряем мы количество метров в километре или количество миллиметров в метре, если для этого мы все равно используем тысячу отсчетов. А вот как раз при переводе из одного пространства в другое, если одно из них уже другого (хотя правильнее говорить о цветовых охватах, а не о пространствах), а глубина цвета одинакова - тогда мы будем иметь значительные ошибки, опять же, связанные с разницей квантования этих пространств. Если в километровом пространстве километр мы будем квантовать через каждый метр, то вся информация исчезнет, если мы совершим перевод в метровое пространство, которое квантуется каждый миллиметр - шаг квантования окажется равен гамуту. Поэтому перевод из LAB в RGB через XYZ происходит с плавающей точкой - это так.

 

[_MBK_]

Повторяю, я не уверен относительно преобразования в XYZ исключительно при работе всех алгоритмов. Хотя, при работе с RAW у меня достаточная доля уверенности имеется. То же самое при переводе Lab<->RGB и обратно. Я сходу даже придумать не могу прямого алгоритма без участия XYZ, не уверен, что он вообще существует.
Что касается ограничений эффектов - насколько я понимаю, ограничения имеются только у палитровых и однобитных режимамов, что вполне очевидно, опять же, если масштабирование можно производить оставаясь в рамках одной модели, то, например, цветовой баланс - нельзя.