Image&Spot Color Management

Статус
Закрыто для дальнейших ответов.
Ответ: Image&Spot Color Management

Alexey Shadrin сказал(а):
Это не «отбрасывание» -- это интерпретация.
Хорошо, пусть будет интерпретация. Сути не меняет. При такой "интерпретации" мы теряем возможность точного синтеза на устройствах с "плохими" primaries. Да, для визуализации на мониторе решать задачу спектрального синтеза не имеет смысла. И в рамках типичного принтера с 4-мя "плохими" primaries особой пользы от спектрального синтеза не будет. Он хорош тогда, когда может высчитать стимул из 10-15 баз (в идеале - из 32). Именно так поступают и в текстильной, и в автомобильной, и в лако-красочной промышленности. Нам же SPM нужен редко, разве что при мешке красок. Но не стоит забывать, что при первичном анализе колористики той же цветопробы нужны именно спектральные исследования, при "интерпретации" мы теряем очень много важной информации. Простейший пример - хроматические сдвиги, которые приходится в рамках ICM скромно называть "неконтролируемые". Следующий пример CMYK->CMYK. Не буду расписывать все проблемы такого преобразования, но отмечу, что именно по этой причине color processors высоко уровня предпочитают dlp (и схожие методы).
Alexey Shadrin сказал(а):
Иначе поступать не получается в данной ситуации, бо не хватит никаких вычислительных ресурсов, дабы проанализировать каждый стимул изображения на предмет tone stability и проч. Может быть, потом, в будущем… В ситуации спот-копирования, когда стимул один (два, три, пять, не более) – это возможно. Но когда стимулов тысячи… -- другого пути нет. Пока нет.
Визуализация данных уже давно использует технологии спектрального синтеза. Тот же телескоп Хабл. Да, вычислительных ресурсов нужно много. Но и наши настольные cpu уже не дети :-).
Alexey Shadrin сказал(а):
И мне бы хотелось особо подчеркнуть разделение на «стимул» (спектр) и «ощущение» (координаты), чтобы у читателей не создалось впечатления, что спектр – это «истинный цвет» (это вообще не цвет), а координаты «псевдоистинный» или истинный в кавычках. :)
Кавычки возникли вследствие того, что понятие "ощущений", которое мы пытаемся вложить в термин "цвет", в жизни значительно более многогранно. Бог с ними, с определениями, вы не хуже меня понимаете, насколько сложным может оказаться этот разговор.
 
Ответ: Image&Spot Color Management

sabos сказал(а):
Бог с ними, с определениями, вы не хуже меня понимаете, насколько сложным может оказаться этот разговор.
Да, конечно. Спасибо, Александр. И не подумайте только, что я пытался зафлеймить Ваш постинг :) -- по моему глубокому убеждению принудительная вербализация понятий необходима, чтобы не утонуть. Ну, да ладно, проехали. :)
Еще раз спаибо.
Алексей.
 
Ответ: Image&Spot Color Management

Harlequin сказал(а):
Порог различения, насколько я понимаю, и существет только в ситуации сравнения объектов (стимулов).
Да, человеческое зрение - это нуль-детектор. Два замечания - объекты и стимулы - не одно и тоже. При сравнении в качестве объекта может выступать память. А могут и объективные реперы. Как пример - серый.
Harlequin сказал(а):
Но если эти стимулы составные, то мне представляется логичным, что порог их различения будет выше.
Я бы не усложнял. Есть прекрасное объяснение - локальная адаптация.
Harlequin сказал(а):
Например, расчёт количества цветового различия (dE), который, я уверен, используется при расчетах профайлов. Тут, кажется, еще есть куда двигаться...
Проблема не в dE, а в самом Lab. В его "условной" равноконтрастности.
Harlequin сказал(а):
Мне кажется, могут возникать и задачи spot CM, требующие алгоритмов, учитывающих адаптацию.
Не очень ясно, что имеется ввиду. Хромадаптация вообще пока возможна только в рамках SCM. Адаптация по контрасту - легко сводится к задаче gamut mapping. А само сжатие - вещь уже независимая, отдельная, это context color management.
 
Ответ: Image&Spot Color Management

