Мелкий вопрос по структуре icc-профайла

[Alexey Shadrin]

Ответ: Мелкий вопрос по структуре icc-профайла

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

Ты очень глубоко копаешь, Саша и переоцениваешь несколько возможности того же РМ -- у РМ, имхо, в этом случае просто "едет крыша" и он лепит нечто одно в таблицу (из каких-то своих соображений), а там уж, что Бог послал при инверсии и попытке печати. Ситуация, тобою описанная, типична для плохих нелинеаризованных устройств, в частности (прости, отче) для НР. Но выход из этой ситуации -- не альтернативные таблицы -- выход -- это линеаризация, которую обязан делать производитель!!! (о чем пишет Фершильд), а делаем мы. Эпсон здесь безупречен -- поэтому его АВС-профайлы так блестяще работают, а с НР мы вынуждены вскрывать нутро -- возиться с РИП-ами, линеаризоваться и пр., дабы уйти от описанных тобою прецедентов неоднозначности соответствий. Сказанное -- один из комплекта ответов на вопрос "зачем нужна линеаризация?"

 

[sabos]

Ответ: Мелкий вопрос по структуре icc-профайла

Невозможно.

Возможно. Преобразования device->PCS и PCS->device невзаимны (точнее взаимно необратимы). Это легко объяснить - если вспомнить про сжатие. Все таблицы типа B2A содержат внутри сжатие. Без сжатия профилей не бывает.

И даже матричные профили в строгом смысле невзаимны. Ибо gamut clipping.

 

[Alexey Shadrin]

Ответ: Мелкий вопрос по структуре icc-профайла

Возможно. Преобразования device->PCS и PCS->device невзаимны (точнее взаимно необратимы). Это легко объяснить - если вспомнить про сжатие. Все таблицы типа B2A содержат внутри сжатие. Без сжатия профилей не бывает.

Странно: AtoB также ведь содержит сжатие, и, по логике, точно такое же. По крайней мере я в свое время проверял и убедился в этом.

 

[almastu]

Ответ: Мелкий вопрос по структуре icc-профайла

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

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

2. В качестве такой ЦКС вряд ли применима абсолютная, типа XYZ. В конце концов, нам нужны разные подложки, с разным цветом - и значит, главное - сохранить определенные соотношения цветов сцены, а не абсолютные значения оных (что в ряде случаев невозможно принципиально - из-за цветности подложек). Тогда на вход можно подавать "Lab", "Lch" и т.п. либо их потомков.

