ICC-профиль изнутри: изучаем детали

[mihas]

Тема эта видимо не на один пост. Народ интересуется устройством профиля внутри, задает детализированные вопросы. Обсудим.

Скриншот из топика "Модули CMM, RI, совместимость с Photoshop" крохотного фрагмента обычной огромной таблицы. Гранулярность CLUT матрицы, равная 33. Первые три столбца любезно подставил wxProfileDump, в профиле их нет, но модули CMM верно прочитают данные четырех столбцов CMYK в той же разметке Lab

Прежде на форуме уже немного в подробностях разбирались детали профилей изнутри в темах:

• Особенности Device Link профайлов (DLP)

• Device link профайл 3cc Lab->Lab коррекция. Правим вслед за EFI Fiery XF

• Как влияет гранулярность на точность цветового профиля ICC

• vcgt editor • редактор video card gamma tag • cielab.xyz/vcgt.php

• Модули CMM, RI, совместимость с Photoshop

• Profile Description Tag - desc: настоящее имя профиля

• Создание колориметрической таблицы target из профиля icc

По ссылкам кое какие детали уже были, но обсудим и те аспекты, которые ранее не затрагивали. Для начала в форме вопросов и ответов.

• Если выставлено Perceptual в Rendering Intent, то по умолчанию преобразование в PCS производится по данным AToB0Tag? (в препарируемом примере все AToB одинаковые - AToB1Tag, AToB2Tag: SameAs="AToB0Tag")

Обычно традиционно почему-то принято указывать дефолтным в профилях перцепционный RI. Но использоваться будет тот, который будет указан в программе, применяющей профиль. Видимо дефолтный вариант внутри профиля на тот необычный случай, когда программа забудет спросить пользователя, какой способ колориметрического преобразования профиля задействовать.

И это распространенная практика, чтобы не плодить сущности, ставить в валидном профиле ссылки от одних таблиц к другим. Если перцепция по расчетам производителя профиля ничем не отличается от относительного колориметрического рендеринга и от неколориметрического Saturation, всегда лучше не просто проигнорировать таблицы, так профиль будет невалидным, а указать в заголовках дублирующих таблиц, что данные для них лежат там-то и там-то, в разбираемом примере на перцепционный тег AToB0Tag ссылаются валидно как на собственный все три разных рендеринга.

То что нет абсолютной колориметрической таблицы в подавляющем большинстве профилей, оправдано спецификацией ICC. Абсолютная колориметрическая таблица всегда вычисляется из относительной колориметрической с использованием белой точки из тега <mediaWhitePointTag> по формулам ICC (28 страница). У меня в софте рилейтив в абсолют и абсолют в рилейтив также вычисляется. Эти же функции ICC задействованы в цветовом конвертере для красок CMYK по фогре 39 в рилейтиве или абсолюте.

Мы все освоили iccMax для преобразования icc в читаемый редактируемый формат xml и обратную последующую упаковку xml в icc. Поэтому если мы, например, встречаемся с неким рипом, управляющим софтом для печати, который по каким-то причинам отказывается использовать например релативный рендеринг профиля и всегда использует перцепционный, а нам надо все наоборот, то нет ничего проще как поменять местами заголовки AToB0 и AToB1 перцепционного и релативного тега, и программа будет считать, что за рилейтив отвечает перцепция а за перцепцию рилейтив изначальные.

• InputEntries="1024" OutputEntries="256".
  В каждой кривой содержится всего 1024 значений, но если для точки нужно два значения, значит должно быть 1024 x 2? Если на входе кривая 1024 значения и на выходе 256 значений, то не происходит нежелательная потеря данных при конвертации в PCS XYZ?

В B-curves профиля прописана гамма sRGB на входе в тег AToB0

• 11.09 КБ • 10823 просмотра

A-curves просто линейные на выходе из тега

• 11.22 КБ • 10823 просмотра

Самое простое сокращенное линейное CLUT-преобразование из RGB в XYZ

• 190.47 КБ • 10823 просмотра

Мы привыкли в обычной жизни к таблицам с двумя осями, где по первой оси располагается шкала, градации, а по второй оси - их значения. Но в профилях на оси градаций экономят, достаточно прописать верно тип данных, их гранулярность, число степов, и программе работы с профилем уже не нужен столбец шкалы, программе достаточно лишь столбца значений. Именно поэтому всего 1024 точки на кривой, а не 1024 умноженных на два. Спецификация ICC обязывает и создателя профиля, и работающую с ним программу, налету подставлять нужную ось градаций к любым кривым и CLUT матрицам. Но нам для удобного чтения таблиц можно воспользоваться приложенной к iccMAX утилите wxProfileDump.exe чтобы смотреть кривые и таблицы в привычном всем виде оси градаций и оси данных, утилита любезно подставляет нам первую ось для удобства (первый и четвертый скриншоты).