А само сжатие - вещь уже независимая, отдельная, это context color management
На сегодняшний день механизмов контекстного сжатия в лоне ICC не наблюдается и, похоже, в ближайшее время не появится: доминирует массовый бытовой workflow :( Педантам по зарез необходимо контекстное сжатие, но вряд ли они смогут покрыть расходы на его разработку, учитывая еще и то, что российский, китайский и К° педант будет воровать, а не покупать... :rolleyes:
Александр, что-то не пойму как расшифровывается данная аббревиатура. Ничего кроме device link profile на ум не приходит...
Алексей.
P.S. Павел! Относительно "сложносоставных" стимулов: CIE расматривает любой стимул, как аддитивную смесь узкоспектральных и множит на ординаты кривых сложения. Поэтому форма кривой SPD не имеет значения. Не имеет значения так же и то, из чего она получена: то ли сама по себе, то ли в результате сложения n-го количества исходных стимулов, например, кардинальных. Смесь спектров -- суть новый стимул, а координаты ощущения всегда можно вычислить по кривым физиологической реакции CIE (кривые сложения).
 
Ответ: Image&Spot Color Management

Alexey Shadrin сказал(а):
Александр, что-то не пойму как расшифровывается данная аббревиатура. Ничего кроме device link profile на ум не приходит...).
Правильно приходит :). Более "модный" термин - 4D-преобразование.
Alexey Shadrin сказал(а):
Относительно "сложносоставных" стимулов.
Здесь у нас и началась путанница. Алексей сделал замечание о красках, а я (с адаптацией) - про объекты.
 
Ответ: Image&Spot Color Management

Alexey Shadrin сказал(а):
На сегодняшний день механизмов контекстного сжатия в лоне ICC не наблюдается и, похоже, в ближайшее время не появится).
Не так все страшно. Сложную проблему нужно, как слона, есть постепенно. Для начала стоило бы решить задачу точного удержания тона при mapping. Не секрет, что мы сейчас имеем большие проблемы с этим. И вина лежит не на несовершенных механизмах CRI или проблемах интерполяции, как это принято считать. Суть - в проблемах самого пространства Lab, которое допускает весьма значительные искривления геометрии. Эту нелинейность и называют неравноконтрастностью пространства. Хотя проблемы там не только (и не столько) в контрасте. Нас волнует больше искривление тона. Очень многие компании работают над этой проблемой. Xopoшо известны работы M. R. Luo, G.Cui, B. Rigg - легшие в основу разработок CIECAM. Однако самые интересные наработки, imho, у направления Uniform Perceptual Lab (UP Lab). Там решаются проблемы не только выравнивания тональных векторов, но и известная blue turns purple! Уже появились профайлы Lab->UP Lab->Lab, с помощью которых можно провести gamut mapping в равноконтрастном пространстве. Рекомендую посмотреть в эту сторону.
 
Ответ: Image&Spot Color Management

sabos сказал(а):
Уже появились профайлы Lab->UP Lab->Lab, с помощью которых можно провести gamut mapping в равноконтрастном пространстве. Рекомендую посмотреть в эту сторону.
С удовольствием, бо давно пора. Но, вот, вопрос: а практически? Пока нет ни сертифицированного формата ICC, где PCS UP Lab, ни "народного" CMM (ACE, Logo Sync и проч.) :)
Алексей.
P.S. Однако, Вы знаете, Александр, меня не покидает сугубо интуитивное ощущение, что мэппинг в Lab не происходит. Все больше склоняюсь к мысли, что механизм мэппинга в любой ситуации реализован на уровне XYZ. Пересчитать Lab<-->XYZ по взаимнооднозначным формулам -- дело "наносекунд".
Уже довольно давно я пытался расшевелить общественность в отношении XYZ, но никто кроме Германа так и не откликнулся. Обратите внимание, что в любых (!) профайлах белая точка прописана в XYZ. Неспроста. И раз так, то эти взаимнооднозначные формулы как-то и зачем-то используются. При мэппинге жмется все цветовое пространство человека (пространство не в математическом смысле, а в биологическом). Точную фигуру этого пространства судя по всему никто толком не знает, и реализовать сжатие в той ситуации проще всего на уровне XYZ, как эфемерного колориметра с абсолютным охватом.
Впрочем, даже если так, если вдруг я действительно учуял (но только учуял, доказать не могу) суть, то использование UP Lab должно дать плоды, т.к. и XYZ будет рассчитан правильнее.
Относительно сжатия сильно продвинулся Павел Топорков (Harlequin) -- надо послушать чего он скажет...
 
Ответ: Image&Spot Color Management

