Линейные RGB пространства

[4AlexK]

Привет всем!
Я тут наткнулся на сайт одного нашего северного соседа - финна Timo Autiokari : http://www.aim-dtp.net (Accurate Image Matching). Там активно рекомендуется использовать линейное (= не корректированное по Gamma) пространство RGB в качестве рабочего пространства для обработки цветных цифровых изображений. Профили линейных пространств можно скачать там же с сайта. В качестве основных аргументов приводятся следующие:
1. Сенсоры сканеров и цифровых фотоаппаратов по сути линейны, перевод информации снятой с матриц этих устройств в Gamma-зависимое RGB пространство приводит к потере информации. Ситуация не так драматична при работе в 16 бит/канал, при 8 бит/канал все просто ужасно - около 25% градаций исчезает
2. Работа по коррекции изображения (например применение фильтров в Photosop-е) зачастую не учитывает нелинейность стандартного пространсва RGB. В результате "математика кривая" как не раз было замечено на этом форуме. Кстати на сайте достаточно много примеров "кривой математики" фотошопа и доказательств того что при работе в линейном пространстве этих граблей существенно меньше.
3. Принтеры не являются Gamma- устройствами хотя и они и нелинейны. В любом случае корректировка изображения под гамму монитора/характеристику принтера при работе в линейном пространстве намного корректнее нежели постоянная работа в гамма-корректированном пространстве.
Так как я совсем новичек в ColorManagement, хотелось бы услышать мнение уважаемых Гуру этого форума по поводу резонности работы в линейном RGB пространстве.
AlexK

 

[atutubalin]

Ответ: Линейные RGB пространства

Привет всем!
Я тут наткнулся на сайт одного нашего северного соседа - финна Timo Autiokari :
1. Сенсоры сканеров и цифровых фотоаппаратов по сути линейны, перевод информации снятой с матриц этих устройств в Gamma-зависимое RGB пространство приводит к потере информации. Ситуация не так драматична при работе в 16 бит/канал, при 8 бит/канал все просто ужасно - около 25% градаций исчезает

Я вот оставил только один пункт, потому что его проще критиковать .
Если мы работаем в линейном пространстве в 8 битах, то у нас и так полная катастрофа в тенях и избыточная точность в цветах. А если мы работаем в 16 битах, то число градаций при не слишком большом количестве преобразований - достаточно.

К творению Timo нужно относиться крайне аккуратно - там есть немалое количество верных идей, которые стоит принять к сведению, но при этом верить всему не следует (соответственно, в проблеме стоит разбираться).

 

[Igor Bon]

Ответ: Линейные RGB пространства

Просто надо разобраться: какие задачи решает Гамма абстрактного RGB пространства и тогда станут ясны заблуждения финского товарища.
Гамма монитора компенсирована Гамма коррекцией "прописанной" в профиле монитора - в итоге мы имеем линейную систему визуализации, Гамма RGB пространства вносит в эту систему искажения - зачем? А не для компенсации ли нелинейности зрительного восприятия?


Не по теме:
Потери, потери, потери - 16 , 48, 64 бит - плохому танцору всё время нужны оправдания и объяснения своих неудач.

 

[4AlexK]

Ответ: Линейные RGB пространства

Гамма монитора компенсирована Гамма коррекцией "прописанной" в профиле монитора - в итоге мы имеем линейную систему визуализации, Гамма RGB пространства вносит в эту систему искажения - зачем? А не для компенсации ли нелинейности зрительного восприятия?

