Коррекция превышающего цветового охвата

  • Автор темы Автор темы izrukvruki
  • Дата начала Дата начала
Осветляйте картинку, убирайте фиолетовые оттенки, пусть будет синее/голубее, потом конвертите в CMYK и уже после через levels, replace или selective colors (смотря что больше подойдёт) восстанавливаете (визуально) до оригинала. Тут основной косяк из-за сине-фиолетовых тонов, такие диапазоны в cmyk выглядят несколько иначе
И вообще вы особо не смотрите на монитор, при печати будет не так всё плохо. Да а какая печать кстати будет?
 
Последнее редактирование:
  • Спасибо
Реакции: akropin и ~RA~
izrukvruki сказал(а):
Извините, что поднимаю довольно старую тему: при выходе цветов картинки из CMYK диапазона, для корректного перевода из RGB в CMYK советуют понизить насыщенность, например на 20 единиц, а после перевода в CMYK поднять на столько же
Нажмите, чтобы раскрыть...
Чушь собачья…
 
  • Спасибо
Реакции: КоньЕстДетей и mihas
Да, конвертнуть по Perceptual и доработать руками.
Нажмите, чтобы раскрыть...
Perceptual для преобразования данного сюжета в фогру 39 ну просто показательно кардинально разный на профилях от разных профилировщиков ColorTool, i1Profiler, CoPrA и т.д., не говоря уже об том, что настройки Perceptual и даже настройки генераций будут существенно влиять на конечный цвет преобразования данного сюжета по Perceptual.
А на счет цветокоррекции не может быть однозначного лучшего результата для даного сюжета, который устроит всех. Любой цветокорректор с опытом вытянет максимум для себя своим инструментарием с этой картинки безпроблем. Вопрос, какие приоритеты в этом сюжете для нас главнее? Что нам главнее сохранить — сохранить ощущение насыщенности цвета в сравнении с оригиналом или сохранить максимально тоновые (светлотные) контрасты или что-то среднее и т.д.

P.S. Я бы сформулировал как аксиома — когда зарезается охват исходного изображнения при преобразовании — нет единственно правильного метода этого преобразования. Результат всегда субъективен (так как идут потери) и зависит от множества причин, в том числе и от вашего настроения. :)
 
Последнее редактирование:
  • Спасибо
Реакции: Valentin, alex103 и Jeine
izrukvruki сказал(а):
для корректного перевода из RGB в CMYK советуют понизить насыщенность, например на 20 единиц, а после перевода в CMYK поднять на столько же. Но мне кажется, это не совсем равнозначное действие?
Нажмите, чтобы раскрыть...
Все умные алгоритмы стараются не снижать насыщенность на сколько это возможно.

TwoDimensionalTaylor.png


Но цветокорректор может сделать еще умнее, чем алгоритм, подробности тут с наглядной иллюстрацией.
 
  • Спасибо
Реакции: colorprint, КоньЕстДетей, izrukvruki и ещё 1 человек
Johan сказал(а):
Это платный редактор 3D LUT?
Нажмите, чтобы раскрыть...
Я бы не сказал. Логика работы плагина построена не на LUT, а на оперировании цветовой моделью CIE LCh, что для колориста максимально удобно. В этом плане автор программы опережает конкурентов, неповоротливый Адоб когда еще допетрит, что отсутствие в современной программе работы с цветом Фотошоп цветовой модели LCh - это просто позорище позорное.
 
  • Спасибо
Реакции: Fragarach, Gadalka, КоньЕстДетей и ещё 1 человек
mihas сказал(а):
Я бы не сказал. Логика работы плагина построена не на LUT, а на оперировании цветовой моделью CIE LCh, что для колориста максимально удобно. В этом плане автор программы опережает конкурентов, неповоротливый Адоб когда еще допетрит, что отсутствие в современной программе работы с цветом Фотошоп цветовой модели LCh - это просто позорище позорное.
Нажмите, чтобы раскрыть...
Логика UI может быть построена на чём угодно; вопрос в том, что "у ней внутре". GrossGrade обновленный видели?
 
Кто такой кроссгрейд и какое отношение он имеет к замечательному плагину файргрейд?
 
Последнее редактирование:
Johan сказал(а):
GrossGrade обновленный видели?
Нажмите, чтобы раскрыть...
Да вот посмотрел - там куб RGB сплошной, значит речь вообще скорее о коррекциях за пределом колориметрических моделей (может ошибаюсь и не вник внимательно) и ни капли не похоже на работу в FireGrade. И самого главного - CIE LCh - там нет в списке. Так что это скорее антипод упомянутой FireGrade. Вообще попытки работать с цветом как GrossGrade при этом за рамками колориметрии в программах случаются, о них быстро забывают.
 