3. Поскольку компрессии все равно придется применять, их набор (RI`s) также можно "зашить" в суперпринтер. А вот выбирать из них, - это конечно должен человек. По-любому.

4. Разные подложки учитывать необходимо - нужна подсистема самокалибровки. Это не проблема, уже сейчас есть карикатуры на нее... А в некоторых системах - даже и не совсем карикатуры, а вполне рабочие решения.

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

6. Ну, и еще конкуренция за максимальный охват подложек...

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

Мне это видится примерно так.

(если слишком далеко ушли от исходной темы , а этот топик интересен, можно его вынести отдельной веткой... или списать во флейм в противном случае)

 

[almastu]

Ответ: Мелкий вопрос по структуре icc-профайла

Странно: AtoB также ведь содержит сжатие, и, по логике, точно такое же. По крайней мере я в свое время проверял и убедился в этом.

Леша, это та же проблема, что я и говорил: сжатие - это когда из набора РАЗНЫХ исходных получается ОДНО выходное значение. "Разжатие" - это не есть операция, обратная сжатию. Ну какой толк с того, что на вопрос "а в этом месте черного пятна, раньше что было?" мы получим ответ "а фиг его знает, что-нибудь из этого набора...". При сжатии теряется _различность_ аппаратных данных.
Видимо, поэтому 2 таблицы действительно необходимы. Из принципиальных соображений.

Добавка:
"Сжатие А2В" - просто описание, что какие-то входные значения дадут одинаковый цветовой результат. (описание клиппинга?)
"Сжатие В2А" - это, видимо, как раз и есть гамут маппинг...

 

[Alexey Shadrin]

Ответ: Мелкий вопрос по структуре icc-профайла

Саша и Саша: вот цитата из спецификации (п. 9.1), "In general, the BToAxTags represent the inverse operation of the AToBxTags." Конечно, смущает "in general", но я уж не думаю, что до такой степени...

 

[Alexey Shadrin]

Ответ: Мелкий вопрос по структуре icc-профайла

"Сжатие А2В" - просто описание, что какие-то входные значения дадут одинаковый цветовой результат.

В том-то вся и штука, что нет! Проведи простой эксперимент: возьми тест-карту с промерами. Выбери коакой-нибудь насыщенный патч, засеки его аппаратные данные и проверь Lab-значения. Потом открой эту карту в Шопе, присвой профайл, не забыв при этом выставить в Color Settings режим Absolute colorimetric. Ты увидишь, что на панели info будут немного иные цифири Lab (причем, выходящие за рамки округлений). Из этого я заключаю, что (как это не парадоксально напервый взгляд) AtoB таблица строится билдером ПОСЛЕ того, как построена BtoA и является ее зеркальным отражением...

 

[sabos]

Ответ: Мелкий вопрос по структуре icc-профайла

AtoB также ведь содержит сжатие, и, по логике, точно такое же. По крайней мере я в свое время проверял и убедился в этом.

Это не противоречит тому, что я сказал. A2B может однозначно описывать промер, а может быть специальным образом предискажено. Я встречал попытки подгонки A2B (совместно с "хитростями" CMM) таким образом, что многократные преобразования тудым-сюдым (device->PCS + PCS->device) не приводили к заметной деградации изображения. Но это всё хитрости, они не отменяют важный принцип - сжатие есть потеря информации. Необратимая.

 

[almastu]

Ответ: Мелкий вопрос по структуре icc-профайла

Саша и Саша: вот цитата из спецификации ... Конечно, смущает "in general", ...

Ага, это самое "в общем случае", имхо, - как раз для хороших устройств, типа Эпсона или там монитора Барко. А как ты и говорил, именно плохие, нелинеаризованные, устройства в этот общий случай и не попадают. Думаю, дело в том, что ICC-спецификации начали создаваться тогда, когда плохих устройств было достаточно много (да их и сейчас еще...), и надо было охватить и их случай.

 

[almastu]

Ответ: Мелкий вопрос по структуре icc-профайла

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

 

[Alexey Shadrin]

Ответ: Мелкий вопрос по структуре icc-профайла

Спасибо всем отозвавшимся

Саша, погоди-погоди: возможное отличие BtoA от AtoB, имхо, может быть плодом принудительной редакции одной из таблиц, но по умолчанию они, имхо, должны быть одинаковы, бо билдер не соображает, как лучше всего поступить. Может быть в "in general" содержится намек на возможность такой редакции? Не уверен я.

 

[almastu]

Ответ: Мелкий вопрос по структуре icc-профайла

Попробую покрутить Lage профайл монитора жены (полусдохший CRT, lut видеокарты обнулю предварительно) - вдруг различает по такому принципу? по принципу, Lage|Default. Других поводов для разных подходов к построению таблиц мне пока не придумать.
Там и гамут клиппинг проверю, заодно.

С другой стороны, откуда возмется "принудиловка"? В результате ручного корректирвания профайла только? Или билдер как-то сам догадывается о такой необходимости? В последнем случае, опять же не ясно, исодя из чего он такой догадливый...

 

[sabos]

Ответ: Мелкий вопрос по структуре icc-профайла

на панели info будут немного иные цифири Lab

Шоп для контроля не годится по причине relative Lab. Причем там относительны не интенты, относительны сами данные в info. Ограничение ACE. Реальные проблемы сжатия можно посмотреть в Colorlab или в ColorPicker (обратите особое внимание на функцию minimize dE), там честный Lab. Именно через них хорошо видно необратимость. Видны и недостатки алгоритмов, в первую очередь колориметрические нарушения при сжатии. Именно эти нарушения делают невозможным корректный spot color mapping (средствами "обычных" CMM) - поэтому я все время напоминаю, что современный CMS умеет решать задачи лишь image color mapping. Заодно там видно и примитивные ошибки алгоритмов, которые приводят к серьезным искажениям изображений (известным как нарушение image consistency).

 

[almastu]

Ответ: Мелкий вопрос по структуре icc-профайла

Ведь ежели профайл должен честно охарактеризовать это ужасное устройство вывода, то он обязан заявить: "аппаратные данные от 0 0 0 до 5 5 5 (из 256) дают один и тот же цвет - ЧЕРНЫЙ !".
И вот там уже посмотрим, как он будет выкручиваться с ответом на вопрос "вот у изображения черная точка, какие сигналы на моник подавать?"

 

[sabos]

Ответ: Мелкий вопрос по структуре icc-профайла

возможное отличие BtoA от AtoB, имхо, может быть плодом принудительной редакции одной из таблиц

Не гадайте. Потери - слово принципиальное. Смотрите на принцип. Если сжатие приводит к тому, что разные координаты PCS A и B выдают одно аппаратное значение С - то "разжатие" не сможет реконструировать из С разные A и B.

 

[sabos]

Ответ: Мелкий вопрос по структуре icc-профайла

Попробую покрутить Large профайл монитора

Вы думаете, что monitor compensation в шопе умеет пользовать Large? Я не знаток последних версий, но вроде Large-профайлы монитора умел пользовать лишь Newcolor.

 

[Alexey Shadrin]

Ответ: Мелкий вопрос по структуре icc-профайла

Именно эти нарушения делают невозможным корректный spot color mapping (средствами "обычных" CMM) - поэтому я все время напоминаю, что современный CMS умеет решать задачи лишь image color mapping.

Кстати, Фершильд, пишет о том, что мэппинг выполняется по линиям тех перцепционных размерностей, что относятся только к related color stimuli, то есть к изображениям. Однако один из последних прецедентов в РМ -- режим ColorFul вероятно выполняет мэппинг по полноте цвета (судя по названию) и есть надежда на улучшение ситуации в сфере unrelated color stimuli, то есть в spot color mapping.

 

[almastu]

Ответ: Мелкий вопрос по структуре icc-профайла

Вы думаете, что monitor compensation в шопе умеет пользовать Large? Я не знаток последних версий, но вроде Large-профайлы монитора умел пользовать лишь Newcolor.

Пока я только собирался использовать данный профайл как профайл мифического RGB-устройства вывода (принтера такого). Взять, да и поназначать его разным картинкам в шопе. Это-то он, кажется, делать может?.. А работать, естественно, на нормальной, линеаризованной и охарактеризованной по Default видеосистеме - на своем компе ))

 

[sabos]

Ответ: Мелкий вопрос по структуре icc-профайла

режим ColorFul вероятно выполняет мэппинг по полноте цвета

Предположение неверно. Выдам часть инсайдерских "секретов". ColorFull не равно ColorFullness. Режим ColorFull всего лишь пользует CIECAM02 для сжатия. Причем грубо, т.к. интерполяционные алгоритмы сидят в CMM, и далеко не все CMM знают CIECAM. Поэтому ColorFull (для универсальности) вынужден строить mapping с учетом линейной интерполяционной модели. Что приводит к неполноценной CIECAM02 модели - это хорошо видно на сжатиях типа "blue turns purple" и "red turns orange".

 

[Alexey Shadrin]

Ответ: Мелкий вопрос по структуре icc-профайла

ColorFull не равно ColorFullness. Режим ColorFull всего лишь пользует CIECAM02 для сжатия.

Тогда, согласитесь, Саша, что это на совести Гретаг -- кто мешал написать "CIECAM02"? Вместе с тем, CIECAM02 оперирует размерностью colorfullness, прогнозирует ее и, может, все-таки как-то связано?