Далее смотрим на кривые с разным числом степов. Структура тегов профиля такова, что каждый тег преобразования в ту или обратную сторону должен содержать три элемента: кривые на входе в тег, CLUT или таблицы, кривые на выходе из тега. Иногда не все три задействуются в полной мере, любая из кривых на входе или выходе может быть просто линейной, любая матрица CLUT может быть просто "заглушкой", обманкой, то что программисты называют cap латинскими буквами, не исполнять никаких серьезных действий и быть просто линейной. Так делается для того, чтобы профиль оставался валидным по структуре. Что означают эти три части тега преобразования например AToB0. На входе мы имеем некие RGB. Первые кривые могут их исказить нелинейно перед подачей на CLUT. В разбираемом примере так все и происходит, кривыми на входе в тег применяется гамма-коррекция, причем со знакомой гаммой sRGB. Далее эти предыскаженные данные поступают на CLUT - табличное преобразование из RGB в XYZ. Тут мы видим в разбираемом примере, что стоит линейная CLUT-заглушка, которая просто присваивает крайним RGB-значения их XYZ-значения. Такое не часто встретишь, обычно кривые ничего не делают, а огромная матрица CLUT очень даже работает во всю. Но тут вот так все просто, простейший CLUT с минимумом необходимых данных, ничего нелинейного; так порой делают в калибровочных девайс-линках, где нужен только CLUT-обманка, заглушка для валидности, всю работу выполняют только кривые, а на входе и выходе из CLUT одно и то же. И третья часть тега - на выходе другие кривые уже предыскажают три канала XYZ. Идея понятна: на входе в тег мы можем кривыми поправить или оставить линейными сигналы RGB, на выходе - поправить или оставить линейными сигналы XYZ. С CMYK и Lab все то же самое. Каждый тег обязан иметь в арсенале все три преобразования curves-CLUT-curves, и он их имеет. Даже если какие-то из них ничего собственно не делают, отдают линейные данные. Эта особенность уже затрагивалось в теме Особенности Device Link профайлов (DLP). И препарируемом примере на выходе просто 256 линейных значений, в принципе эту часть можно было бы сократить и до 2 линейных значений, но видимо в профайлере оставлен программистами задел на тот случай, если потребуются нелинейные вмешательства кривыми в координаты XYZ. При использовании профилей происходят интерполяции любых кривых и CLUT профиля, и там где важна точность повыше - там 1024 точки на кривой или более, там где речь просто о линейной заглушке валидности - вполне хватит и 2 и конечно 256 точек на абсолютно ровной прямой.

В обратном направлении преобразования BToA из PCS XYZ в каналы RGB и кривые задействуются в обратном порядке. Вначале на входе линейные XYZ не подвергаются воздействию кривых, а вот после CLUT-преобразования, на выходе - уже RGB значения подвергаются воздействию зеркальной, обратной кривой тегу AToB тонопередающей функции.

На выходе из тега BToA0 кривые, обратные, зеркальные кривым первого скриншота AToB0

• 10.91 КБ • 10823 просмотра

Помимо бесплатных iccMAX и его wxProfileDump - используйте также для визуализации кривых профиля бесплатный Profile Inspector, он многое что показывает очень наглядно.

• С обсуждаемым профилем у меня в печати все желтит даже на синей бумаге. От чего?

Белая точка нетипичная D65 в данном профиле, профили печати все как на подбор с белой точкой D50. Но стандарт sRGB - это D65, вот тут и совмещали ежа с ужом не совсем корректно.
Препарируемому профилю не хватает только тега хроматической адаптации CHAD от D65 к D50, белая точка необычная D65 для <ProfileDeviceClass>prtr - описания профилем принтера. CHAD кстати есть в подобных профилях sRGB от ICC (тут было немного подробностей).

• Обязательно ли нужно объявлять кривую без преобразований?

Обязательно. В этом состоит валидность профиля - все его регламентированные части должны быть на своем месте. В этом и сила и слабость профилей. Слабость в том, что как бы отводится лишнее место под четкую структуру, которая как бы может быть и не задействована в расчетах. Слабость в том, что если знанием структуры воспользуется злоумышленник - это может сильно повредить компьютеру, как в любой продвинутой технологии структуру icc к сожалению можно использовать во вред, об этом расскажу позже. Сила в том, что четкая структура позволяет экономить на различного рода предисловиях, разметках и проверках любого тега, программа любая знает что до и после CLUT должны быть поканальные кривые а не что-либо другое, ей не надо долго объяснять что тут вот кривые, прога и сама знает, что тут могут быть только кривые. И модуль CMM не запутается (а ведь мог бы).

[mihas]

Вспомнился интересный момент, когда потребовалось аккуратно поправить кривые A-curves на выходе из тегов BToA преобразования Lab➔CMYK. Любопытная история, чтобы ей поделиться. Тема с этими профилями была тут FOGRA39 для флексографии, но в ней рассказано об удобстве применения данных профилей в заданных условиях печати, а не о "кухне" приготовления этих особенных профилей.

А там все просто, я именно кривой на выходе из тега Lab➔CMYK преобразования (цветоделения) вычитаю в высоких светах кусочек тоновой кривой, которой не будет на флексографских формах, а значит их также удобно не видеть у себя на экране и цветопробе, отказаться от той части полутонов на краю диапазона, которых точно не будет воспроизведено в печати, еще на стадии цветоделения.

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

[mihas]

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