1. Насколько я понимаю, Гамма в RGB пространства оригинально добавилась как раз для того чтобы частично компенсировать свойства мониторов, чтобы JPEG в любых браузерах смотрелся более менее прилично и без всяких профилей, которые были реализованы позднее нежели определена гамма для RGB пространств. Отсюда и значение гаммы в RGB пространстве - 2.2 (среднее между PC 2.5 и Mac 1.8). Компенсация нелинейности зрительного восприятия тут не при чем.
2. Зрительное восприятие действительно нелинейно. На сайте Timo есть несколько страниц посвященных Perceptually Uniform Space. (например http://www.aim-dtp.net/aim/ ; http://www.aim-dtp.net/aim/evaluation/perception/perception.htm). По его оценкам если вводить поправки на человеческое зрение именно функцией гаммы, то Perceptually Uniform гамма - 1.25, что куда ближе к линейному пространству нежели к 2.2 в стандартном RGB.
3. На настоящий момент, когда стал доступен нормальный ColorManagement, выбор рабочего пространства не завязан напрямую с нелинейностью восприятия или проблемами физических особенностей мониторов. Выбор рабочего пространства скорее должен обеспечивать корректость работы различного рода преобразований, выполняемых в нем и минимум потерь при переходах из этого пространства в любые другие и из других в него. Также существует проблема наличия достаточного количесва градаций в тенях\светах для представления свойств объектов. Понятно, что корректную математику можно реализовать в любом пространстве - достаточно просто учитывать пространственные характеристики. Проблема в том что как показывают экперименты Тимо, такого рода математика реализована далеко не везде. Корректность переводов из одного пространства в другое обеспечиваются повышением битности вычислений (кстати, я слышал что в новом Фотошопе битность достигает 32?!). Кстати, на том же сайте приводится пример некорректной работы AdobeACE engine по сравнению с MicrosoftICM (см. http://www.aim-dtp.net/aim/photoshop/v6/slope-limiting/index.htm). Проблема количества градаций решается повышением битности хранимых данных.
Так не стоит ли все таки перейти на линейное рабочее пространство просто чтобы не иметь граблей с существующей математикой? Или может имеет смысл работать в Perceptually Uniform пространстве с гаммой 1.25?

 

[atutubalin]

Ответ: Линейные RGB пространства

1. Насколько я понимаю, Гамма в RGB пространства оригинально добавилась как раз для того чтобы частично компенсировать свойства мониторов, чтобы JPEG в любых браузерах смотрелся более

Тут много наворочено, но принципиально вот что:
1) зрение нелинейно. Т.е. чувствительность "к ступеньке" в тенях выше (в абсолютных величинах) чем в светах. В тенях мы прекрасно отличим значения 10 и 11 (в любых линеных единицах - это 10% разницы по яркости) а в светах 255 и 254 - не отличим (0.4% разницы).
2) Если бы мы работали с бесконечной точностью - было бы наплевать. Но точность конечна и для 8 бит мы вынуждены использовать нелинейную шкалу по причине, описанной двумя сообщениями выше.

