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

  • Автор темы Автор темы ENVdovin
  • Дата начала Дата начала
Статус
Закрыто для дальнейших ответов.
2) Любые плоскости AB пространства LAB остаются плоскими в пространстве sRGB (однако перестают иметь эквидистантную дискретную сетку).
Пока что данная гипотеза остается не до конца опровергнутой только в случае D65 с гаммой 1. И то, только потому, что мне пока некогда всерьез садится за разбор формул. Но численный анализ, приведенный выше, показывает, что скорее всего, даже в данном экзотическом случае она не выполняется.
 
Пока что данная гипотеза остается не до конца опровергнутой только в случае D65 с гаммой 1. И то, только потому, что мне пока некогда всерьез садится за разбор формул. Но численный анализ, приведенный выше, показывает, что скорее всего, даже в данном экзотическом случае она не выполняется.
Она также остается не опровергнутой для D50 с гаммой 1., а также для любого другого источника. Не так ли?
 
В принципе да, но мы пока что рассматриваем именно этот случай, не так ли? ;)
 
Сделать я хочу следующее: некий гамут-маппинг при переводе LAB->RGB для цветов вышедших за пределы гамута sRGB, сохраняющий неизменной светлоту и оттенок, и жертвующий хромой.
Все предельно ясно. Сжимать хрому будете перцепционно или релативно только на краю? Или так и так? Думаю задача осуществима вполне.
 
Да я в общем то и не спорил по поводу реализуемости. Вопрос только в сложности преобразований и, собственно, практической пользе сего действа. Тем более, похоже, действительно, гамма 1 сохраняет плоскости ab при преобразовании в RGB
 
Да я в общем то и не спорил по поводу реализуемости. Вопрос только в сложности преобразований и, собственно, практической пользе сего действа. Тем более, похоже, действительно, гамма 1 сохраняет плоскости ab при преобразовании в RGB
Поздравляю с просветлением.'))'

Все предельно ясно. Сжимать хрому будете перцепционно или релативно только на краю? Или так и так? Думаю задача осуществима вполне.
Только на краю. Но желательно и так и так. Да я уже понял давно, как это делать, еще в посте №36.
 
Да я уже понял давно, как это делать, еще в посте №36.
Ну я вам в предыдущем сообщении писал свои опасения относительно этого. И случай с гаммой 1 отнюдь не упрощает дело. Во-первых, работать будет заметно медленнее, а во вторых - практическая польза близка к нулю.
 
Практическая ценность пока только не ясна: RI Perceptual и Saturation тоже неплохо сжимают, правда L тоже затрагивают. Но если L не затрагивать, а попытаться оставить на месте, то chroma придется сжимать значительно сильнее в большинстве случаев. Мне бы такой алгоритм не хотелось применять, где L остается неизменной в ущерб chroma, я лучше оба параметра ужму понемногу чем по много только chroma, и вполне штатно.
 
Топикстартер, по сути, хочет натянуть на глобус пр..острансво Lab. '))'
При подобном преобразовании, все прямые, параллельные L будут выходить из одного полюса (0,0,0) и заканчиватьcя в противоположном полюсе (1,1,1) Я не вижу принципиальных препятствий сделать подобное преобразование даже с гаммой sRGB, но будет ли оно лучше существующего? Очень сомнительно, поскольку в светах и тенях цвет будет искажаться достаточно неприятно.
 
К сожалению - хотелось бы так, но фотошоп несколько глупее чем мы о нем думаем. Он умудряется именно что в RGB проделывать такие операции, которые в RGB проделывать нельзя. Простой пример - изменение размера изображения. Нарисуем 2 серых пикселя в модели Lab: L=20 и L=80, уменьшим картинку до 1 пикселя, получим L=50. Проделаем то же самое в модели RGB - получим пиксел L=52. Фотошоп не может даже проделать простого масштабирования правильно в формате RGB - перевирает цвета.
Все тут правильно делает ФШ.
Он делает операцию в том режиме, каком ему сказали. Если RGB - значит RGB, если Lab - значит Lab.
Так и должно быть.
 