И вот мы видим профиль, любопытный вариант sRGB, в котором явно есть все теги с разными рендерингами, да и еще все эти рендеринги равны. И тут у модулей CMM не остается иного выбора, как считать строго по профилю и строго по тому RI, что мы укажем в программе. Если вы возьмете классический tristimulus профиль 1998 года sRGB IEC61966-2.1 например отсюда, то простое его изучение в профайл-инспекторе покажет, что в нем просто нет перцепционного рендеринга. А в нашем препарируемом сейчас профиле sRGB класса prtr - явно и однозначно перцепционный рендеринг есть. Натравите на него любой модуль CMM и вы увидите одинаковые цветовые результаты у этих модулей. Подумалось, что это важно еще раз проговорить в аспекте проникновения в самую суть того или иного профиля. И к слову приведу старую мысль, которая мне кажется должна быть четко отрефлексирована каждым, кому не безразлична внутренняя суть icc-профилей:

Есть две веские причины, почему лучше выбрать относительный колориметрический рендеринг при отображении, а не перцепционный:

1) Совместимость с Photoshop. Можно спорить на тему, хорошо это или плохо (я думаю что хорошо), но Photoshop при отображении всегда использует таблицу рилейтив профиля, даже если выбран другой RI; отличный от Relative интент задействуется только при преобразовании из профиля в профиль, а отображение - всегда только относительное колориметрическое.

2) Зачастую в профилях типа tristimulus RGB, таких как sRGB или AdobeRGB, просто отсутствует таблица перцепции как таковая. В результате к отображению будет применена все равно таблица Relative, или же перцепция будет рассчитываться модулем CMM операционки налету, что плохо влияет на качество отображения. Чтобы не плодить энтропию, когда мы достоверно не знаем, как поведет себя тот или иной софт в отсутствии таблицы Perceptual - применит таблицу Relative профиля или будет пытаться просчитать перцепцию налету - лучше осмысленно установить Relative и не путаться в догадках.

[mihas]

Дамп вирусного профиля ColorLogic показывает, что данные не соответствуют структурной разметке ICC, такое зашифрованное разупорядоченное расположение данных напрямую запрещено консорциумом ICC и не просто так

• 272.92 КБ • 10666 просмотров

Синий канал вирусного профиля ColorLogic, не соответствующий структурной разметке ICC: прямо запрещено ICC для расширений файла icc. Приводит к обрушению системы

• 212.12 КБ • 10666 просмотров

Градационные характеристики синего канала вирусного профиля ColorLogic в сравнении со здоровым профилем i1P по тем же колориметрическим данным

• 64.38 КБ • 10666 просмотров

Обещал выше рассказать про уязвимость четкой продуманной экономичной структуры icc-профилей. Рассказываю.

Я уже обращал выше внимание на этом и этом скриншотах, что wxProfileDump любезно подставляет нам для удобства препарирования верную разметку осей, Lab для первой ссылки и градационные для второй. В профилях этой разметки не содержится. Спецификация ICC предполагает, что каждая программа самостоятельно сделает разметку данных, и в ICC настолько уверены, что данные в профиле корректные, что модули CMM и программы с колорменеджментом и не думают проверять данные на корректность и безопасность, как бы по умолчанию к ICC есть доверие. Консорциум ICC прямо и недвусмысленно запрещает каким-либо образом шифровать файлы с расширением ICC, хотите играть в эти игры - называйте файлы иначе, но не ICC и не ICM.

И вот какой вышел случай. Коллега вместо того, чтобы как все купить или обменять профайлер CoPrA от ColorLogic, зачем-то сгенерил профили в демо-версии. И оказалось, что демо-версия таким образом шифрует и разупорядочивает структуру файлов с расширением ICC, вопреки прямому запрету консорциума, что они нехило так сносят всю колориметрическую систему. Чувак попросил меня протестить эти зловредные файлы, после крушения до синего экрана у меня ни в какую цветопробный рип не выводил цветопробы, для Windows эта ошибка ее системного модуля CMM была слишком серьезной, чтобы просто так пройти мимо нее, умная Windows просто после крушения запрещала программам как обычно работать с цветом.

Помогло полное восстановление системы из бэкапа образа системного диска, я потратил на эту ерунду время и матерился, а потом, когда все наладил, полез смотреть вредоносные файлы ICC от CoPrA ColorLogic на предмет содержащихся в них засад. Привел на скриншотах, что не так с доверительным отношением системы к четкой структуре ICC. Данные в CLUT просто располагаются в хаотичном одному ColorLogic известном порядке, при попытке применить к ним известную структуру ICC - происходит обрушение системы из-за опасных математических ошибок в расчетах по какой-то каше из цифр, а не структурированных как положено данных. Это обычная, кстати, история, как программист сто раз проходил, что функции сложных интерполяций не работают с ненормальными не структурированными ни по одной из осей данными. А системный модуль CMM только интерполяциями и занимается. И конечно, CMM данные не проверяет в профилях на предмет безопасности, просто в голову никому не приходило, что такое вообще может потребоваться.