Последнее редактирование:
mihas сказал(а):
Да вот посмотрел - там куб RGB сплошной, значит речь вообще скорее о коррекциях за пределом колориметрических моделей (может ошибаюсь и не вник внимательно) и ни капли не похоже на работу в FireGrade. И самого главного - CIE LCh - там нет в списке. Так что это скорее антипод упомянутой FireGrade. Вообще попытки работать с цветом как GrossGrade при этом за рамками колориметрии в программах случаются, о них быстро забывают.
Нажмите, чтобы раскрыть...
Поддерживаемые форматы выходных файлов LUT:
§Adobe / IRIDAS Cube (*.cube)
§Adobe / IRIDAS Look (*.look)
§Autodesk / ASSIMILATE Scratch 3DL (*.3dl)
§Autodesk Color Management (SynColor) CTF (*.ctf)
§Rising Sun Research cineSpace (*.csp)
§Academy / ASC Common LUT Format (CLF) (*.clf)
§Digital Vision Nucoda CMS (*.cms)
§DaVinci Resolve Cube (*.cube)
§FilmLight Truelight (*.cub)
§Side Effects Houdini (*.lut)
§DVS Clipster (*.xml)
§Panasonic VariCam (*.vlt)
§Hald CLUT Image (PNG) (*.png)
§Hald CLUT Image (TIFF) (*.tif;*.tiff)
§ICC profiles (*.icc)
§ICM profiles (*.icm)


...Забыть как страшный сон :-D
 
fgcs.jpg

Вот все цветовые модели, что доступны для работы в FireGrade. Иными словами никчемно и к цвету не имеет отношения.
Вы серьезно считаете, что можно выполнять осмысленную цветокоррекцию в неравноконтрастных стимулах XYZ или в аппаратных сигналах для телевизора YCbCr?
Автор FireGrade принципиально с других позиций пишет софт, только колориметрия, только LCh - меня как колориста его подход максимально радует, мы хоть и не сходимся в некоторых воззрениях на форуме, но с логикой FireGrad работы именно в колориметрической и самой удобной модели я стопроцентно поддерживаю автора плагина.
 
Последнее редактирование:
  • Спасибо
Реакции: andrejK
Любопытно. Сколько десятилетий пройдет. До тех пор, пока в адобе поймут, что единственно верное цветовое пространство для цвета - Lch
 
mihas сказал(а):
Посмотреть вложение 135767
Вот все цветовые модели, что доступны для работы в FireGrade. Иными словами никчемно и к цвету не имеет отношения.
Вы серьезно считаете, что можно выполнять осмысленную цветокоррекцию в неравноконтрастных стимулах XYZ или в аппаратных сигналах для телевизора YCbCr?
Автор FireGrade принципиально с других позиций пишет софт, только колориметрия, только LCh - меня как колориста его подход максимально радует, мы хоть и не сходимся в некоторых воззрениях на форуме, но с логикой FireGrad работы именно в колориметрической и самой удобной модели я стопроцентно поддерживаю автора плагина.
Нажмите, чтобы раскрыть...
Хех, если там еще правой кнопкой мыши нажимать - то там вообще ад и израиль, и нодовая система (со смарт-масками).
Однако на выходе - стандартный LUT. Если вспомнить начало темы - про небо - то имеет ли значение, какую модель использовать, если по сути надо просто упихнуть облака во что-то вменяемое? Если кому-то проще в "телевизорном" пространстве, то почему бы и нет, если делать это по виджету визуализации?..
 
andrejK сказал(а):
Любопытно. Сколько десятилетий пройдет. До тех пор, пока в адобе поймут, что единственно верное цветовое пространство для цвета - Lch
Нажмите, чтобы раскрыть...
Это для белковых форм жизни, у которых там сетчатка как-то нелинейно кодирует. Кукурузену при нормальной оптимизации сейчас в принципе без разницы, что во что перекодировать, на входе и выходе чистая мать ее математика.
 
На картинке, что дана несколькими постами выше выделен желтым как мне кажется наиболее оптимальный алгоритм сжатия, когда меняется светлота L для достижения высокой хромы C. Если какая-то Lut- конверсия подобную логику обеспечивает - честь ей и хвала. Но как мне кажется, без владения знанием о L и C оптимальное сжатие невозможно. А предложенная Lut программа как мне показалось, как раз таким знанием и не владеет.
Какой алгоритм сжатия применен в продвинутом софте от @TRANTOR я не знаю. Наверное что-то такое умное.
P.S. Я в свое время поискал геометрическую формулу, как нарисовать такой перпендикуляр к краю охвата в координатах LC (на картинке выше желтым выделил) и вот чудо - достаточно быстро нашел нужную математику среди разных геометрических задач. Работает здесь в алгоритме RGB-гамут-маппинга для единичных цветов, к сожалению, не для фотографического изображения.
Трантор справедливо мне в свое время сказал, что клиппинг не делается в координатах RGB по уму. С тех пор я с сожалением встретил на сайтах пантона и RAL именно такой бездумный RGB-clipping, когда очевидное отрицательное значение одного из каналов явно за пределами охвата просто приравнивается нулю, а заохватные значения выше 1 (255) приравниваются к 1 (255)... На тот же рефлекс блю взгляните на сайте пантона, это типичный RGB-clipping. Я оставил по ссылке такую возможность поклипить, но не по умолчанию - только специально отключив гамут-маппинг.
 
Для ответа нужно войти/зарегистрироваться
Верх Низ