Все тут правильно делает ФШ.
Не совсем. Он правильно делает в режиме RGB с гаммой 1, а вот с любой другой другой гаммой - неправильно, применяет математику к нелинейным значениям так, словно к линейным. Впрочем этот колориметрический волюнтаризм в фотошопе давно и не мной подмечен.
 
Это не ошибка, а общепринятая практика. Это нормально.
Учитывать гамму можно, если того хочется или требует задача, но опционально.
Иными словами, можно и так, и так, и оба варианта по-своему верны.
 
Учитывать гамму можно, если того хочется или требует задача, но опционально.
Иными словами, можно и так, и так, и оба варианта по-своему верны.
Задача на самом деле колориметрически пустяковая - найти среднее значение между светлотой 20 и светлотой 80 на равноконтрастной шкале от 0 до 100 с равными делениями. Математика начальных классов подсказывает, что среднее значение равно (20+80)/2=50. Если это простое уравнение не выполняется по какой-то причине - мы имеем дело с колориметрической ошибкой, а не с "по-своему верными" вариантами. С одной гаммой фотошоп даст ответ = 52, с другой = 61, с третьей гаммой - еще какое-нибудь. В чем "верность" этих вариантов не возьму в толк? Я утверждаю, что колориметрически ответ, отличный от =50 - не верен. Колориметрически не верен, ни по своему, никак, цвет неправильный посчитан. Расскажите, в какой системе координат он верен, если правильный цвет уже не интересен? В линейном усреднении нелинейных значений? Так тоже нельзя не только колориметрически, но и математически.
 
В защиту фотошопа можно лишь сказать, что старый ACDsee и новый FastStone так же справляются с задачей колориметрически неверно. Причем все три программы неверно по-разному:-) Так что "нормальной общепринятой практики" я не уловил пока в этих разных ошибках.
 
Задача на самом деле колориметрически пустяковая - найти среднее значение между светлотой 20 и светлотой 80 на равноконтрастной шкале от 0 до 100 с равными делениями. Математика начальных классов подсказывает, что среднее значение равно (20+80)/2=50.
А "нет" там никакой светлоты. И равноконтрастной шкалы тоже "нет".
Там есть красный, зеленый и синий каналы - точка. Именно с ними работает пользователь и ожидает от них (тоже на основе своих школьных знаний математики) вполне определенного результата = (R1 + R2)/2.

А если некому пользователю, обременённому дополнительными знаниями, эта система координат не нравится - пожалуйста, переходим в Lab, и там всё будет.

И это правильно, потому что если мы выбрали такую систему координат (со всеми её упрощениями и особенностями), то и работаем в ней, не пытаясь неявно выскочить куда-то в другое измерение. Результат смешивания Lab тоже не совпадет с, например, LCh - но это не баг, это фича.
 
Идею понял - если выскочила цветовая ошибка - называем ее фичей. Другую ошибку с другой гаммой - другой фичей. Составляющих цвета в RGB нет - есть только каналы, удобно. Тут еще обычно следует совет поотключать все цветовые профили и наслаждаться чистой поканальной математикой. Раз нельзя в пространстве RGB показать "никакой светлоты" правильно?
С Lab и LCh неверный пример - они дадут одинаковый результат усреднения светлот.
Есть еще кстати вариант верно посчитать среднее по цвету - в пространстве xyY. Все руки не доходят вписать эту формулу в бинирование.
 
Впрочем проверил про xyY, вношу поправку: в XYZ и xyY можно правильно просуммировать световой поток - например микс из нескольких по оттенку и яркости светодиодов. Такая арифметика ведет себя абсолютно корректно и суммировать надо именно в XYZ, в Lab этого нельзя правильно сделать. А вот вычислить корректно среднее значение цвета в пространстве XYZ нельзя, как и в его RGB представлении, придется переходить в Lab. Или я просто как и в фотошопе не знаю верной формулы. Предполагаю что ее нет.
 