С моей частной точки зрения, здоровому умом и душой человеку не придет в голову так представлять табличные данные, чтобы они уверенно обрушали CMM модуль операционной системы. Консорциуму ICC такое в их спецификации ICC не могло и прийти в голову. Но какие-то альтернативно-одаренные в ColorLogic решили, что правила им не указ, прямой запрет шифровать файл с расширением ICC им не указ, и лабают в демке своих программ подобные вирусные профили-убийцы. Так что увидите в дампе "Creator: CoLg" - проверяйте на всякий случай структуру данного изделия с расширением ICC, оно может быть на редкость вредоносным. Не забывайте иногда бэкапить системный диск, чтобы быстро восстановиться в случае крушения, всякое может случиться.

Один из примеров этих вирусных профилей ColorLogic лежит по ссылке, но если вы не эксперт по препарированию профилей - отнеситесь к этим файлам ICC со здоровой опаской. Продавец по ссылке пишет, что файлы безопасны, но последнее дело доверять продавцу. Он не понимает, о чем пишет, но прав лишь отчасти: по ссылке три DLP не настолько сильно вредоносные, как RGB и CMYK от CoPrA demo. ColorLogic может делать какие угодно файлы для своих демо-программ, но подобные поделки вполне официально не имеют права носить релевантное для операционной системы расширение имени файла ICC, это важно отрефлексировать. Одна из тактик злоумышленников - замаскировать вредоносный файл под что-то безобидное, так порой вирусные скрипты маскировали под картинку с расширением jpg в надежде, что jpg откроют не в Фотошоп или FastStone, а браузером, и браузер отработает исполняемый сценарий, а не картинку. Ну и тут также: если вредоносный icc использует не демка от ColorLogic, а Фотошоп или цветопробный рип - система гикнется.

Можете себе представить, что авторы демо-конвертера картинки в jpg пишут в примечании, что jpg нельзя использовать в обычных программах типа Photoshop, XvView, Chrome и Firefox, а можно только в нашей демке. А иначе крах операционной системы. Нет, представить такого мне лично не получается при всей фантазии. Но именно это делают в ColorLogic с их демкой CoPrA по упаковке колориметрических данных в псевдовалидный icc.

[mihas]

Использование Device Link в Photoshop

• Можно ли избежать преобразования в PCS Lab и напрямую конвертировать RGB в CMYK, минуя PSC?

Конечно можно, первая ссылка первого поста Особенности Device Link профайлов (DLP) именно об этом. Эти специфические профили девайс линки позволяют связать два профиля в один, взять RGB➔Lab одного профиля и Lab➔CMYK другого профиля и напрямую пересчитать все в единый DLP RGB➔CMYK. В обычной жизни девайс линки не слишком востребованы, но бывают удобны в тех случаях, когда не получается научить софт тот или иной того или иного принтера как положено отрабатывать связку RGB➔Lab➔CMYK между двумя профилями.

Девайс линк или DLP нельзя внедрить в документ или картинку, такой профиль не может служить источником отображения файла по цвету, потому что цвета - Lab или XYZ - в девайс линке просто нет, PCS как бы нет, профиль такого типа может преобразовать каналы RGB в краски CMYK, в обратном порядке, краски в краски, и это три разных девайс линка, но визуализировать по цвету это преобразование в DLP будут обычные не-LinkClass профили с PCS в моделях Lab или XYZ.

Минимально необходимая матрица CLUT и минимально необходимые Curves

• 190.48 КБ • 10612 просмотров

• Как выглядят в профиле минимально необходимые кривые из 2 значений 0 и 100 и такие же минималистичные CLUT?

Показал на скриншоте ответ на этот вопрос.
Препарируемый профиль класса Link по ссылке.
Это переход через кривые от фогры 39 к фогре 51.
Есть и обратный переход от фогры 51 к фогре 39 по ссылке.
Оба профиля созданы в этом софте для калибровки.

• Читаю неделю спецификацию ICC, но мало что понимаю.

Да это такой специфический документ, попробуйте это изучение наряду с wxProfileDump и Profile Inspector - поможет лучше понять. Я кстати был удивлен, когда писал свой профайлер для CMYK и RGB, что тот же важный тег gamt или Gamut Tag вообще не имеет внятного описания в спецификации ICC, что он собой представляет. А этот тег использует Фотошоп, например, чтобы красить серым заохватные при включении Gamut Warning. Так что самому пришлось сочинять алгоритм от и до. То же самое с алгоритмом перцепции - никаких правил нет, сочиняй что хочешь, да так и происходит на практике со всеми профайлерами, есть перцепции похуже и получше. Даже очень серьезные колористы не очень внятно понимают, что делает перцепция в профиле, их все тянет на разукрашивание по восприятию, а в профиле это просто умный CLUT переход от большего охвата к меньшему, я его на основе CIECAM02 построил. Прямо скажем, спецификация ICC программисту не очень помогает. А вот iccMAX и wxProfileDump - отличные инструменты, чтобы поучиться на примерах.

[mihas]

• Построить профиль CMYK - нетривиальная задача. Интересуюсь у тебя, как у написавшего такой профайлер в 2021 году. И смотрю код Грэма. 2 вопроса.
  
  1) Какой из бесконечного количества CMYK-ов с разным количеством черного взять для определенного лаба? Грэм находит минимально и максимально возможное количество черного для заданного Lab-а, и дальше применяет в этом диапазоне разные функции. Самый простой его вариант - это взять разность максимального и минимального черного и умножить на 0.5. По какому алгоритму ты считаешь Lab->CMYK в iccGPU?
  
  2) Как найти для выбранного CMYK-а Lab с нужной точностью? Грэм делает полные сетки интерполяцией прямой таблицы и ищет кубик с нужным черным, в который попал заданный Lab. Скорее всего делает несколько итераций, делая более подробные полные сетки внутри ранее найденного кубика, чтобы получить достаточную точность. Полную сетку на весь диапазон с маленьким шагом делать долго. До конца я это еще не изучил. Как ты в iccGPU находишь Lab-ы для заданных тобой CMYK-ов?

