Управление цветом в Lightroom 3.2

[ispirato.md]

А рабочее пространство в эксперименте каким было? В Lightroom 3 это ProPhoto RGB, его изменить нельзя. А какое пространство у вас в Photoshop CS5 (наверное имелось ввиду ACR 6)?

ЦС 5 перед тем как открыть фаил спрашивает использовать встроенный профиль или преобразовать цвета в рабочее пространство 3 вариант мы нерассматриваем. я оставляю встроенный профиль. дабы не преобразовывать сРГБ в АдобРГБ

[maveryck]

В принципе вы уже почти разобрались с этой бедой, в подтверждение ваших слов: http://svetlayakomnata.ru/?p=1357

[Julysha]

Мне кажется, что лайтрум показывает гистограмму применительно к ProPhoto RGB. То есть как бы она выглядела, если бы текущий файл был сконверчён в пространство профото. Есс-но, что какой бы sRGB не был насыщенный по каналам, для пространства ПроФото всегда наёдётся запас. Фотошоп показывает гистограмму текущего пространства, вот тут и появляются перенасыщения.

Ремарка по поводу цветов С1 и С2, различающихся в широком и выпадающих за гамут узкого пространства. Эта ситуация возможна в случае полного игнорирования СМS, когда координаты будут использованы без изменения. "Калиброваный монитор" по-умолчанию означает работу в рамках CMS, что, в свою очередь, означает интерполяцию обоих цветов в зауженное пространство с сохранением какой-то разницы. То есть даже работая в профото, мы будем видеть какую-то там разницу на sRGB мониторе. НО! Необходимо понимать, что эта разница будет максимально сохранена при использовании алгоритма сжатия цветов "перцепционный" и, скорее всего, аннулирована при использовании "абсолютного колориметрического" метода сжатия. В последнем случае гамутовые цвета будут отображаться максимально близко к оригинальным, но все внегамутовые уплывут. В первом случае уплывут все цвета, но сохранится пропорциональность. По мне второе правильнее.

Я не работаю в Лайтрум, но в ACR принцип действия такой же. Когда там выбираешь ProPhoto, то яркие цвета отображаются адекватно, гистограмма нормальная. Меняешь пространство на Adobe RGB - и cразу видно, что участки с яркими красками тускнеют, а на гистограмме появляется клиппинг по этим каналам. Если идти дальше, сжимая пространство до sRGB, то ситуация становится еще хуже, участки с яркими красками тускнеют еще сильнее, и в них исчезают детали. Кажется, что картинку напечатали на газетной бумаге.



Монитор у меня калиброванный, но его охват заметно шире Adobe RGB.



"Перцепционный" не всегда срабатывает. Например, если нужно перевести в узкое пространство участок, в котором красные оттенки представлены координатами красного канала 253, 254, 251 соответственно в пространстве ProPhoto , то в какой цвет они переведутся? Только в 255 и в Аdobe RGB, и в sRGB. Поэтому приходится любоваться пылающими красками заката только на своем мониторе.

[Andrey]

Ремарка по поводу цветов С1 и С2, различающихся в широком и выпадающих за гамут узкого пространства. Эта ситуация возможна в случае полного игнорирования СМS, когда координаты будут использованы без изменения. "Калиброваный монитор" по-умолчанию означает работу в рамках CMS, что, в свою очередь, означает интерполяцию обоих цветов в зауженное пространство с сохранением какой-то разницы.

Это не верно, потому что:



Теорема:



Для любых пространств А и В, одно из которых вложено в другое (теорема будет работать и в более общем случае, когда мощность одного больше мощности другого), и для любого преобразования f из А в В ( f:A->B ), сушествуют точки с1 и с2 из пространства А, которые будут представлены одной точкой в пространстве В.



Док-во теоремы элементарно, но на пальцах простой пример. Пусть у Вас есть набор чисел {1,2,3,4,5} (множество А) и набор чисел {6,7,8,9} (множество В), то как бы Вы не извращались, нельзя придумать преобразование f из А в В, чтоб каждому числу из множества А соответствовало единственное число из множества В.







Ваше утверждение, собственно, как и большинства людей, не работающих с подобными алгоритмами, основано на том, что конкретное изображение из пространства А (заметьте разницу между "любое" и "конкретное"), как правило (опять же - "как правило"), не охватывает все исходное пространство и для этого конкретного изображения можно без труда найти преобразование f1, которое корректно переведет это изображение в более узкое пространство В. Т.е. для любого подмножества А1 < A (в примере с числами - любой набор чисел 1-5, содержащий не более четырех чисел), существует преобразование однозначно переводящее А1 в В.