Идею понял - если выскочила цветовая ошибка - называем ее фичей.
Не ошибка, а погрешность. Это разные вещи.
Погрешность отличается от ошибки в том, что она осознаваема и, в какой-то мере, признана приемлемой на практике.
Потому что в противном случае тысячи пользователей стали бы возмущаться, что среднее арфиметическое не равно среднему арифметическому. Они ожидают именно такой результат, и он их устраивает. А авторы ФШ не ошиблись, а пошли на сознательный компромисс.
Для продвинутых - есть отдельные галки в настройках и специальные пространства.

С Lab и LCh неверный пример - они дадут одинаковый результат усреднения светлот.
А цвета в целом - неодинаковый. Так что пример нормальный.
 
Нет, пример не нормальный. Оставшиеся детали цвета кроме светлоты - насыщенность и тон - будут так же одинаково и правильно усреднены в моделях Lab и LCh, правильно в обоих случаях. "Результат смешивания" в этих моделях будет одинаковым, потому что это фактически одна и та же модель, просто немного в различном численном представлении.
Вчера ошибка фотошопа была фичей и общепринятой практикой, сегодня стала погрешностью и сознательным компромиссом, хорошо что у фотошопа появился адвокат-софист, мне тоже нравится этот софт:-) Кто больше сможет придумать эвфемизмов для фразы "колориметрическая ошибка"?
Какую колориметрическую погрешность в 8 битах мы в таком случае будем считать в фотошопе допустимой? Когда фотошоп выдает в лабе вместо 44.4 только 44 а вместо 44.6 выдает 45 - это погрешность. Когда фотошоп по лабу в 8 битах вместо 50 выдает 52 или 61 или 81 - мой жизненный опыт не позволяет называть эту ошибку погрешностью при дискретности 8 бит. Лучше давайте на фиче остановимся:-) Дельта 2, 10, 20 - все это выше погрешности вычислений. Но соглашусь в фотошопе на погрешность с дельтой до 0,5.
По поводу общепринятой практики я кстати так и не получил ответа - какие еще программы делают при усреднении такие же ошибки, как фотошоп? По моим наблюдениям другие программы при выполнении той же задачи усреднения цвета двух соседних пикселов в пространстве RGB делают другие колориметрические ошибки. В контексте наплевательского отношения к колориметрии я не против называть эти ошибки фичами в юмористическом ключе, но неправильное решение уравнения со всеми известными переменными не подпадает под определение "погрешность".
И уж точно обычные пользователи ждут от графического редактора правильного цвета, и в последнюю очередь ждут среднего арифметического двух значений на нелинейной степенной шкале. Зачем им нужно это среднее арифместическое при обработке фоток, если даже с точки зрения математики некорректно так усреднять нелинейные величины?
 
Оставшиеся детали цвета кроме светлоты - насыщенность и тон - будут так же одинаково и правильно усреднены в моделях Lab и LCh, правильно в обоих случаях.
Будет не одинаково. Но в обоих случаях - условно-правильно :)

Когда фотошоп по лабу в 8 битах вместо 50 выдает 52 или 61 или 81
Опять 25. Ключевое слово - в лабе! Вот когда мы будем работать с файлом в лабе, тогда и будем мерить лабовским аршином, там это будет обосновано. А когда мы в ргб, то мы про лаб вообще знать не обязаны (если только явным образом не указано иное). Если я захожу в магазин и там ценники в рублях, то все расчеты могут быть только в рублях. Нельзя требовать на кассе распечатать чек с ценами в баррелях нефти.

Дельта 2, 10, 20 - все это выше погрешности вычислений.
Я говорил не про вычислительную погрешность, а погрешность системы координат, модели - называйте как угодно.

По поводу общепринятой практики я кстати так и не получил ответа - какие еще программы делают при усреднении такие же ошибки, как фотошоп?
В любом софте, любых программных библиотеках (да хоть html canvas, хоть OpenGL) к качестве базового варианта идет обычная линейная интерполяция в rgb. Никто в lab или xyz не пересчитывает. Опционально разработчики могут применить кубические сплайны, Ланцоша, всевозможные фильтры четкости, преобразование Фурье и ещё миллион вариантов, только к колориметрии прямого отношения это уже не имеет. Видимо, оттуда и идут различия, которые вам не дают покоя.
 
Статус
Закрыто для дальнейших ответов.