Скриншот из мануала профайлера iccGPU по ссылке


Оригинал, голубой канал при обычной максимальной ширине и голубой канал при эксклюзивной максимальной ширине iccGPU


На картинке снизу представлен черный канал в результате цветоделения профилем Less GCR in Skintones iccGPU, в телесных черной краски нет, а в сером фоне - выше крыши

Это интересно, как сделано у Грэма, в первом вопросе кажется есть ответ на тему, почему в каналах сильный шум у Грэма. У меня тоже как у многих есть шум в каналах на пережатых оригиналах jpg, но меньше, и я не знаю как определить и пофиксить его источник. Шума нет только в профилях Фотошопа, но они ужасны, лучше шум, чем вот это вот все с фотошоповскими грязными красками.

У меня таблицы цветоделения строятся по принципу инверсии данных о цвете красок: задаются нужные краски с большой шириной черного на 9 шаге конструирования профиля пользователем. Находится цвет этих красок CMYK➔Lab, и лишь затем из этих пар создается таблица цвет-краски Lab➔CMYK. Генерация черного, экстра-ширина черного таким образом не похожа ни на один известный профилировщик, позволяет добиваться сепараций максимальной чистоты цвета: необычайно востребовано в классном офсетном цветоделении. Среди пресетов генерации черного есть Skin, где создается исключение для телесных в старой доброй полиграфической традиции, и в правильные по цвету телесные черная краска не попадает, там идет загрязнение через голубую. И в принципе сам пользователь может задать любые красочные таблицы, какие ему нравятся, я потому и пишу про свой профайлер, что это "конструктор" профилей, потому что пользователь максимально наделен полномочиями разработчика, может с помощью вытянутых в интерфейс удобных промежуточных таблиц творить все что угодно в профиле, при этом не обладая навыками в программировании: с таблицами умеют работать все.

Лабы для заданных мной цмиков я создаю, фактически построив в программе iccGPU предварительную модель профиля, это дополнительная вычислительная операция. То есть я не иду по принципу Фотошопа, типа в тесткарте CMYK-и дали такие-то лабы, значит возьмем для лабов эти ужасные цмики. Я считаю внутри свою таблицу CMYK-Lab и на ее основе уже считаю таблицу самую важную, ради чего все затевалось - цветоделение Lab-CMYK. Чуть больше чем у других вычислений, но и результат никем неповторимый по точности и чистоте красочных сепараций.

Таким образом короткие два ответа на вопросы такие:

1) Я вообще не занимаюсь перебором бесконечного кол-ва возможных CMYK-ов и нацеливаюсь сразу только на чистые красочные смеси без третьей загрязняющей цветной (исключение для телесных только в пресете Skin).

2) Нужная точность лаба для заданного цмика у меня определяется просто многомерной сплайновой интерполяцией, если тесткарта достаточно развернутая и точно промеренная - то промежуточные значения цмиков и их цвета между известными цмиками и их цвета рассчитываются достаточно точно, многомерной сплайновой интерполяцией. Заметь, не трилинейной более быстрой и менее точной как в CMM при применении профиля. Нет, долгой и нудной, на нескольких ядрах проца, на хилых процессорах до минуты, поначалу и с применением графического процессора (но эту часть я позже сократил и взвалил больше параллельных задач на ядра CPU, а не на GPU), - а именно сплайновой многомерной интерполяцией, у сплайнов точность выше для таких нелинейных данных, как измеренная тесткарта печати, чем у кусочно-линейных, трилинейных и прочих линейных интерполяций.

Кстати, процессор айфона неплохо справляется с построением профиля у меня в iccGPU, не хуже новых i7-i9 по скорости. Но это уже не совсем важные наблюдения, просто к слову пришлось.

• У тебя на девятом шаге задается массив СМУК значений (примерно 2000 штук). Выглядят вот так:
  0 6 0 0
  0 6 6 0
  0 6 14 0
  0 6 21 0
  и т.д.

Все верно. Можно больше 2000, но тогда расчеты замедляются. Пользователь может по образцу ввести свою таблицу на 3000 и более значений, только дольше будет ждать расчетов.

• Примечательны они тем, что в них всех одна из красок 0. Т.е. для тех значений, где есть черный, это СМУК с максимально возможным черным.

Да там нет загрязнения третьей цветной краской, то чем жутко грешит хоть тот же Фотошоп и чего мне крайне не нравится. Но пользователь может создать таблицы с 3 цветными при желании. У меня три цветных вместе появляются в секторе телесных при выборе пресета Skin.

• Затем для всего этого набора СМУК-ов ты находишь Lab-ы. Этот набор СМУК-ов всегда один и тот же? Из этого набора можно интерполяцией построить обратную таблицу для максимально возможной генерации черного. Но нам же нужна не совсем максимальная генерация?

