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

[_MBK_]

Я, вообще то брал такой алгоритм, потому как он ближе всего к фотошоповскому - вы ж собираетесь фотошоп улучшать, не так ли? Вдобавок, я очень сильно сомневаюсь, что с D65 алгоритм плоскости сохранять будет. Я надеюсь, вы согласны, что с D65 это явно не плоскости? Смысла область брать шире я не вижу никакого, поскольку даже на такой маленькой области кривизна уже заметна - на большой будет еще значительнее.

 

[ENVdovin]

Опять путаете, это у меня был D65, где явно были плоскости. Но не важно.
Предлагаю Вам остаться при своем мнении и закрыть данную дискуссию, тем более при таком отношении. Думал, открою кому-то что-то полезное, но оказывается, я сам с собой говорю.
Для себя я сделал нужные выводы и буду продолжать работу.

 

[mihas]

Проверил на примере 9 точек от _MVK_ в аттаче. _MVK_ прав, в Lab они не лежат в одной плоскости. Пересчитывал из sRGB c гаммой sRGB и белой точкой D65 в Lab D65 без хроматической адаптации. Визуализировал просто в CHROMiX ColorThink Pro на графике 3D. Близко к плоскости но не плоскость. Желающие могут сами втащить файл с Lab-значениями в ColorThink и повертеть плоскость из 9 точек так и сяк: это не плоскость но близко к ней.

 

[andrejK]

да нет никаких желающих.

автор поражает своим упорством и отрицанием очевидных вещей.

только Михаилы )) могут это терпеть и ещё как-то отвечать.

 

[mihas]

только Михаилы ) могут это терпеть и ещё как-то отвечать.

Ну с другой стороны хочется понять, что же собственно собрались улучшать в фотошопе? Какой алгоритм усовершенствовать? Хроматическая адаптация от D65 к D50 там безупречная, устаревшая по сравнению с CAT02 но Брэдфорда никто не отменял. Формулы CIE тоже верно работают. Компенсация черной точки работает супер и она настолько сложная, что ни один чел на форуме ее не то что не перепишет лучше - даже смоделировать не сможет как она есть. Что в переходе Lab<->RGB не так еще? Ради чего спорим и что пытаемся изменить?

 

[ENVdovin]

Проверил на примере 9 точек от _MVK_ в аттаче. _MVK_ прав, в Lab они не лежат в одной плоскости. Пересчитывал из sRGB c гаммой sRGB и белой точкой D65 в Lab D65 без хроматической адаптации. Визуализировал просто в CHROMiX ColorThink Pro на графике 3D. Близко к плоскости но не плоскость. Желающие могут сами втащить файл с Lab-значениями в ColorThink и повертеть плоскость из 9 точек так и сяк: это не плоскость но близко к ней.

А Вы ведь совершили перевод из RGB в LAB... Я понимаю, что тема не стоит внимательного прочтения.
P.S. Я использовал гамму 1.0, вот, чтоб не утруждаться посчитанные значения:

Спойлер

LAB:
30 20 20
30 30 20
30 30 30
30 20 30
30 30 40
30 40 40
30 40 30
30 40 20
30 20 40

RGB:
37,2883358851515 10,587917011019 5,53370309452717
46,6866247840402 7,77680547319345 5,69509774656638
48,222044540632 7,6488186650357 2,43872417547959
38,8237556417432 10,4599302028612 2,27732952344038
49,25457739406 7,56275061513538 0,24889127750685
59,5134292289637 4,49423707312771 0,425064178768893
58,4808963755357 4,58030512302803 2,61489707674163
56,945476618944 4,70829193118578 5,87127064782842
39,8562884951712 10,3738621529609 0,0874966254676416

 

[_MBK_]

Опять путаете, это у меня был D65, где явно были плоскости.

Я ничего не путаю - лично я считал D50 с гаммой sRGB, потому что так считает фотошоп.
Почему вы думаете, что результат D65 с гаммой 1 корректнее будет и там будут плоскости?
ЗЫ: Только что посчитал через определитель - первые четыре точки по вашим значениям тоже не лежат в одной плоскости, так и вышло...

 

[ENVdovin]

