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

[mihas]

Будет не одинаково. Но в обоих случаях - условно-правильно

Ну посчитайте же наконец! Хоть здесь http://www.brucelindbloom.com/iPhone/ColorConv.html
Будет абсолютно одинаково безо всяких условно!

Вот когда мы будем работать с файлом в лабе, тогда и будем мерить лабовским аршином, там это будет обосновано.

Я работаю в модели RGB или CMYK или еще какой с цветом, вы работаете с каналами. Эта история здесь на форуме уже сто раз звучала. Я сужу о правильности или неправильности алгоритмов с точки зрения колориметрии, вам больше нравится, чтобы несложная поканальная арифметика выдавала понятный простой ответ. Вы доказываете, что пользователям графического редактора важнее понятная им арифметика, я доказываю что правильный цвет важнее арифметики и наплевать, как это внутри программы математически реализовано.
Я меряю не лабовским аршином а колориметрическим. И даже привел выше пример, чего в лабе посчитать правильно нельзя, но можно правильно в XYZ. И фотошоп обычно прекрасно всеми этими координатами оперирует, только вот операцию уменьшения поленились написать правильно для всех условий. И не говорите, что в фотошопе нельзя в модели RGB оперировать например колориметрической светлотой или тоном - можно, и при изменении светлоты будет меняться именно светлота, безо всякой простой логики в поведении цветовых каналов при этом. И простое изменение колориметрического тона hue RGB картинки нельзя описать никакими уравнениями для трех цветовых каналов RGB. Как и для большинства операций, к счастью.

различия, которые вам не дают покоя.

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

 

[mihas]

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

 

[dom1n1k]

Ну посчитайте же наконец!

Да не будет же оно одинаково! Просто не может быть. Для примера:
lch1 = 50/50/50 -> lab1 = 50/32.1394/38.3022
lch2 = 50/30/70 -> lab2 = 50/10.2606/28.1908
lch[avg] = 50/40/60 -> lab[avg] 50/20.0000/34.6410
Легко заметить, что (32.1394 + 10.2606)/2 != 20.0000, аналогично и по второй координате.

Если бы оно было одинаково, специалисты по визуализации данных сейчас не пилили бы себе специальные библиотеки для интерполяции цветов именно в LCh. Им оно подходит наилучшим образом.
Самое известное - http://old.driven-by-data.net/about/chromajs/#/0 и https://github.com/gka/chroma.js

Вы доказываете, что пользователям графического редактора важнее понятная им арифметика [...] И не говорите, что в фотошопе нельзя в модели RGB оперировать например колориметрической светлотой или тоном

Я этого и не говорил.
Повторюсь еще раз, надеюсь хоть теперь будет понятнее - я говорю, что пользователи рассчитывают (и имеют право) получить понятную арифметику в базовом варианте по умолчанию. Многие вообще не знают, что такое адаптация и с трудом понимают понятие гаммы (те же фотографы в массе своей - технически не очень грамотные люди). Я помню себя N лет назад - когда программа выдает что-то совершенно непонятное (хотя теоретически возможно и правильное), это выносит мозг. Я её прошу сложить 2 и 2, а получаю 5. И сидишь думаешь - то ли я идиот, то ли одно из двух.

Вместе с тем, я всячески приветствую все эти продвинутые корректные алгоритмы, но как дополнительную опцию. Когда пользователь сам сознательно натыкал нужные галки, когда ему это стало нужно. Хочется смешивать цвета с учетом гаммы - включите этот режим.
Условно говоря, не надо мне сразу навязывать теорию относительности, мне пока и ньютоновской механики хватит! Вот когда я созрею - тогда и включим релятивистские эффекты.
После многих лет в IT я убежден - программа должна помогать пользователю, но она не должна додумывать за него, что ему нужно, если её об этом не просили. Это воспринимается как навязчивая медвежья услуга.

И простое изменение колориметрического тона hue RGB картинки нельзя описать никакими уравнениями для трех цветовых каналов RGB.

Смотря какой hue. Если он из HSB, то можно же.

 

[mihas]

Смотря какой hue. Если он из HSB, то можно же.

Можно, да, не люблю hsb за его отвязанность от цвета!

"пользователи рассчитывают (и имеют право) получить понятную арифметику в базовом варианте по умолчанию".
Идея понятна.

Мое видение выглядит иначе:
пользователи рассчитывают получить правильную базовую колориметрию и им глубоко наплевать на применяемую при этом арифметику в графическом редакторе.

 

[dom1n1k]

Дело в том, что "правильная" колориметрия нетривиальна и неоднозначна, в зависимости от множества параметров. Нет такого алгоритма, который даст правильный результат всегда и везде. Какой набор параметров мы должны выбрать? Почему именно такой, а не иной? Непонятно. При неправильных/неоптимальных параметрах результат, скорее всего, всё равно будет неверен. Но какой-то другой и непонятный. Пользователь должен выбирать их осознанно.

Ну что толку навязывать пользователю какого-нибудь Бредфорда, если он не знает что это и не понимает зачем оно нужно? А раз не понимает - оно ему не нужно. Ему проще сделать всё на глазок так, как ему понравится. Пусть это будет не совсем корректно с т.з. науки, но по крайней мере предсказуемо. Интересы продвинутых пользователей это никак не ущемляет.

 

[mihas]