Почему не нужна? Мне всегда нужна максимальная ширина черного. Не путай с тяжестью GCR - это разные настройки.
Один ли и тот же? Да что пользователь выберет. Я его приглашаю в соавторы и создатели без навыков программирования, участвовать простыми таблицами в управлении создания профилем. Мне такая идея нравится, все эти промежуточные расчеты разработчики прячут, а я предлагаю поучаствовать.

• На следующем шаге строится вот такая штука:
  36.500 -0.002 -0.002 50.188 49.264 44.632 51.311
  37.000 -0.002 -0.002 49.784 48.920 44.330 50.599
  37.500 -0.002 -0.002 49.383 48.574 44.029 49.889
  где набору Lab-ов с a и b равными нулю сопоставляются значения СМУК-ов с некой генерацией черного.

Да тут задается нейтраль и около нее с привычными типичными генерациями GCR или смешанной. Эта таблица присовокупляется к первой из 2000. Туда же присовокупляется таблица с углами куба за охватом тесткарты. И вот из них ->

• Как дальше из этих двух таблиц (или еще из чего-то еще?) строится обратная таблица с некой генерацией черного отличной от максимальной?

-> с помощью многомерной сплайновой интерполяции строится огромная таблица непосредственно самого профиля.

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

Без смеси всех 4 красок с максимальной черной - нет суперблека. Этот суперблек создается на 11 шаге вычисления генерации черного. Скриншот с модели 9 шага чистых трехкрасочных смесей без третьей загрязняющей цветной.

• 624.89 КБ • 10419 просмотров

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

Нельзя слишком много подавать полей на вход в многомерную сплайновую интерполяцию, она тормозная от этого, а вот на выходе гранулярность в много десятков тысяч значений матрицы CLUT - это ядра проца хорошо молотят.

Мне была интересна архиширина черного - я ее сделал. Вот тут в 21 году я поясняю почему мне хочется максимальную ширину всегда.

• Не понимаю я только одного - зачем тебе при максимальной генерации черного в насыщенных цветах меньшая генерация черного в цветах ближе в нейтрали?
  Делал бы maxK везде. Чем это плохо?

Недостаточная чернота фотошоповского (и прочих) maxK - там же реально суперчерный одной краской, и он по светлоте не тянет сильно до 4-красочного суперблека типа 60-40-40-100. Я оставил в таблице насыщенных нейтральный центр по оси L с Хромой до 4 в рилейтиве под ту или иную нейтраль, тот или иной суперчерный, тот или иной ранний или поздний старт черного в светах, на все случаи жизни пока 3 пресета на 11 шаге построения профиля. Что касается не теней а светов - в GCR-пресете у меня стартует черный с нуля. Но по традиции оставил и пресет a-la fogra 39 с ненулевым стартом черного. Все это удобно спроектировать и этим удобно управлять пользователю с помощью отдельной таблички для ахроматичных.

[mihas]

• Профиль сканера от Profile Maker внедряется в картинку в 24 Photoshop и не внедряется в 25 Photoshop. Второй считает, что профиль Invalide. Отчего так и что не так с профилем?

Профиль сканера традиционно содержит таблицы только одного направления преобразования - RGB➔Lab. Обратного направления Lab➔RGB таблиц в профиле сканера от PM нет. Такие однонаправленные профили могут вызвать сложности в работе программ работы с цветом, Illustrator уже очень давно не признает такие профили валидными, до Photoshop видимо это дошло только сейчас.

Типичный профиль сканера: в одном направлении преобразования тег A2B0 есть, а в другом направлении B2A0 тега нет. Часть программ не работает с такими однонаправленными профилями.

• 20.89 КБ • 10351 просмотр

Но традиционно такие профили сканера с одним направлением преобразования считались валидными. Я как-то попробовал ради экономии размера специального маленького профиля CMYK ограничиться одним направлением преобразования CMYK➔Lab для отображения цветоделений, но без создания цветоделений Lab➔CMYK, и Photoshop такой профиль тогда еще признал, как валидный, а Illustrator не признал.

Как-то на printplanet интересовались "почему бы просто не использовать инверсию таблиц B2A для сопоставления охвата принтера с PCS?" Уже отвечал на этот вопрос: налету модулю CMM такую обратную таблицу теоретически просчитать долго и так компьютер просто будет не успевать, представляете если простенькая картинка визуализируется минуту? Вы хотите копипастом что-то вставить в ваш скан, но профиль не позволяет преобразовать ваш цвет в каналы скана, совершенно критическая ошибка на мой взгляд. Но модуль CMM не умеет считать инверсные таблицы, и тот же Фотошоп ранее предупреждал отдельным алертом, что цветоделение по профилю только CMYK➔Lab выполнено быть не может. Теперь видимо решил вообще не связываться с однонаправленными профилями без зеркальных таблиц в обоих направлениях преобразования. И логика у такого решения без сомнения есть.

Еще одна причина невалидности профиля сканера может быть в том, что в моем примере на скриншоте прописана перцепционная таблица A2B0, а Фотошоп, вообще-то, для отображения использует всегда релативную таблицу A2B1. Это, я думаю, тоже веская причина, почему фотошоп теперь может не признавать валидным профиль без релативной таблицы.