Алексей, я никак не могу взять в толк, что в имеете в виду, когда говорите "gamut mapping ПРОИСХОДИТ". В смысле, где он рассчитывается? Потому что, на мой взгляд, в случае табличных профайлов весь расчет gamut mapping производится на этапе вычисления профайла. Каковы алгоритмы этих расчетов и в каких ЦКС они производятся? Это уже, я думаю, vendor specific. В одной из буржуйских монографий, посвященной gamut mapping для hi-fi color приводились алгоритмы расчетов в Luv (на уровне схем - не более того). Может быть, некоторые вендоры реализуют их в CIECAM или UP Lab... Все эти разработки проприетарны, и я не думаю, что мы сможем накопать здесь что-то более конкретное.
А то обстоятельство, что белая точка всегда задается в XYZ, объясняется, на мой взгляд, просто: для реализации Absolute Colorimetric intent необходимо масштабирование XYZ-координат. Gamut mapping, как мне кажется, здесь ни при чем...
Я продолжаю считать, что функции CMM исчерпываются:
1. Преобразованиями координат ЦКС (XYZ - Lab) и chromatic adaptation.
2. Матричными преобразованиями (никакого, по сути, gamut mapping).
3. Интерполяциями в LUT табличных профайлов.

С уважением,
Павел Топорков.
 
Ответ: Image&Spot Color Management

Павел, я не пытаюсь спорить, но следующий тезис мне в упор непонятен:
в случае табличных профайлов весь расчет gamut mapping производится на этапе вычисления профайла.
Ну, как это может быть? Откуда профайлу знать, что за цвета не полезут в целевой охват и как их жать?
Потом: возьмите один и тот же профайл, одно и то же изображение и прокрутите его разными CMM. Сжатие будет немного (!) отличаться, а ежели использовать Kodak DS, то отличия от того же ACE будут разительны. Но ежели gm закладывается при построении профайла, то отличий быть недолжно.
"Тут и проснулся в недоумении"...
Алексей.
 
Ответ: Image&Spot Color Management

Alexey Shadrin сказал(а):
а ежели использовать Kodak DS, то отличия от того же ACE будут разительны.
Слышал я это много раз и читал. Однако, ярких и убедителных примеров не припоминаю. Можно ли взглянуть на примеры? Или как-нибудь самому их воспроизвести?
 
Ответ: Image&Spot Color Management

Shlyapa сказал(а):
Можно ли взглянуть на примеры? Или как-нибудь самому их воспроизвести?
Нет ничего проще, дорогой коллега.
1. Создаем sRGB-файл, заливаем 255 0 0. Получается цвет L54 a81 b70. Сохраняем.
2. Конвертируем Фотошопом по профайлу Euroscale Uncoated (охват маленький, компрессии большие – наглядно), CRI -- Perceptual. Получаем аппаратные CMYK-данные 0 95 100 0 , то есть цвет L51 a49 b67
3. Сохраненный sRGB-вариант грузим во FreeHand 10. Это как раз Kodak DS CMM. В установках Хэнда выбираем Euroscale Uncoated (предвариетльно переписав профайл в соотв. Папку Хэнда), CRI -- Perceptual. В качестве RGB-источника выбираем sRGB. Генерим композитный постскрипт, не забыв установить флажок «Convert RGB to process».
4. Полученный постскрипт перекручиваем дистиллером в PDF при «Leave all colors unchanged» или же рипуем в TIFF с помощью Harlequin. Без разницы.
5. Открываем в Шопе и видим: аппаратные данные CMYK 0 81 99 0, а цвет после присвоения профайла Euroscale Uncoated L55 a60 b50.
И так можно проделать с Corel, NewColor и проч.
Далее: берем ColorPicker от PM 5.0.1. Выбираем соотв. профайл, CRI – Perceptual, заливаем исходным цветом L54 a81 b70 и конвертируем по Euroscale Uncoated. Результат: L51 a70 b46, а аппаратные CMYK – 0 96 100 0. И это уже работа LogoSync.
* * *
Итак, был исходный цвет L54 a81 b70.
После компрессии с помощью
ACE --> L51 a49 b67
KodakDS --> L55 a60 b50
Logo Sync --> L51 a70 b46

* * *
Еще нужны примеры?
Проделайте, убедитесь... :)
Алексей.
 
Ответ: Image&Spot Color Management

