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

Привет всем!
Я тут наткнулся на сайт одного нашего северного соседа - финна 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

Ответ: Линейные 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?

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

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

1.

atutubalin сказал(а):

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

Во втором случае у нас нигде исходник в линейных 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 близка к средней "комфортной" гамме и видимо я с ней и продолжу по жизни.
Еще раз всем спасибо.