2. Зрительное восприятие действительно нелинейно. На сайте Timo есть несколько страниц посвященных Perceptually Uniform Space. (например http://www.aim-dtp.net/aim/ ; http://www.aim-dtp.net/aim/evaluation/perception/perception.htm). По его оценкам если вводить поправки на человеческое зрение именно функцией гаммы, то Perceptually Uniform гамма - 1.25, что куда ближе к линейному пространству нежели к 2.2 в стандартном RGB.

Я же говорил, что Тимо заносит. Perceptually Uniform - это линейное по L (в Lab-координатах). Постройте шкалку с L=10,20,...100 посмотрите.

L от яркости зависит как корень кубический т.е. гамма=3. В sRGB принята более сложная гамма-кривая (линейная на старте, а дальше 2.2), она очень близка к зависимости L(Y).

Так не стоит ли все таки перейти на линейное рабочее пространство просто чтобы не иметь граблей с существующей математикой? Или может имеет смысл работать в Perceptually Uniform пространстве с гаммой 1.25?

Еще раз. Если работать в 8 битах, то в линейном пространстве и в гамме 1.25 у вас будут проблемы в тенях. Если работать в 16 битах - то более-менее пофиг. То же относится к хранению.

Возьмите линейное RGB-пространство, постройте там серую шкалу в тенях (в 8 битах) и посмотрите на размер ступеньки по L - удивитесь.

 

[german]

Ответ: Линейные RGB пространства

Или может имеет смысл работать в Perceptually Uniform пространстве с гаммой 1.25?

Я бы не отказался, если бы он был реализован. Линейное пространство...заманчиво

 

[Igor Bon]

Ответ: Линейные RGB пространства

В линейном? или в равноконтрастном?

 

[Alexey Shadrin]

Ответ: Линейные RGB пространства

Коллеги!
Ну что же мы опять-то возвращаемся к давно пройденной теме? :cry:
Ох...
* * *
Думаю, не нарушу контракт, если выложу короткую главу из книги по мониторам -- пусть она будет для издателей как бы рекламой, тем паче, что сугубо теоретическая.
И давайте закроем этот дурацкий вопрос.
Алексей.

 

[Alexey Shadrin]

Ответ: Линейные RGB пространства

А не для компенсации ли нелинейности зрительного восприятия?

Позволю себе теоретическую придирку: зрение совершенно. Раз оно нелинейно -- значит так надо и биологически оправданно, и компенсировать тут нечего и незачем . Критерий совершенства: факт существования человека, как биологического вида. Задача зрения -- обеспечить выживание.
Поэтому компенсируем мы ну никак не нелинейность зрения. Компенсируем мы гамму предыскажения, введенную в в 80-х годах прошлого столетия (!!!) из-за априорной ублюдочности и хилости 8-битных систем оцифровки -- компьютеры были так слабы, что 16 или даже 10 бит были просто неосуществимы. Вводя гамму-предыскажения мы сознательно уменьшали шаг дискретизации в низких энергиях (тени), отбирая шаги у светов, потому что в тенях видим больше градаций (и хрен с ними со светами). То есть, вводя гамму, мы смещали вниз если угодно "плотность" (специально взято в кавычки) энергетического кодирования .
Сейчас, когда и 32 бита в машинном смысле не Бог весть что -- о гамме можно и нужно просто забыть. Но если она присутствует -- "фиолетово" (как говорят подростки).

Не по теме:
Потери, потери, потери - 16 , 48, 64 бит - плохому танцору всё время нужны оправдания и объяснения своих неудач.

Потери в 8-битных изображениях возникают (и очень существенные) при "тяжелой" ЦВЕТОКОРРЕКЦИИ. Игорь, возьмите 8-битный скан и залудите серьезную корректирующую кривую, а потом посмотрите гистограмму: от градаций останется один "забор". Две-три таких кривые и изображение "выхолостится" -- что сразу станет видно даже на плохоньком мониторе. С 16-битным (даже с 12-битным) такого не произойдет долго, как бы мы этому изображению ни выкручивали руки. Высокая разрядность изображения (какой-то умник обозвал её в свое время "глубиной цвета" -- уши бы надрать) нужна для коррекции в лоне цифровой системы.

 

[Alexey Shadrin]

Ответ: Линейные RGB пространства

В чем прав "горячий финский парень"? В том, что ежели работаешь в 16-битах, то абстрактный колориметр может иметь гамму 1. Ради Бога. Сваять такой колориметр -- дело одной минуты: Custom RGB. (Герман -- здесь никакитх векторов сжатия нет, это не Lab, здесь gamut clipping и бояться нечего -- ваяй, если хочешь ). No Problem.
В чем неправ "горячий финский парень"? В том, что ежели некая гамма заложена в абстрактный колориметр (как, скажем в Adobe RGB, sRGB и проч.) -- то беды в том, ну никакой решительно нет.
Таким образом, проблемы (при 16 битах) как таковой фактически не существует.

 

[Harlequin]

Ответ: Линейные RGB пространства

Алексей, а я так понял, что стоит вопрос о корректности расчетов Photoshop в зависимости от нелинейности конкретного RGB. То есть, проблема техническая - расчет коррекций производится не в Lab, а в текущах RGB-координатах.

 

[Alexey Shadrin]

Ответ: Линейные RGB пространства

Алексей, а я так понял, что стоит вопрос о корректности расчетов Photoshop в зависимости от нелинейности конкретного RGB. То есть, проблема техническая - расчет коррекций производится не в Lab, а в текущах RGB-координатах.

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

 

[Harlequin]

Ответ: Линейные RGB пространства

Я несколько другое имел в виду. Например, результат коррекции HSL будет зависеть от нелинейности конкретного RGB. А, казалось бы, зачем?..

 

[atutubalin]

Ответ: Линейные RGB пространства

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

Нет таких крепостей, которых не взяли бы большевики.

Берете файл в линейном пространстве (RAW-данные со сканера), лучше
если это слайд с густыми тенями.
16-битный файл, естественно.

И делаете с ним одну и ту же операцию 4-мя разными способами
1) Гамма-коррекция через levels
2) гамма-коррекция через загрузку кривой из 256 точек
3) гамма-коррекция через assign profile с gamma 1 (Custom RGB) и convert to profile
4) гамма-коррекция программой, про которую известно что она делает (ImageMagick, можно исходные тексты почитать и убедиться что делается все правильно)

И смотрите разницу. Ее не должно бы быть, но она есть, levels дают ужасающие результаты, кривые - лучше. Прогонка через ICM дает результаты с практической точки зрения неотличимые от правильного (IM) вычисления.

Disclaimer. На первый взгляд, в CS2 с levels получше чем раньше.

 

[Alexey Shadrin]

Ответ: Линейные RGB пространства


Не по теме:
Кстати, CS2 наконец-то стал печатать большие форматы.

 

[Glutton]

Ответ: Линейные RGB пространства

Картины в студию!

 

[Igor Bon]

Ответ: Линейные RGB пространства

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

 

[atutubalin]

Ответ: Линейные RGB пространства

Второй файл (впрочем как и исходник 8 бит) и обработан в 8 битах, так что выполнение сложной коррекции не зависит от глубины цвета (действительно дурацкий термин)