Alexey Shadrin сказал(а):
Итак, был исходный цвет L54 a81 b70.
После компрессии с помощью
ACE --> L51 a49 b67
KodakDS --> L55 a60 b50
Logo Sync --> L51 a70 b46

* * *
Еще нужны примеры?
Проделайте, убедитесь... :)
Да нет, не буду воспроизводить — я верю, что именно так и получается. Но нельзя ли прокомментировать эти цифры? Я вижу, что они разные, и разные, тыкскыть, по-разному, но какие выводы из этого следуют?
 
Ответ: Image&Spot Color Management

Дим, не совсем разные по-разному. ACE и LogoSync при Perceptual выдержали L.
 
Ответ: Image&Spot Color Management

german сказал(а):
Дим, не совсем разные по-разному. ACE и LogoSync при Perceptual выдержали L.
Не понял. В описанном опыте тоже Perceptual, и из исходного L получилось 2 одинаковых, отличных от исходного, и одно отличное от всех остальных. Эти два одиновых, кстати, от исходного дальше, чем одно, которое само по себе.
Кто что выдеражал?

В значениях A и B разброс вообще во все стороны.

Вот я и не понимаю, какие выводы можно сделать из этих цифр. По какому критерию один результат можно считать лучше другого?
 
Ответ: Image&Spot Color Management

Они показали одинаковое направление векторов, в отличие от кодавского. А кто из них прав, думаю визуальная оценка может дать ответ. И при perceptual, a и b — это те координаты, которыми жертвуют.
 
Ответ: Image&Spot Color Management

Попробовал повторить. НО: за исходный взял L54a81b70.
В Photoshop CS конвертировал в Euroscale Uncoated (Perceptual) с отключенной опцией Black point compensation. Получил 0 96 100 0. Конвертнул обратно в Lab - L51a69b46.

В ColorPicker: 0 96 100 0. L51a70b46.

По-моему, с ACE и LogoSync все ясно.

Что касается конверсии из sRGB (или других матричных): там действительно разница в работе различных CMM видна невооруженным глазом. Такой пример я приводил еще на cps.prepress.color. Правда, там я сравнивал ICM и ACE. Конкретно для sRGB можно предположить, что используются различные алгоритмы chromatic adaptation - Bradford или von Kries - ведь white point в sRGB - D65.

До FreeHand и Kodak CMS пока руки не дошли...
 
Ответ: Image&Spot Color Management

Shlyapa сказал(а):
Вот я и не понимаю, какие выводы можно сделать из этих цифр. По какому критерию один результат можно считать лучше другого?
Вот в этом-то и соль. Ни по какому! Ибо в данном случае перед системой Image Color Management-а поставлена непосильная для него Spot-задача. Изображения-то нет... Есть один стимул и одно ощущение.
Критерием-же качества работы CMM может служить, имхо, только результат копирования изображения, состоящего из множества стимулов (от четырех и выше); изображения, где есть чему с чем соотноситься. Критерием качества работы CMM является точность копии изображения, точность передачи соотношений координат.
Павел справедливо заметил, что конверсию нужно выполнять при снятом black point compensation. Да. Но позвольте: bpc -- это атрибут системы мэппинга, выведенный для пользователя. А, к примеру, в NewColor или iQueue такой флажок снять невозможно за отсутствием оного -- система блэк-компенсации там всегда работает при компрессии, но ее невозможно отключить. А в Шопе возможно.
Все это лишний раз доказывает, что компрессии на совести CMM.
Далее: присутствие/отсутствие bpc влияет и на все цвета, даже светлые и очень светлые, что немудрено, когда черную L0 a0b0 абстрактного идеального устройства всаживают в реальную черную точку реального устройства, которая ой как далека от L0 a0 b0. Поэтому все цвета "едут".
Таким образом, точность передачи данного конкретного цвета (неважно, гамутный он или нет) не является критерием качества CMM.
* * *
В какой-то степени absolute претендует на решение spot-задач, но тоже плохо с ними справляется.
Алексей.
 
Ответ: Image&Spot Color Management

[quote = Alexey Shadrin]Ну, как это может быть? Откуда профайлу знать, что за цвета не полезут в целевой охват и как их жать?[/quote]