Я думаю, что обычные пользователи действительно могут ничего не знать о Брэдфорде, но если фотошоп по дефолту отключит эту хромадаптацию - обычные пользователи ну очень возмутятся! На глазок хромадаптацию не сделаешь. Черт знает что по цвету программа будет показывать и ей никто пользоваться не станет без Брэдфорда.
Соглашусь, что решение колориметрической задачи хромадаптации например может быть решено массой способов и все результаты будут разными. Да продвинутому пользователю может хотелось бы в фотошопе иметь переключатель между Брэдфордом и CIECAM02 и так далее. Тем не менее отключить хромадаптацию по дефолту вообще нельзя, какую-то надо держать включенной всегда в графическом редакторе. Иначе это будет не редактор. У меня калькулятор умеет отключать хромадаптацию а MT не умеет. Для калькулятора это плюс и то я селекторы когда надо по дефолту включаю для большинства задач и только пользователь имеет право осмысленно выключить. Может и в фотошопе надо иметь возможность выключить для экспериментальных целей, но по дефолту фотошоп Брэдфорда все же включает и правильно делает. Это ж не конструктор, не экселовский файл для упражнений с арифметикой, это графический редактор.
И что предсказуемого в изображении без хромадаптации? То что это примитивно, колориметрия не работает и ничего ни на что не похоже, зато примитивная арифметика задействована. Может и в операционке отключить хромадаптацию до кучи? Будет сразу понятно и надежно как команданая строка DOS. А то придумали тут графический инерфейс, разбаловались.

 

[mihas]

Может вы так прикалываетесь? Или и правда любовь к упрощению столь сильна? Редкую операцию, в которой фотошоп ошибается, вы защищаете, что это не ошибка. Там же где фотошоп делает все колориметрически верно - предлагаете упростить, отказаться от сложной хромадаптации по дефолту, лишь бы незнакомому с колориметрией была понятна примитивная арифметика. Фотошоп не наглядное пособие для изучающих азы арифметики.

 

[dom1n1k]

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

ФШ, как ни крути, продукт для пользователей с очень широким спектром квалификации, как MS Office для документооборота. Adobe это прекрасно понимает и вынуждена как-то балансировать, чтобы и профессиналам угодить, и обычным людям. Они ж не дураки терять такой огромный рынок.

 

[mihas]

Ну я тоже в чем-то с вами соглашусь а в чем-то нет.
Некоторые функции как бы сложны или непонятны они ни были все равно должны быть. И постоянно задействованная помимо воли пользователя хромадаптация необходима, иначе бы с фотика он получал верхнюю картинку, а после простого цветоделения её из sRGB в fogra39 - нижнюю картинку.

И никакими поканальными манипуляциями ни в лабе, ни в цмике, ни в rgb из этих картинок нельзя сделать то, что в действительности должно быть (припас на всякий и то что должно быть посередине). Специально помещаю именно картинку для наглядности а не цифры и формулы, именно так бы выглядела наша работа в фотошоп без хромадаптации по Брэдфорду безо всякого даже Lab просто при переходе от sRGB к fogra39.
Так же не соглашусь, что можно волюнтаристски считать цвет прямо в нелинейных RGB. Слишком криво и ошибка заметная. А вот с разночтениями в векторной пространственной математике между векторами LCh и координатами Lab - тут есть о чем подумать. Усреднение в Lab даст правильный ответ в пространстве dE1976, но это достаточно примитивная линейная шкала в нелинейном пространстве. Усреднение длин векторов Chroma и разница между углами hue теоретически могла бы дать верный ответ в более продвинутых пространствах dE1994 и dE2000, но тоже не дает (по ссылке визуализированы цифры из вашего примера) http://rudtp.pp.ru/report.php?50&19.28&22.98&50&20&34.64&50&17.1&46.98&50&20&34.64 Продвинутые дельты не равны между крайними и средним значением, а значит это все же не строго среднее цветовое значение найдено и в системе LCh так же. Так что тут поразмыслив соглашусь на определенные погрешности в Lab и LCh при усреднении цвета соседних пикселов. В идеале на мой взгляд было бы искать среднее в громоздком пространстве dE2000, но это было бы неприлично долго для графического редактора. Но это не значит, что мы вообще должны докатиться до примитивизма расчетов прямо в неколориметрических координатах rgb и hsb, то есть таких вычислений, при которых цвет заметно искажается при нашем не очень строгом восприятии. И в большинстве случаев фотошоп до примитивизма и не скатывается.

 

[dom1n1k]

а после простого цветоделения её из sRGB в fogra39

Ничего не смущает в этой фразе? Какой обычный пользователь будет что-то делить в fogra?! Он явно не относится к категории обычных.

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

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

Усреднение длин векторов Chroma и разница между углами hue теоретически могла бы дать верный ответ

И теоретически не могла никак. Ну очевидно же: в Lab точки соединяются прямыми отрезками (декартовы координаты), а в LCh тон интерполируется по концентрическим дугам (полярные). Они разные и никак не могут совпадать (хотя и тесно связаны, конечно). И это нормально, так и задумано.

 

[mihas]

Какой обычный пользователь будет что-то делить в fogra?!

Как раз не актуально и не имеет значения - любые другие профили CMYK, которые могут быть подключены помимо сознания обычного пользователя, как и фогра39 не имеют белой точки D65 стандарта sRGB - об этом речь в защиту хромадаптации.