Но, что самое главное, о чем как правило не задумываются, что все эти преобразования из подмножеств А (конкретных изображений) в более узкое пр-во В, зависят от самих изображений. Т.е. на момент написания алгоритма изображение уже должно существовать. Т.е. алгоритм должен быть "умным" и уметь подстраиваться под конкретное изображение, что увы не так.



Но, даже для самого умного алгоритма, теорема (приведенная выше), увы, верна ...



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





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

[Andrey]

плюс к этому как ни крути, а пространство sRGB пока вроде как стандарт для веба (а большинство фотографий лично у меня постится туда).

Небольшое дополнение к моей фразе о том, что "sRGB надо забыть как страшный сон" - дополнение: в качестве рабочего пространства.



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

[Andrey]

Андрей, читал это в разной литературе и в принципе на интуитивном уровне с логикой таких советов согласен. Для коррекции ProPhoto RGB очень удобное пространство, сам его некоторое время пытался использовать. Но вот проблемы итоговой конвертации из широкого пространство в гораздо более узкое в литературе как-то не освещены, ну или мне не встретилось.

Добрый день,



к сожалению, Вы правы, по крайней мере, на момент, когда я работал с аналогичными алгоритмами толковых книг на эту тему было не много.



Могу посоветовать фундаментальную книгу Salomon "Data Compression The Complete Reference", т.к. сжатие изображений - это по сути преобразование из более широкого пространства в более узкое.

И на этапе преобразования из широкого пространства в узкое у меня была масса проблем с отсечением крайних значений.

На мой взгляд, правильный алгоритм - это алгоритм способный учитывать особенности конкретного изображения, а не некий обобщенный алгоритм (см. идею "умного" алогоритма выше).



Эта идея лежит на поверхности, и почему она до сих пор не реализована (по крайней мере, мне таких алгоритмов не известно), я не знаю.



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

[Andrey]

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

Не совсем понял эту фразу.



Какая разница насколько отличаются профиль лабы и "нашего" монитора?



Лаба в любой случае сделает конвертацию из пр-ва изображения (к примеру, sRGB) в пр-во своего принтера. Это, если не стоит галочка "без коррекции", если стоит галочка, то это проблемы фотографа перевести изображение из своего рабочего пр-ва в пр-во лабы.



Кстати, это еше один аргумент, а зачем работать в sRGB, если будем печатать в "пр-ве принтера"? Может тогда сразу работать в пр-ве принтера, и так каждый раз будем переключать рабочее пр-во в пр-во каждой конкретной лабы ... Лично я, не вижу никакого смысла в этом.

[Andrey]

ПЫСЫ прилагаю пару скриншотов. первый это ТИФФ из ФШ в ЛайтРуме

Могу ошибаться, но мне кажется Вы совершаете одну ошибку:



Когда загружаемое изображение имеет встроенный профиль отличный от рабочего профиля редактора, изображение должно либо быть скоректировано в рабочее цветовое пр-во, либо рабочее цветовое пр-во должно быть изменено на "загружаемое". Иначе у Вас и изображение и гистограмы будут очень разными, т.к. числовые значения соответствующие одному пр-ву будут отображаться как числовые значения совершенно другого пр-ва, к которому они не имеют никакого отношения.



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

[Genn]

[oft]

нашел одну из ссылок на данный проект http://www.dpbestflow.org, это, как понимаю, во что превратился данный проект сейчас.

Спасибо огромное за ссылку. Отличный ресурс. Весь день читаю про различные варианты workflow и пытаюсь найти решение для себя.

[/oft]

Коллега Genn вроде бы говорил, что в последнее время использует ProPhoto RGB в качестве рабочего пространства, как ему удаётся с ним ладить не знаю?

Perceptual или Relative Colometric. Soft Proof и подстройка оттенков.

У меня положение проще - нет клиента, который может сказать что "эт-то нэ красный".

Я стараюсь не допускать клиппинга - если только это не белые облака.

Теорема:

А смысл? Мне представляется - это и так очевидно. Сразу вспоминается "зависимость длинны береговой линии от масштаба и линейки".

[Andrey]

[oft]Спасибо огромное за ссылку. Отличный ресурс. Весь день читаю про различные варианты workflow и пытаюсь найти решение для себя.[/oft]

Рад, что ссылка оказалась полезной ...



Действительно, написано толково и, по крайней мере, не вижу каких-либо явных противоречий со своими наблюдениями.



Они раньше проводили (может и сейчас проводят) бесплатные семинары, и, как раз, в Вашингтоне, но все не получалось выбраться к ним ...

А смысл? Мне представляется - это и так очевидно. Сразу вспоминается "зависимость длинны береговой линии от масштаба и линейки".

Для меня это тоже очевидно, на, как сами видите, недопонимание этого "очевидного факта" возникает постоянно на разных форумах ...