Цветоделение изображений с цветовым охватом, превышающим офсетный

[colorprint]

Да такая операция будет отличаться от Saturation в Photoshop.

Да, Saturation в Photoshop в sRGB ужасный, Ваш «Saturation», намного лучше и корректней работает. Но надо заметить, что похожие (но не точно такие) результаты к Вашему «Saturation» можно достичь в Photoshop в sRGB за счет Saturation+Vibrance или в Lab — просто Saturation или s-образная подрезка кривых в a,b — каналах.
Короче, можете смело продавать свой «Saturation» Adobe.

 

[mihas]

Посмотрел расширенные профили на предмет всяких детских болезней типа "blue turns purple" problem. К чести Фейрчайлд и CIECAM CAT02 - там конечно все это учтено. Вот расширение охвата, соответствующее профилю gamut_204%. В первой строке как отработал алгоритм, цветовой тон изменен и сильно с 292 до 301 градуса. Второй строчкой иллюстрируется blue turns purple - здесь при разной насыщенности тон остается неизменным в Lab - 301 градус. Заметно как завалился в пурпур менее насыщенный левый патч.
Так же глянул и на другие изогнутые тоновые лучи и от Muncell и от Ebner (F. Ebner and M.D. Fairchild, "Finding Constant Hue Surfaces in Color Space", SPIE/IS&T Electronic Imaging, (1998).) при их расширении в охвате. Из этих таблиц достаточно сложно выбрать нужные данные (но я выбрал!), поэтому так же воспользовался линдблумовским профилем по совету @TRANTOR - Uniform Perceptual Lab ICC profile отсюда http://brucelindbloom.com/UPLab.html на основе данных Muncell. Вроде на вскидку все загогулины при "раздутии" охвата выглядят корректно, причем как я понимаю тоновые "изгибы" пространства CIECAM CAT02 сделаны по более свежим данным Ebner а не по Muncell:

 

[colorprint]

Mihas, а сделать плугин Saturation (SIECAM CAT02) для фотошопа ( с ползунком) возможно?

 

[mihas]

Лучше с ползункАМИ Я не умею пока плугины, но разумеется возможно, алгоритм на очень простом языке в виде макроса прописан в Excel на Visual Basic - http://rudtp.pp.ru/pdf/CIECAM02function.xls
Я его на JavaScript перевел именно отсюда. На JavaScript алгоритм работает здесь: http://rudtp.pp.ru/spectralcalc.php Добавил кстати визуализацию и генерацию tif-мишеней кроме sRGB еще Adobe RGB и ProPhoto RGB - а то на огромных охватах в маленьком sRGB ничего не понятно. Конечно надо уметь работать с цифрами цвета но мне пока все же нравится и визуально в том числе контролировать результаты вычислений. Хотя на огромных охватах не все можно реально увидеть - монитор не позволит. Жаль кстати, что элементам html-разметки нельзя цветовой профиль icc присвоить, как присваивается картинкам.

 

[mihas]

переделить из CMYK с расширенным охватом в стандартный ISO_coated по Perceptual?

Собственно ответ, почему именно так хорошо, как обычно лежал на поверхности, а я мимо проходил. @sabos помог разобраться. Тут дело не в фотошопе а в том, что разумеется перцепционные таблицы разных профилей разные и перцепция из большого профиля RGB заметно отличается от перцепции из большого профиля CMYK. Отсюда и заметная разница, хотя оба профиля сжимают в лаб, но просто сжимают по разным таблицам, заключенным в эти профили. Так что тут причина неплохого результата не только в алгоритме CIECAM CAT02, но и в профилировщике Heidelverg Color Tool и его перцепционной таблице расширенного CMYK профиля. Вообще думаю эти таблицы стандартных профилей RGB tristimulus systems очень примитивны, нельзя в несколько килобайт что-то сложное уместить, там похоже кроме колорантов и кривых TRC ничего и нет особо.

 

[TRANTOR]

В TRC (которые обычно v2, кстати), нет вообще никаких таблиц LUT. Если нужно делать что-то эдакое, то нужно его делать, пардон за тавтологию. Т.е. они должны быть с CLUT (A2B, B2A итд).

 

[mihas]

Тогда кстати возникает вопрос - если как мы видем в tristimulus system профилях вообще нет таблиц A2B, B2A - кто же тогда перцепционно сжимает? Сам фотошоп додумывает за профиль? Потому что вот на вскидку разница в перцепционном сжатии разумеется есть при конверсии из большого CMYK профиля с нужными таблицами и из ProPhoto RGB без этих перцепционных таблиц:

Хорошо видно, что изначальный зеленый с тоном 160° в одном случае при сжатии Chroma изменил тон на 159° а в другом на 166°, синий исходный 306° в одном случае изменил тон на 290° а в другом на 297°. Это большие заметные глазом разночтения, причем в случае с перцепцией и ProPhoto RGB фотошоп похоже "перебдел" над проблемой blue turns purple и сделал из синего конкретно голубой - на 16° тон двинул (в цмике только на 9° - синий синим остался).

 

[TRANTOR]

кто же тогда перцепционно сжимает?

А никто. Нет перцептуальной конверсии в TRC-профилях. Только relative и absolute.

при конверсии из большого CMYK профиля