В рамках нашей темы погружения в тонкости профилей надо понимать, что цветовые охваты таблиц RGB➔Lab и Lab➔RGB разные, края разные. CMYK каналов это касается в той же степени. Одни таблицы определяют цвет каналов, любых их сочетаний. И этот цвет ограничен неким охватом устройства. А другие таблицы просчитывают переход из любого цвета в каналы, и этот цвет может быть и гораздо шире возможностей устройства, но таблицы должны содержать отклики каналов на весь куб Lab со сторонами 100х255х255. Подробнее про куб Lab в цветовом профиле было в недавнем эссе про CIE Lab. А значит, создание зеркальной таблицы для однонаправленного профиля - не такая простая задача, как кажется, не решается налету. При зеркальном пересчете надо заново структурировать таблицы в нужной последовательности на нужной шкале CLUT, а это не быстро все вычисляется.

[mihas]

анимированные теги rTRC профилей sRGB с гаммой sRGB и профиля AdobeRGB1998 с гаммой 2.2

• 22.81 КБ • 10135 просмотров

• Чем можно быстро подменить в профиле гамму sRGB на гамму 2.2?

Самое просто наверное, в профайл инспекторе открыть профиль с гаммой 2.2 в тегах TRC, открыть тег rTRC, кнопкой Export сохранить эту кривую в файл curve.txt, и потом в профиле с гаммой sRGB назначить тегам rTRC, gTRC, bTRC эту кривую гаммы 2.2 кнопкой Import.
Но я бы посоветовал также после этой операции не просто сохранить профиль с новым именем, но изменить в нем тег desc - внутреннее имя профиля, потому что система читает не имена профилей, а теги desc, будет очень неудобно и не практично, если разные профили с разными TRC будут иметь одно и то же внутреннее имя, можно запутаться. Подменить desc можно на Маке просто двойным щелчком по профилю в ColorSync, можно под Windows перевести профиль в XML и там поправить desc, а потом перепаковать XML обратно в ICC, инструкция тут. Вариант любого hex-редактора тоже годится, но там уж без сдвигов (offset), байт в байт, символ в символ, нельзя будет менять длину внутреннего имени профиля, иначе весь профиль посыплется, все ссылки тегов на их таблицы посыплются. Также простой способ назначить tristimulus профилю степенную гамму с любой степенью - пересохранить такой профиль в обычном Photoshop по Ctrl+Shift+K, указав Custom степенную гамма любую.

Тонопередающая функция EOTF современных HDR 10-битных устройств высокого качества без потери детализации в глубоких тенях

Потеря 4% тонового диапазона в 10 битах при степенной гамме 2.4

На анимашке хорошо видно, что при гамме 2.2 (и выше кстати тоже) кривая в глубоких тенях, близких к нулю (левая нижняя часть графика) лежит на оси значений, а значит несколько темных оттенков слипаются в один, из 8-битного диапазона 0-255 выпадают несколько полезных различимых значений в глубоких тенях. Этот недостаток степенных функций гаммы выше 2.1 был отмечен инженерами еще в прошлом веке, и была придумана гамма sRGB, затем гамма L, затем EOTF или PQ (перцептивное квантование) в современных 10-битных устройствах, где вводились отдельные правила для глубоких теней при обычно остальной степенной кривой. Терять часть градаций в тенях не хотели в прошлом веке, и тем более их не теряют в современных устройствах отображения и в современных форматах записи графики и медиа уровня DolbyVision, HDR10, HDR10+. Подробности были в теме "Пара соображений о гамме sRGB, гамме 2.2 и современном стандарте Display P3" по ссылке. Можно посмотреть рекомендации по тонопередающим гаммам и EOTF (PQ) и HLG (гибридно-логарифмической) международного союза электросвязи для современных форматов записи графики и главное медиа: везде тени просчитываются по отдельной функции, чтобы эффективно решать проблему степенных 2.2 и выше с потерей ими части темных градаций.

[mihas]

Apple Wide Color Sharing Profile.icc и Display P3.icc

• 84.55 КБ • 9518 просмотров

Мы уже посмотрели в позапрошлом посте однонаправленный профиль класса input, в котором есть таблицы преобразования из RGB в цвет для отображения, и нет таблиц Lab➔RGB для конвертации из цвета в этот профиль.

Сегодня столкнулся с таким, опишу в чем дело. Тут у Адобы немного обсуждают профиль 2016 года Apple Wide Color Sharing Profile.icc, который изредка встраивается в фотку айфона вместо привычного встроенного Display P3 2017 года (можно скачать Display P3.icc).

Пользователи жалуются, что программы не всегда корректно работают с профилем Apple Wide Color Sharing Profile.icc. Адоб ответов не дает, а мы с вами уже знаем причину: в профиле есть таблицы A2B и нет таблиц B2A, такой типичный профиль класса input, а не display: картинку по цвету опишет, но создать из цвета такую картинку в RGB не даст. Я проверил в фотошопе, все верно: конвертнуть куда-то из Apple Wide Color Sharing Profile.icc RGB можно, а вот нечто конвертнуть в этот профиль - уже нет, он благоразумно фотошопом не отображается в списке профилей, в которые можно конвертнуть изображение.