Да нет, Вы просто опять опечатались в предыдущем посте. В данном случае мне без разницы, как считает фотошоп. Я не считаю, что результат D65 будет корректнее. Повторяю, я считаю, что он будет другим. И там будут плоскости, потому что, так уж получается из экспериментов.
А разве не очевидно, что гамма должна быть 1.0? Естественно, если искривить полученный результат в пространстве RGB гаммой, отличной от 1., никакие плоскости, направления нормалей которых отличны от направлений осей пространства, уже не будут плоскими.

 

[mihas]

А разве не очевидно, что гамма должна быть 1.0?

А зачем? Зачем нужны значения Lab, вычисленные из sRGB, но не с его гаммой, а с единицей? Такие значения Lab куда потом девать? Гамму опосля к лабу не применишь. Фотошоп забывает про гамму, когда уменьшает RGB-изображения и это его ошибка. А у вас "очевидно, что гамма должна быть 1.0". Не очевидно. Зачем?
С гаммой 1.0 точки так же не лежат в одной плоскости (аттач).

 

[mihas]

Проверьте у себя вычисления, должно быть для sRGB белая точка:
RefWhiteRGB.X = 0.95047;
RefWhiteRGB.Y = 1;
RefWhiteRGB.Z = 1.08883;

Матрица sRGB->XYZ:
0.4124564 0.3575761 0.1804375
0.2126729 0.7151522 0.0721750
0.0193339 0.1191920 0.9503041

и обратная XYZ->sRGB:
3.2404542 -1.5371385 -0.4985314
-0.9692660 1.8760108 0.0415560
0.0556434 -0.2040259 1.0572252

 

[_MBK_]

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

Где я опечатался в предыдущем посте? Я, конечно, понимаю, что вам все равно, что там придумали разные теоретики до вас, но давайте хотя бы основополагающие моменты уясним. Фотошоп делает преобразование D50 c гаммой sRGB, я сперва привел данные этого преобразования, проведенного в самом фотошопе, затем пересчитал его по другому с плавающей точкой. Результат вы видели - плоскости не сохраняются. Я не знаю, кому практически может понадобиться преобразование D65 с гаммой 1, естественно, оно совершенно другое, но плоскостей там, как видите, тоже нет. Как вы думаете, имеет смысл продолжать дальнейшую дискуссию или вы уже поняли, что дважды два - четыре? И, поясните мне пожалуйста, какой эксперимент показывает что там плоскости? Вы имеете в виду ваш мультик?

 

[ENVdovin]

А зачем? Зачем нужны значения Lab, вычисленные из sRGB, но не с его гаммой, а с единицей? Такие значения Lab куда потом девать? Гамму опосля к лабу не применишь. Фотошоп забывает про гамму, когда уменьшает RGB-изображения и это его ошибка. А у вас "очевидно, что гамма должна быть 1.0". Не очевидно. Зачем?
С гаммой 1.0 точки так же не лежат в одной плоскости (аттач).

И снова Вы посчитали преобразование RGB->LAB.
Еще раз:
Я тут пишу про преобразование LAB->RGB. Не про RGB->LAB.
Пожалуйста, при всем моем уважении, если Вам не интересна тема, не комментируйте. Если интересна, читайте повнимательнее.
Теперь, объясняю, почему в данном конкретном случае нужна гамма 1. Чтобы в пространстве RGB плоскости, нормали которых отличны от направления осей пространства, оставались плоскими. Просто для того, чтобы была возможность реализовать алгоритм, о котором я писал где-то там, много страниц тому назад. Вы можете наложить потом любую гамму, отличную от 1.0, хоть триста раз подряд, если будет нужно, но уже после гамут-маппинга.

Я не знаю, кому практически может понадобиться преобразование D65 с гаммой 1, естественно, оно совершенно другое, но плоскостей там, как видите, тоже нет.

Не вижу. Где посмотреть?

Сомнительный вопрос о том, кто именно тут не понимает, что дважды два четыре. А вообще, я уже предлагал прекратить дискуссию.

P.S. Кстати, Ваш посчитанный определитель можно в студию, пожалуйста?

 

[ENVdovin]

mihas, вот мои использованные значения:
RefWhiteRGB.X = 0.950456;
RefWhiteRGB.Y = 1;
RefWhiteRGB.Z = 1.088854;

Матрица sRGB->XYZ:
0.412453 0.357580 0.180423
0.212671 0.715160 0.072169
0.019334 0.119193 0.950227

и обратная XYZ->sRGB:
3.240479 -1.537150 -0.498535
-0.969256 1.875992 0.041556
0.055648 -0.204043 1.057311

