Методы Gamut-ного сжатия

Статус
Закрыто для дальнейших ответов.

Vadim_PDF

Топикстартер
15 лет на форуме
Сообщения
1 648
Реакции
237
Насколько мне известно, есть только 4 способа преобразования охвата изображения из профайла в профайл. По крайней мере так дело обстоит в основных приложениях. Цеплять сюда способы преобразования из
32-битного HDR не будем (хотя по хорошему, это тоже сюда относится)
Итак, что мы имеем? Имеем:
1 Perceptual — При этом преобразовании, если хотя бы один пиксель изображения не помещается в охват, цвета (все!) сдвигаются со своих мест в сторону потускнения (ближе к центральной оси по Lab) (я думаю
понятно, что я имеюю виду - меняют координаты цвета), даже те, которые в исходном профайле спокойно умещаются в охват того профайла в который мы преобразуем. В таком глобальном "убийстве" цвета тем не менее, есть свой смысл. Сохраняются психологические (психофизические) соотношения между цветами, и изображение в целом (по замыслу создателей этого метода) должно нами восприниматься как не потерявшее общего ощущения картинки с минимальным искажением цветов. (Здесь у меня возникает вопрос - кем просчитаны эти подвижки, на основе каких экспериментов, и почему далеко не всегда это
работает)
2 Saturation — При этом преобразовании цвета стараются стать, а не просто остаться, максимально насыщенными, даже если они в исходном изображении (например CMYK с меньшим охватом) были значительно
тускней, то при преобразовании в (допустим AdobeRGB) они станут насыщеннее по цвету "расползшись" ближе к крайним границам охвата, сохраняя при этом свой цветовой тон. Кроме того при преобразовании в
профайл с меньшим охватом могут запросто сменить (немного сдвинуть) свой цветовой тон лишь бы остаться максимально сочными (здесь вопрос номер 2 - кто-то в реальной практике использовал (использует)
этот метод?, Считается, что он подходит для деловой графики - диаграмки там, но я как-то его и для этого использовать бы не решился).
3. Relative — Если цвета в исходном изображении попадают в преобразуемый профайл то этот метод не трогает их, оставляя такими, какими они есть. Цвета которые лежат вне охвата профайла-получателя
ужимаются теряя насыщенность, но стараясь при этом сохранить светлоту. Считается, что метод довольно опасен, так как возможна (при определенном несовпадении охватов профайлов) значительная потеря
общей насыщенности изображения. Тем не менее считаю этот метод наиболее правильным, и чаще всего использую в программах его (несмотря на то что по дефолту в Adobe продуктах стоит по-моему Preceptural)
4 Absolute — насколько я понимаю, цвета меняются меньше всего. Те цвета, что попадают в охват изображения не меняются вообще, а те что "вылазят" за охват просто подводятся к ближайшей точке которая
попадает в охват (при этом может искажаться насыщенность, но тон и светлота остается неизменным. Кроме того, насколько я понял, метод преобразования учитывает точку белого (возможно и точку черного) для компенсации например желтизны или голубизны бумаги.
Правильно ли я понимаю эти методы. Если где-что не так - поправьте. Так же, хотел бы посмотреть на математические формулы преобразования что бы понять как точно оно работает.
Теперь основное, из-за чего я решил поднять эту тему. Дело в том, что для каждого изображения я выбираю метод преобразования вручную. То есть, смотрю в режиме привью что получится. Иногда даже делаю копию изображения, затем преобразую два по разным методам, а затем копирую слои в один файл и уже ластиком или в режиме LayerMask довожу изображение применяя локально где-то один метод
преобразования, где-то другой. Иногда ужимаю охват вручную в исходном изображении, контролируя через Preview (Ctrl-Y). (Речь в данном случае о Photoshop). Так вот. Есть у меня мечта, чтобы рано или
поздно в Photoshop-е появился несколько другой интерфейс управления преобразованиями.
Как я вижу его? Ну что-то вроде картинки в аттаче (это только прообраз) - когда я в трехмерном виде вижу исходное изображение в виде точек и охват профайла куда я собираюсь сжать его. При этом у меня в
руках (в курсоре) инструмент вроде пальца (Smudge Tool) из Photoshop и им я сдвигаю пиксели изображения вмещая его в охват. При этом естественно вижу контролирую преобразования изображения в окне. Это что-то вроде полностью контролируемого выбора для разных локальных областей изображения и разных цветов метода преобразования.
Может я намудрил конечно, но всех ли устраивает то, что мы имеем сейчас?. И как например гуру вгоняют в охват фото тропического заката или бирюзу тихого океана. (Просто директор фирмы, где я работаю –
путешественник, и часто из поездок привозит просто уникальные снимки с разных концов планеты, которые позже идут в печать (например на календари). И мне так искренне жаль
"убивать" цвета и изображение в целом. Но охват офсета, это охват офсета. И единственное, что я могу сделать, это попытаться создать иллюзию исходного изображения у человека, который будет рассматривать конечный продукт, например плакат. По крайней мере на своем участке допечатной подготовки
 

Вложения

  • Met.jpg
    Met.jpg
    29.6 КБ · Просм.: 686

Alexey Shadrin

Участник
Сообщения
9 260
Реакции
1 190
Ответ: Методы Gamut-ного сжатия

Vadim_PDF сказал(а):
И единственное, что я могу сделать, это
внимательно прочитать разделы, посвященные гамут мэппингу в:
1. Спецификации профайлов.
2. Моделях восприятия.
И от себя личный, но настойчивый совет: чтобы ситуация стала чуть лучше, чуть полегче и чуть порадостнее -- перепостройте действующие профайлы офсета с помощью PM 5.0.7 в режиме ColorFul.
 

Vadim_PDF

Топикстартер
15 лет на форуме
Сообщения
1 648
Реакции
237
Ответ: Методы Gamut-ного сжатия

Можно уточнение. А версия 5.0.5 хуже работает? Изменения произошли именно в 5.0.7?
 

minos

Модератор
15 лет на форуме
Сообщения
1 935
Реакции
707
Ответ: Методы Gamut-ного сжатия

505 по Perceptual работает, на мой взгляд, значительно лучше. Я об этом уже здесь писал. Но все-таки, Я ТАК ДУМАЮ, лучше Monaco по Perceptual никто ничего не придумал.

С уважением, Дмитрий.
 

Alexey Shadrin

Участник
Сообщения
9 260
Реакции
1 190
Ответ: Методы Gamut-ного сжатия

minos сказал(а):
Я ТАК ДУМАЮ, лучше Monaco по Perceptual никто ничего не придумал.
Сие факт. Однако имеет смысл пробовать и в Монако, и в РМ -- выбор векторов компрессии сильно-насыщенных цветов, имхо, дело вкуса и контекста изображения. Лично мне вектора Монако не очень симпатичны, но еще раз подчеркиваю -- дело вкуса и контекстов, -- нужно пробовать.
 

lev

Модератор
20 лет на форуме
Сообщения
2 147
Реакции
2 072
Ответ: Методы Gamut-ного сжатия

...если хотя бы один пиксель изображения не помещается в охват...
Мне казалось, что сжатие происходит если охват профиля исходного изображения не попадает в охват целевого профиля, даже если цвет всех пикселей изображения попадают в целевой охват. Т.е. большинство программ не делают попиксельного анализа исходного изображения (т.н. контекстное сжатие).
 

Alexey Shadrin

Участник
Сообщения
9 260
Реакции
1 190
Ответ: Методы Gamut-ного сжатия

lev сказал(а):
Мне казалось, что сжатие происходит если охват профиля исходного изображения не попадает в охват целевого профиля, даже если цвет всех пикселей изображения попадают в целевой охват. Т.е. большинство программ не делают попиксельного анализа исходного изображения (т.н. контекстное сжатие).
Да, так и есть, и это легко проверить...
 

lev

Модератор
20 лет на форуме
Сообщения
2 147
Реакции
2 072
Ответ: Методы Gamut-ного сжатия

Теоретически могут существовать программы, осуществляющие контекстное сжатие, просто мне они не известны, поэтому и пришлось делать оговорки.
 

Alexey Shadrin

Участник
Сообщения
9 260
Реакции
1 190
Ответ: Методы Gamut-ного сжатия

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

sabos

Участник
Сообщения
1 909
Реакции
285
Ответ: Методы Gamut-ного сжатия

Imho, говоря о сжатии, нельзя все сводить к работе стальных идиотов, живущих внутри CMS. Контекстным сжатием занимаются не программы, а люди. Во-вторых нужно понимать, что gamut mapping не эквивалент ICC. Любая система цветокоррекции имеет внутри себя систему gamut mapping, просто не всегда эти системы соответствуют спецификации ICC. Скажу больше - в некоторых промышленных системах цветокоррекции таблицы сжатий есть отдельные коммерческие компоненты (и имеют стоимость порой больше, чем вся остальная система целиком). Пример - видео- и кинообработка.
 

Alexey Shadrin

Участник
Сообщения
9 260
Реакции
1 190
Ответ: Методы Gamut-ного сжатия

sabos сказал(а):
Во-вторых нужно понимать, что gamut mapping не эквивалент ICC. Любая система цветокоррекции имеет внутри себя систему gamut mapping, просто не всегда эти системы соответствуют спецификации ICC.
Спецификация требует от вендоров обязательного наличия Abs. и Rel. Perceptual (а именно этот вариант для нас принципиален) не лимитирован.
 

sabos

Участник
Сообщения
1 909
Реакции
285
Ответ: Методы Gamut-ного сжатия

В каком из CMM (соответсвующих icc-спецификации) я могу сказать, что при сжатии мне нужно перейти от ярких условий просмотра (и с высоким диапазоном) к полутемным? В каком из CMM я могу сказать в явном виде, что хромадаптация будет неполной?
 

Alexey Shadrin

Участник
Сообщения
9 260
Реакции
1 190
Ответ: Методы Gamut-ного сжатия

sabos сказал(а):
В каком из CMM (соответсвующих icc-спецификации) я могу сказать, что при сжатии мне нужно перейти от ярких условий просмотра (и с высоким диапазоном) к полутемным? В каком из CMM я могу сказать в явном виде, что хромадаптация будет неполной?
Не понял -- это риторика? Если нет, то: лично мне такой софт неизвестен. Но есть надежда на интеграцию CIECAM02 в тот же Фотошоп, эту же надежду выражет и Фершильд.
 

sabos

Участник
Сообщения
1 909
Реакции
285
Ответ: Методы Gamut-ного сжатия

Alexey Shadrin сказал(а):
Не понял -- это риторика?
Нет, это лишь попытка сказать, что цвет не заканчивается на уровне Adobe ACE и icc-профилей.
Alexey Shadrin сказал(а):
Но есть надежда на интеграцию CIECAM02 в тот же Фотошоп
В каком виде? Есть ли у нас на входе того же "фотошопа будущего" полный набор данных? Не нормированных светлота/насыщенность. А полноценных, в т.ч. и о источниках света сцены (а их зачастую не один), о дин. диапазоне захвата, о балансировке (фона в первую очередь). Нет, данные безвозвратно утеряны еще на стадии захвата. Что мы должны делать в этой ситуации. Предполагать их некими "типичными" viewing condition. Да и при воспроизведении аналогично - предполагать нечто "типичное". Hа ком лежит ответсвенность за адекватное предположение? На цветокорректоре. Их много?

Откуда и происходят шаманские CLUT того же Cinematic, DaVinchi и т.п. - предполагаем viewing condition для входа и выхода, берем ближайшую модель color appearance (тот же CIECAM), просчитываем закрытое решение и продаем за большие деньги.
 

Alexey Shadrin

Участник
Сообщения
9 260
Реакции
1 190
Ответ: Методы Gamut-ного сжатия

Чего-то я не врубаюсь... :+((
sabos сказал(а):
Нет, это лишь попытка сказать, что цвет не заканчивается на уровне Adobe ACE и icc-профилей.
Так этого никто и не утверждал... Собственно ради этого и Фершильд переводился, и ICC-спецификация...
В каком виде? Есть ли у нас на входе того же "фотошопа будущего" полный набор данных?
Набор сцен, увы, банален. В свое время я просил операторов фотостудий понаблюдать за характером сцен, о чем рассказывал в ветке по фотографии. Более того, серьезные фирмы, озабоченные нашей темой, хранят на своих дисках массивы данных о сценах. На основании этих массивов можно вывести некие средние условия сцены и условия просмотра репродукции, а затем предложить их в качестве опционального набора. Это лучше, чем ничего. Плюс к тому: возможны advanced-опции, где "продвинутый" цветокорректор будет вводить необходимые параметры. Их не так много, как может показаться с перепугу :)
Далее: давайте не будем забывать о том, что по мнению самоей Adobe Systems -- Фотошоп -- это в первую очередь инструмент фотографа. Под "фотографом" они, кстати понимают и цветокорректора. Серьезные фтографы и цветокорректоры зачастую хорошо представляют себе условия съемки (особенно фотографы-студийщики, предметники, "ювелирщики" и пр.). Опытный цветокорректор, по моему глубокому убеждению, это человек имеющий богатый опыт осмысленного наблюдения за сценами + конечно же, минимально необходимый практический навык дергания рычагов Фотошопа.
Я это все к чему: не вижу ничего страшного в том, ежели следующий Фотошоп предложит диалоги ввода входных и выходных данных CIECAM02 -- лично я буду только приветствовать.
 

sabos

Участник
Сообщения
1 909
Реакции
285
Ответ: Методы Gamut-ного сжатия

Ситуация очень проста. На данный момент (как и 40 лет назад) есть два подхода к проблеме - любительский и профессиональный. Технология не в состоянии заменить профессионала любителем, она лишь помогает работать профессионалу. Соответственно есть (и будет) два результата. Любителям "ленивых" кнопок CIECAM и "фотошоп будущего" ничем не поможет, результат у современного любителя будет аналогичен результату того же любителя 40 лет назад. Треш в 99% случаев. Да, увеличение количества кнопок приведет к увеличению количества шаманских алгоритмов по последовательности их нажатия. Метод проб и ошибок порождает их комбинаторно (факториалом).

Все вышесказанное - не риторика. Оно напрямую относится к
есть только 4 способа преобразования охвата изображения из профайла в профайл
лучше Monaco по Perceptual никто ничего не придумал
Еще раз без лишней скромности. Цветокоррекцию (в т.ч. и цветоделение) делает не CMS. Её делает профессионал. Сжатие делают руками. Руками проектируют и автоматическое сжатие. Адекватный CLUT для преобразования делают не "калибровками" (сканеров, принтеров), а руками. CMS, RI, профили и пр. "калибровки" мне в этом помогают.
 

Alexey Shadrin

Участник
Сообщения
9 260
Реакции
1 190
Ответ: Методы Gamut-ного сжатия

sabos сказал(а):
Любителям "ленивых" кнопок CIECAM и "фотошоп будущего" ничем не поможет, результат у современного любителя будет аналогичен результату того же любителя 40 лет назад. Треш в 99% случаев.
Ну, кто бы спорил. Но убежден, что профессионалу тот же CIECAM02 позволит радикально сэкономить время (и нервы, заодно).
Да, увеличение количества кнопок приведет к увеличению количества шаманских алгоритмов по последовательности их нажатия. Метод проб и ошибок порождает их комбинаторно (факториалом).
У тех, кому лень тратить время на учебу. Теперь уже просто так сослаться на отсутствие материалов не получится -- кое-что уже есть.
Сжатие делают руками. Руками проектируют и автоматическое сжатие. Адекватный CLUT для преобразования делают не "калибровками" (сканеров, принтеров), а руками.
Головой, коллега, головой... (и, порой, -- сердцем).
 

Alexey Shadrin

Участник
Сообщения
9 260
Реакции
1 190
Ответ: Методы Gamut-ного сжатия

sabos сказал(а):
Цветокоррекцию (в т.ч. и цветоделение) делает не CMS. Её делает профессионал. Сжатие делают руками. Руками проектируют и автоматическое сжатие. Адекватный CLUT для преобразования делают не "калибровками" (сканеров, принтеров), а руками. CMS, RI, профили и пр. "калибровки" мне в этом помогают.
Собственно говоря, Саша, система контекстного сжатия, о которой сетовали выше, это всего лишь услуга -- сервис, предоставляющий интерфейс того, что сегодня Вы делаете "руками" в Excel, Cи++-редакторе, в целевом аппаратном пространстве и пр.
в т.ч. и цветоделение
Бога ради, давайте уходить от этого дурного термина, заменив его, скажем, на "целевое преобразование" или что-нибудь в этом роде.
 

minos

Модератор
15 лет на форуме
Сообщения
1 935
Реакции
707
Ответ: Методы Gamut-ного сжатия

Александр... Ну что же Вы так... У меня нет пока возможности (читайте - знаний, опыта) руками делать gamut mapping... Это уже высший пилотаж. Я лишь высказал мнение из своего не очень обширного опыта о том, что Perceptual в трактовке Monaco Systems является СУБЪЕКТИВНО и ПО МОЕМУ МНЕНИЮ лучшим из того, что я пробовал (Gretag[Colorful, Classic, Chroma+ 5.0.1-5.0.7], Heidelberg, Fuji, BasICColor). И тот результат, который получается в итоге весьма неплох и будет более чем достаточен в 95% случаев для пользователей, скажем, фотопринтеров Epson.

С уважением, Дмитрий.
 
Статус
Закрыто для дальнейших ответов.