Профиль прикладываю, извлек (/Library/Scripts/ColorSync/Extract) из айфоновской картинки, пересланной по почте Gmail, именно на этом этапе конверсии в жпег из родного формата HEIC возможно внедрение в картинку как родного Display P3, так и устаревшего Apple Wide Color Sharing Profile.

Сам профиль Apple Wide Color Sharing Profile.icc по цветовому охвату небольшой (заметно визуально меньше, чем Display P3), очень похож на маленький охват sRGB с некоторой разницей в светах. Отставляю тут на память, может кому пригодится.

[mihas]

Тонопередающая гамма-функция большого медийного цветового пространства Rec. 2020 (BT.2020)

• 44.5 КБ • 9498 просмотров

В позапрошлом посте мы сравнивали на анимашке степенную гамму 2.2 и гамму sRGB в глубоких тенях.

Сейчас привожу скриншот с профиля большого медийного охвата Rec. 2020 (BT.2020) и его тонопередающей кривой или функции гаммы. Как видим, также в этом современном стандарте цвета, включенном в CSS v4 в качестве одного из трех основных (еще основные sRGB и Display P3), обсчет кривой в тенях осуществляется по отдельным правилам, отличным от степенной функции, и в глубоких тенях создается шикарная разделка локальных контрастов, тени не залипают на одном и том же значении по несколько разных оттенков, как в любой степенной функции выше 2.1.

Эта функция гаммы описана в ITU-R BT.2020-2 p.4 и в виде функции на яваскрипт приведена тут у CSS, также пространство Rec. 2020 с его особенной гаммой доступно в цветовом конвертере.

Если записать коротко, то функция гаммы для Rec. 2020 выглядит так для диапазона 0-1:

Код: Выделить всё

companded = (linear <= 0.018053968510807) ? (linear * 4.5) : (Math.pow(linear, 0.45) - 0.09929682680944);

А обратная, возвращающая к линейности для корректного перехода в цветовые стимулы XYZ из нелинейных каналов RGB, так:

Код: Выделить всё

linear = (companded < 0.0812428582986315) ? (companded / 4.5) : Math.pow((companded + 0.09929682680944) / 1.09929682680944, 1/0.45);

[mihas]

Перцепционный гамут-маппинг от iccGPU (схема ниже) и от ColorToolbox

• Должны ли в icc-профиле совпадать цветовые охваты таблиц колориметрических (рилейтив) и таблиц неколориметрических (перцепция и сатурейшен)?

Не должны. И при цветоделении CMYK зачастую даже лучше, когда не совпадают, чем когда совпадают.

Я в своем профайлере сделал три варианта разных перцепционных охватов и четвертый вариант по сути самой мощной перцепции записываю в таблицу сатурейшен. Все варианты - результат разного раздутия охвата с помощью CIECAM02, то есть проверено давно, что очень красиво и естественно, сбалансированно. Я исходил из того при проектировании профайлера iccGPU, что к перцепции мы прибегаем чаще, когда что-то в охват не лезет, требуется сжатие. Ну я и жму из большего в меньший по CIECAM02 красиво, плюс фишка маппинга с двуразмерностью светлоты и насыщенности, тоже применительно к светлым RGB и темным краскам. То есть у меня охват перцепционных таблиц априори больше охвата колориметрического рилейтива, осмысленно, специально. А охват таблиц Saturation - еще больше. Примерно так все делают я думаю, просто не у всех задействуется красивый сбалансированный CIECAM02 для создания охвата перцепции из релативной таблицы с раздутием или сжатием. И не все разработчики профайлеров поднаторели в цветоделении, чтобы управлять светлотой при сжатии насыщенности. Перцепции у всех профилей разные, это только препрессору кажется, что над перцепцией трудится Фотошоп или рип и что-то там как-то странно сжимает. Да ничего подобного, над перцепцией трудится не Фотошоп и не рип, а создатель цветового профиля, или точнее автор программы для создания цветового профиля. Перцепция сидит в таблице CLUT профиля, а не где-то в коде Фотошопа или рипа. Вот это знание надо четко отрефлексировать. Оно поможет вам в выборе профилей и профайлеров с самой лучшей самой красивой перцепцией.

Перцепция - это восприятие, и некоторые колористы даже думают - ну тут типа в профиле надо покрутить тона, перестроить зависимости светлот и насыщенностей как-то не линейно, а типа по восприятию как-то красиво. Ничего подобного, конечно. Перцепционная таблица профиля отвечает за хороший гамут-маппинг. В идеале конечно маппинг бы для каждой картинки свой индивидуальный, и Грэм это пробует, но это штучная работа и очень небыстрая, обычно в профилях все же просто некие общие правила для всех картинок по перцепционному преобразованию. Все эти перцепции по-разному проектируют, и у меня она не такая как у Гейделя, а у него не такая как в CoLg. И так и должно быть. Тут как бы разработчик профайлера и его перцепции пытается сделать цветокоррекцию со сжатием заохватных для всего на свете с помощью таблиц CLUT, и конечно представление об этом у всех различные. Я как офсетчик мыслю, как издательский технолог, другой разработчик как программист мыслит, все по-разному.