Алексей, но ведь LUT рассчитываются для всего диапазона кодирования Lab. В том числе, и для тех значений, которые не имеют за собой реальных цветов. Это последнее не должно нас смущать, ибо, откуда им в наших изображениях взяться?.. Рассчитываются аппаратные координаты в соответствии с алгоритмами профилировщика. Для Colorimetric intents требованием спецификации ICC является "факсимильный" мэппинг in-gamut цветов. При этом мэппинг out-of-gamut на совести вендора. Для Perceptual - все на совести вендора. А уж определить находится ли в гамуте тот или иной цвет для профилировщика, думаю, не проблема - сначала рассчитываются таблицы A2B, которые и "вычерчивают" гамут устройства в ЦКС.

Что касается опции BPC - я, безусловно, согласен с Вами в том, что это параметр gamut mapping. Но, как мне кажется, в данном случае Photoshop в своем стиле являет некоторую гибкость. Как мне кажется, эта опция используется CMM "по умолчанию" именно для Perceptual - это логично, не правда ли? Но Photoshop позволяет нам использовать ее и для Colorimetric intents, или же отключать - для Perceptual. И ведь, как Вы можете заметить, в ColorPicker (приложения, предназначенного, по моему, как раз для Spot-копирования) эта опция не используется - даже для Perceptual. А тот же Photoshop независимо от этой галочки будет делать BPC для матричных профайлов всегда - вот так принято. А то, что эта опция "вынесена" из раcчета профайлов в CMM - ну тоже, думаю, для гибкости. Ведь операция BPC банальна и нересурсоемка.

И насчет критериев качества. Критерии, очевидно, зависят от задач. Задача spot-копирования декларируется ICC. Она решается с конечной точностью. Устраивает она нас или нет - вот и критерий. С изображениями CMS справляется значительно лучше - ну и ура :)

С уважением,
Павел Топорков.
 
Ответ: Image&Spot Color Management

Господа, в этой интересной дискуссии утрачена цель, imho. Цель gamut mapping является сохранение деталей изображения. Отличие ICM от Spot в этом и заключается. К SPM понятие маппинга неприменимо. Если некий spot будет внегамутным для некоторого устройства - то нужно менять устройство. Если же он попадает в гамут - хорошо, только этот цвет должен быть напечатан as is, он не должен попадать в CRI. Очень важно понимать, что термин spot правильно применять не к пикселю, а к крупному, самостоятельному объекту. Именно по этой причине в профессиональных пробах применяют отдельные таблицы исключений для spot-цветов. Исключить их из CRI. Оценивать качество сжатия разных CMM (именно для ICM) нужно на множестве, на изображении, на явно различимых объектах. Проверять, как деградирует изображение, как оно "уплощается".
Harlequin сказал(а):
Для Colorimetric intents требованием спецификации ICC является "факсимильный" мэппинг in-gamut цветов. При этом мэппинг out-of-gamut на совести вендора. Для Perceptual - все на совести вендора.
Я бы выразился немного иначе. Вектор, по которому "втягивают" некий цвет, может лежать строго в плоскости ab - в этом случае маппинг жертвует Chroma при сохранении L и Hue. Такой метод приводит к изрядной деградации деталировки, поэтому на границе выделяют некоторую область для "сжатия". Размер области - "на совести вендора", но обычно она небольшая. Вектор может быть и 3D - здесь уже все "на совести вендора", и размер пограничной области (она может достигать половины объема!), и наклон вектора.
 
Ответ: Image&Spot Color Management

Что касается алгоритмов gamut mapping, то формально их три. Public Gamut Mapping Algorithm (PGMA) - официально поддержан CIE (точнее, их 8-м комитетом), исходники можно взять прямо на colour.org. Он основан на Full–Colour Spatial Gamut Mapping Algorithm, разработанном в 90-x годах Jan Morovic и Yu Wang. Именно он является основой и для Heidel, и для Gretag (Logo). Некоторое время 8-й комитет носился с идеями Topographic Gamut Mapping (TOPO) или "universal" gamut mapping, но особого успеха они не имели. Это "костыли", а не идеи. Замкнувшись около идей Jan Morovic, они упорно игнорировали справедливые замечания и munsell lab, и японцев о проблемах геометрии в пространстве Lab. В результате последние пару лет 8-й комитет пинает ..., там идей больше не видать. Остальные двигались в сторону линеаризации Hue, откуда появились системы третьего типа: space dependent color gamut mapping, chroma clipping techniques (tetrahedral interpolation algorithm). Улучшения касаются проблем, условно названных blue turns purple (иногда упоминается red turns orange - суть этих проблем одна).
 
Статус
Закрыто для дальнейших ответов.