Разница в 100000-ных долях не существенна.

 

[_MBK_]

Теперь, объясняю, почему в данном конкретном случае нужна гамма 1. Чтобы в пространстве RGB плоскости, нормали которых отличны от направления осей пространства, оставались плоскими.

Кажется, я начинаю понимать истоки вашего заблуждения. Вы, навернео, думаете, что если преобразование XYZ->RGB при гамме 1 является простым матричным, то и общее преобразование Lab->RGB тоже линейным? Могу вас огорчить, что это не так, при преобразовании Lab->XYZ присутствует третья степень, поэтому общее преобразование линейным быть не может по определению.

 

[ENVdovin]

Кажется, я начинаю понимать истоки вашего заблуждения. Вы, навернео, думаете, что если преобразование XYZ->RGB при гамме 1 является простым матричным, то и общее преобразование Lab->RGB тоже линейным? Могу вас огорчить, что это не так, при преобразовании Lab->XYZ присутствует третья степень, поэтому общее преобразование линейным быть не может по определению.

Не спорю, не может.
Задумайтесь над тем, что я написал про плоскости. Искривляются только те плоскости, нормали которых отличны от направлений осей пространства. Это касалось вопроса с гаммой.
Это же самое относится и к нелинейному преобразованию с возведением каждой координаты в третью степень. Плоскость AB при этом остается плоской. Если бы мы взяли плоскость, которая имеет некоторый угол наклона по отношению к плоскости AB, то вот она бы стала кривой.

 

[_MBK_]

Все это было бы справедливо только в том случае, если бы каждая компонента зависела только от одной исходной компоненты (например x1=k1*x2^3, y1=k2*y2^3, z1=k3*z2^3) в нашем же случае зависимость более сложная, так что плоскости не сохраняются уже на этапе Lab->XYZ)

 

[ENVdovin]

Все это было бы справедливо только в том случае, если бы каждая компонента зависела только от одной исходной компоненты (например x1=k1*x2^3, y1=k2*y2^3, z1=k3*z2^3) в нашем же случае зависимость более сложная, так что плоскости не сохраняются уже на этапе Lab->XYZ)

Зависимость более сложная, но L зависит только от одной компоненты y. И наоборот, y зависит только от одной компоненты L. Поэтому плоскости AB являются исключением.

 

[_MBK_]

Зависимость более сложная, но L зависит только от одной компоненты y.

А, точно, извиняюсь, сразу не заметил. Тем не менее, результирующее преобразование в RGB плоскости все равно не сохраняет, попробую еще внимательнее пересчитать.

 

[mihas]

Разница в 100000-ных долях не существенна.

Согласен.

Я тут пишу про преобразование LAB->RGB. Не про RGB->LAB.

Хорошо но с гаммой 1 вобщем все равно: если в одной модели 9 точек в одной плоскости то в другой нет. RGB->Lab мне удобнее визуализировать.
Про алгоритм ваш пока не понял что вы хотите сделать, гамут-маппинг?

 

[ENVdovin]

Согласен.
Хорошо но с гаммой 1 вобщем все равно: если в одной модели 9 точек в одной плоскости то в другой нет. RGB->Lab мне удобнее визуализировать.
Про алгоритм ваш пока не понял что вы хотите сделать, гамут-маппинг?

Поверьте, это не взаимно обратное свойство.
Чтобы Вам не перечитывать весь топик заново, расскажу вкратце.
Спор шел о кривизне пространства LAB в системе координат sRGB. Я утверждал, что, хоть оба пространства не сопоставимы линейно, следующие условия выполняются:
1) Все оси L,A,B пространства LAB продолжают оставаться прямыми в пространстве sRGB (однако перестают быть взаимно перпендикулярными).
2) Любые плоскости AB пространства LAB остаются плоскими в пространстве sRGB (однако перестают иметь эквидистантную дискретную сетку).
Как видите, речь шла о том, что только плоскости AB остаются плоскими в sRGB, и только об этом. Я не рассматривал какие-либо плоскости пространства sRGB в системе координат LAB. Я также не рассматривал какие-либо другие плоскости пространства LAB в системе координат sRGB, т.к. они уже не будут оставаться плоскими.
Сделать я хочу следующее: некий гамут-маппинг при переводе LAB->RGB для цветов вышедших за пределы гамута sRGB, сохраняющий неизменной светлоту и оттенок, и жертвующий хромой.