Естественно, если у вас есть 8-битный исходник в линейном пространстве, то ничего хорошего из него уже не сделать.

Вопрос же не такой простой (про исходник в 8 битах).
Если у нас CCD(/CMOS)-сенсор, то он линеен. Если ФЭУ (на барабаннике), то конечно можно для каждой точки играться напряжением на умножителе (не уверен что так делают).

А дальше встает вопрос "где делается гамма-конверсия". Вариантов несколько
* сначала линейная оцифровка, гамма-конверсия делается "в цифре"
* в АЦП загнали нелинейную таблицу

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

 

[4AlexK]

Ответ: Линейные RGB пространства

Привет всем опять. Ну вроде немного мне попонятнее стало, спасибо всем откликнувшемся.

1.

А дальше встает вопрос "где делается гамма-конверсия". Вариантов несколько
* сначала линейная оцифровка, гамма-конверсия делается "в цифре"
* в АЦП загнали нелинейную таблицу

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

Как мне кажется, второй вариант встречается на практике редко. Поэтому если говорить о наиболее корректной в практическом смысле работе с цифровыми данными полученными от линейных устройств (raw файлов со сканеров и ЦФК), то даже при 16 битной изначальной оцифровке конвертирование из линейного пространства в гамма-зависимое лучше доверять проверенным средствам (типа конверсия через профайлы проверенным enginе-ом). Это связано не с теоретической необходимостью иметь достаточное количество градаций в тенях\светах а с тем обстоятельством, что алгоритмы многих Raw конвертеров выдают достаточное количество ошибок при подобном переходе (даже ФШоп не идеал в данном случае - см пост выше). При оригинале с плотностью информации 8 бит и линейным распределением, даже самый корректный алгоритм перевода в гамма-зависимое пространство 8 бит приводит к ощутимой потере информации в светах. Поэтому выигрыш от перевода "8 бит линейных->16 бит линейных->16 бит гамма зависимых" а не "8 бит линейных->8 бит гамма зависимых->16 бит гамма зависимых" огромен и если нет возможности стазу получить 16 линейных бит (что сейчас уже редкость), то лучше уж снять 8 линейных бит и аккуратненько их конвертировать. В этом смысле Тимо прав, деваться некуда.

2. По поводу выбора гаммы рабочего пространства. Мне тут пришла такая мысль в голову. Раз при 16 битах градаций хватает с лихвой, то проблема выбора гаммы рабочего пространства скорее базируется не на параметрах точности описания градаций, а больше на корректности работы математики и простой комфортности для человека (типа привычка). Корректность работы алгоритмов нужно проверять. На мой взгляд, существует огромное количество софта который просто не приспособлен для работы в линейном пространстве, т.к. разработчики оного вообще не были в курсе что такоt Color Management. Возможно и обратное - некоторый софт будет корректнее работать в линейном пространстве, действительно хорошему софту будет пофиг - если люди грамотные то и проблем не будет. Правда опыт показывает что грамотных меньшинство. Я тут например попробовал убрать шум Neat-ой в линейном файле, - эффективность этого плагина сильно уменьшилась, теперь буду это делать только в гамма-зависимом пространстве. При необходимости использовать софт, корректно работающий в только в определенном пространстве, всегда можно конвертировать сначала в него, обработать, потом перевести назад. При ограниченном количестве конверсий плотности 16 бит за глаза хватит чтобы не почувствовать этих операций.
3. Серьезным аргументом при выборе рабочего пространства может служить простая привычка людей, привыкших к некоторого рода плотности цифровых данных для определенного участка тонов. Например, я привык контролировать распределение тонов на фотографии по гистограмме в AdobeRGB (гамма 2.2) и как только у меня образуется отвесная стенка в тенях/светах, я начинаю беспокоиться. Поэтому практическая проблема линейного пространства для меня - невозможость корректно проконтроллировать по гистограмме когда пошел клиппинг. При этом параметр наиболее "комфортной" с этой точки зрения гаммы для рабочего пространства может зависеть от конкретного изображения - при работе в высоком ключе комфортнее работать с меньшей гаммой, при низком - с большей. Видимо 2.2 близка к средней "комфортной" гамме и видимо я с ней и продолжу по жизни.
Еще раз всем спасибо.

 

[Alexey Shadrin]

Ответ: Линейные RGB пространства

Видимо 2.2 близка к средней "комфортной" гамме и видимо я с ней и продолжу по жизни.
Еще раз всем спасибо.

Ну, и с Богом. Никаких противопоказаний нет. Главное, что у Вас есть -- это четкое ПОНИМАНИЕ ситуации.
Аминь.