Не не. Lab<->RGB исключительно. Я специально проверял - чуда не происходит. Если брать RGB профиль с соответствующим CLUT, то да, другое дело. На сайте ICC (color.org) есть несколько таких.

 

[mihas]

чуда не происходит.

Да я так вроде соглашусь - тем не менее в фотошопе прекрасно видна разница при конверсии из TRC ProPhoto в маленький охват по relative и по perceptual. Просто я вот когда специально подменял в профиле нужные таблицы - например давал ссылку на одну во всех случаях - так и отрабатывалось - чего не выбери в фотошопе а результат одинаковый. А тут-то результат разный хотя таблицы perceptual нет вообще. Все же кто-то додумывает.

 

[TRANTOR]

в фотошопе прекрасно видна разница при конверсии из TRC ProPhoto в маленький охват по relative и по perceptual

Не соглашусь, однако. Разницы нет.

В качестве иллюстрации: http://forum.rudtp.ru/resources/sravnenie-relative-i-perceptual.571/

Внутри:
Lab.tif - исходное изображение
sRGB_Rel.tif - конверсия в стандартный sRGB по relative
sRGB_Perc.tif - конверсия в стандартный sRGB по perceptual
sRGBv4_Perc_Real.tif - конверсия с помощью профиля sRGB_ICC_v4_appearance_beta_displayclass.icc

Как видно, разницы в случае TRC-профиля никакой. Зато в случае специального профиля результат налицо.

 

[mihas]

А спасибо, все понял. Разницы нет, когда и destination профиль тоже TRC. Когда в офсетный профиль конвертишь из TRC - есть. То есть это вносит уже в цвет перцепционные коррективы не профиль из которого конвертишь а профиль назначения.

 

[TRANTOR]

Чтобы путаницу не создавать, лучше рассматривать не кучу конверсий "профиль -> PCS -> профиль", а отдельные звенья вида "PCS -> профиль". Тогда проще понять, на каком этапе возникает неопределенность. Был бы в экспериментах задействован device-link, то тогда да - получится один шаг "профиль -> профиль".

 

[TRANTOR]

Когда в офсетный профиль конвертишь из TRC - есть

Сейчас проверил: не важно, откуда. Из Lab'а в обычный ISO ECI разный результат, да.

 

[mihas]

Сейчас проверил: не важно, откуда.

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

 

[mihas]

Чтобы путаницу не создавать, лучше рассматривать не кучу конверсий "профиль -> PCS -> профиль", а отдельные звенья вида "PCS -> профиль".

Согласен, так и буду делать в будущем, спасибо. То есть практически - выбираем один из профилей CLUT второй TRC - соответственно видим как работает перцепция чисто CLUT одного профиля, будь он хоть source хоть destination, а не связки двух профилей CLUT.

 

[TRANTOR]

Из большого цмика в маленький TRC RGB - перцепция и колориметрия разные результаты дают

Безотносительно целевого RGB, уже в Lab (считай PCS) разные. Это, опять же, потому, что данный CMYK-профиль не TRC и позволяет как perceprual, так и colorimetric. Ну не может TRC perceptual и все тут. Не предназначен.

Можете проверить сами:

1. Из CMYK CLUT в Lab прямо в окне конверсии (с отмеченной птицей preview) переключать perceptual/colorimetric.
2. То же самое там же из Lab в CMYK CLUT.

а не связки двух профилей CLUT

Да. Всегда останавливаемся на Lab'е. В случае двух CLUT будет две конверсии перцептуальных (если выбрано), двойная путаница.

 

[TRANTOR]

Понятное дело, что если у нас LUT-таблица задана не как перцептуальная конверсия, а как колориметрическая, то результат будет колориметрическим.

Обычно колориметрическим считается L=const, H=const (уже повторяюсь, скорее всего). Работаем только с хромой, таким образом. Вот ее степень компрессии и алгоритм этой компрессии могут быть разными (зависимость от H, от L, от обоих, форма компрессии, зависимость от разницы целевого и исходного охватов по хроме итд итп).

 

[mihas]

Всегда останавливаемся на Lab'е. В случае двух CLUT будет две конверсии перцептуальных (если выбрано), двойная путаница.

Все же не на Lab-е - в него никаких компрессий не будет, зачем в Lab сжимать если он считай внеохватный. Я так понимаю надо остановиться на связке профилей CLUT-TRC - тогда мы увидим, как действует всего одна перцепция одного CLUT профиля.

 

[TRANTOR]

в него никаких компрессий не будет

Будет. Зуб даю. Толко не компрессия, а обратное действие, декомпрессия, если можно так выразиться.

в Lab сжимать

Только не сжимать, а разжимать. Обратная конверсия по перцепции, B2A же действует. Можете сами проверить.

Разумеется, что оно не станет в точности таким, как было до компрессии. Плюс всякие ошибки накапливаются, постеризация лезет, то-се.

 

[mihas]

Да убедился, действует перцепция. Но она абстрактная какая-то при конверсии в Lab!-) Как-то мне понятнее идея, когда целевой охват обозначен все же TRC профилем!
И не знаете еще смысл того что Линдблум намудрил с профилем UPLab? Там же не просто тоновые прямые превращаются в кривые как положено, они еще градусов на 30-40 сдвигаются, и это мне уже совсем не понятно. Я в колорлабе конвертил из абстрактного D50LAB профиля. Может как-то что-то иначе надо делать?