В качестве алаверды к предыдущему посту имею сообщить, что хвалимый многими модуль дисплейной калибровки Argyll CMS мне не понравился:
Задача-максимум: добиться одинакового визуального воспроизведения нейтральных плашек на двух мониторах не достигнута. Формально dE меньше единицы, но реально глаз видит разницу (которую можно устранить кривой в зеленом, но удобных средств редактирования LUT монитора у меня под рукой не было).
Задача-минимум, собственно калибровка и профилирование, выполняются относительно неплохо, но калибровка идет средствами LUT видеокарты (т.е. 8-битной таблицы на DVI), точность работы средств, пищущих в LUT монитора - сильно выше (это видно при рассмотрении серого ступенчатого клина). Матричные профили имени Argyll мне при этом вполне нравятся, табличные - не нравятся.
Использовать сам Argyll (коммандлайновые утилиты) необычайно мучительно, GUI сильно упрощает процесс. dispcalGUI задачу управления вполне решает.
С учетом вышесказанного, остался жить с basICColor.
В процессе этих упражнений, пронаблюдал эффект с потерей точности уже в CMM-engine (в фотошопе), который легко воспроизводится (и как только я его объяснил в уме, он перестал быть неожиданным):
Калибровка и рабочий профиль у меня совпадают по точке белого (D50) и тоновой кривой (L*).
Берем ступенчатый серый клин (я использую мишень от Norman Koren) в пространстве sRGB (D65 и степенная гамма-кривая), выводим фотошопом на экран, получаем (видимую) разноцветность по патчам.
Эффект проявляется только для табличных (LUT) профилей и связан, естественно, с ошибками интерполяции содержащихся там таблиц (при построении условного device-link профиля пространство файла-пространство монитора). Для матричных профилей такой пересчет интерполяции не требует и, соответственно, ошибок не создает.
Я несколько опережаю события и фактически презентую незаконченное микро-исследование, но мне кажется полезным немножко обсудить методику с сообществом, прежде чем доделывать работу до конца.
Текущие стандарты (ISO 12232) на чувствительность цифровых камер довольно креативны: специфицируется значение, которое должен иметь средний тон (18%-й серый) в sRGB-файле, а про RAW ничего не говорится. Неявно предполагается, что RAW обрабатывается каким-то проявителем конвертором и, соответственно, чувствительность оценивается у всего комплекса камера-конвертор. Собственно, оно так и было в пленочном мире, пока не проявишь - ничего не понятно.
Вместе с тем, линейная передаточная характеристика современных цифровиков и доступность RAW-данных в цифровом виде позволяют подойти к проблеме и с другой стороны.
Вот пишут мне знакомые в почту, что всем российским покупателям Vuescan автор предлагает халявно проапгрейдиться по случаю появления русского перевода. Даже тем, кто стандартную версию покупал с годом апгрейдов. Я, правда, не сумел вспомнить E-mail на который свою копию регистрировал и подозреваю, что это был профуканый мой мейлбокс на rambler.ru.
Сходил Vuescan-у на сайт, прослезился, вспомнил молодость. Оказывается, впрочем, разовый бесплатный апгрейд предлагают всем покупателям, по случаю 10-летия программы.
Проект LibRaw стал настоящим — у нас завелся живой форумный тролль. Как от многих таких троллей, от него есть и некоторая польза: если кормить его вдумчиво, то можно заодно разобраться с какими-то вещами, до которых не доходили руки. В данном конкретном случае
я разобрался с мониторным softproof (т.е. эмуляцией одного монитора на другом) и с пользой от этой техники для обработки изображений:
поиск невидимых (искаженных) цветов на собственных картинках;
оценка того, как изображение будет выглядеть на чужом мониторе (в том числе и в приложении, которое ничего не знает про профили и ICC).
Все эти вещи - интуитивно понятны, но их систематизация оказалась полезной и выродилась в отдельный текст:
Мониторный Softproof и Gamut Warning в Adobe Photoshop
...мониторный софтпруф может быть полезен тем, кто публикуется на фото-сайтах и подобным электронным образом, особенно для тех, кто обзавелся монитором с расширенным охватом и/или использует в качестве рабочего пространства - RGB пространство с охватом, много большим чем мониторный (например, Adobe RGB на обычном мониторе).
Помимо этого, вполне возможна ситуация, когда монитор не способен отобразить все цвета изображения - и это надо вовремя детектировать.
Два дня всерьез пользую CS4, впечатления смешанные:
64-битный - сцуко, быстрый. Если быть точным, то сохранение (layered tiff, PSD, PNG) не кажется быстрее прошлых версий, а вот работа с большим количеством здоровых открытых файлов - не тормозит.
Естественно, ни один из старых 3rd-party плагинов под 64-бита не работает. В результате двустадийный Workflow (RPP - Lab - Photoshop - RGB) стал трехстадийным (RPP - Lab -PSx64(основная обработка) - Lab - PSx32(плагины)). На каждом шаге количество обрабатываемого падает в разы, поэтому жить можно.
32-битный по ощущениям медленее.
Но есть некоторое количество довольно мерзких багов.
Калибровка NEC 3090 заняла существенно больше времени, чем я рассчитывал. Одновременно, читатели задавали всякие вопросы, а у меня на них теперь есть ответы.
Ниже мы рассмотрим такие темы
работает ли SpectraView Profiler с NEC 3090;
работает ли SpectraView II и что из этого получается;
работает ли SpectraView Profiler и как;
разумная (на мой взгляд) процедура калибровки в многомониторном случае
Несмотря на то, что о калибровке мониторов уже написаны мегабайты текстов, сделаны гигабайты текстовых картинок и все такое прочее, некоторые современные веяния описаны очень скромно. А эти веяния довольно существенно влияют на качество мониторной картинки.
Потратив изрядное время на их рассмотрение, решил задокументировать. Первый текст из двух запланированных:
Мониторы с большим цветовым охватом (вроде того, за которым я сейчас пишу этот текст создают понятную проблему:
Если расширенный охват используется (у монитора не включили насильно режим sRGB или что-то такое), а программа показа картинок цветовых преобразований делать не умеет, то вы увидите на экране фигню.
Ну совсем грубо, RGB (255,0,0) - это на двух мониторах ("обычном" и "расширенном") будет красный цвет, соответствующий красному углу охвата. Только красный этот будет сильно разным, см. например картинки с охватом
На скриншоте ниже четыре (на самом деле 2) варианта показа на мониторе одной и той же картинки:
Поигрался с покупкой, привык к ней, покалибровался до мозолей. На картинке полученные цветовые охваты по уровню L=50 (в координатах a-b):
Цвета линий:
черная: NEC 3090WQXi
зеленая: NEC 2180UX
синяя: Adobe RGB
желтая: sRGB
белая: охват принтера Epson 3800 на бумаге Epson Premium Glossy
Из приятного: охват монитора здорово увеличен в зелено-синюю область, где довольно много естественных цветов. Раньше можно было напечатать, но нельзя визуально отредактировать, сейчас стало несколько легче.
(под катом краткое описание наступленных при калибровке граблей и картинки охвата на других уровнях яркости)
При редактировании изображений фотографы пользуются 3-4 компонентными моделями цвета , которые растут либо из особенностей устройства воспроизведения (RGB, CMYK), либо из классических цветовых моделей (LAB). (Затрудняюсь сказать, откуда растут HSB/HSL, классически вероятно из Манселловских атласов, но современные варианты - скорее всего пересчет из LAB по известным формулам.).
Вместе с тем, мы регулярно используем эмпирические приемы (в частности поднимаем цветовой и тоновый контраст на пейзажах, подбираем тон рамки под контраст), а современные цветовые модели содержат численное описание используемых фотографами эффектов.
По случаю дождя и нежелательности выхода на улицу, у меня родился следующий текст:
Смысл в том, что исходные данные с цифровой камеры содержат достаточно много абсолютных данных (как минимум, об освещенности) и их можно использовать, например, для автоматической коррекции контраста.
В комнате светло. И ночью тоже светло, если лампочку включить
Свет - почти точно 5000K, CRI=92 (это i1Share посчитала). Конечно, это не color proof качество, но жизнь все равно стала прекрасна.
Люстра не болтается под потолком, стало просторнее.
Цена вопроса - меньше ста баксов, по 270 рублей за лампы (их две) и 1700 за светильник с высокочастотным (электронным) дросселем. Несмотря на то, что лампы формально 5400K, прибор намеряет 4970, может быть потолок поглощает синий, а может это лампы такие.
Вот спектр ламп:
И единственный вопрос, который меня мучает, это почему я все это не сделал года три назад...
Update: По просьбам трудящихся
Лампы OSRAM DE LUXE L36 W/954 (даю ссылку на lampa28 т.к. на сайте Osram можно только каталог в rar-ах скачать, а если вы у лампы-28 что-то купите, им будет приятно).
Светильник из Рязани LTX 236 с электронным ПРА неизвестной мне иностранной фирмы.
Многие, наверное, уже видели. Для остальных не могу не проанонсировать
Online Paper Spectrum Comparator - визуализированные спектры 32 разных фотобумаг для струйных принтеров, включая 12 эпсоновских.
Возникло острое желание поработать с какой-то бумагой без оптического отбеливателя (т.е. без пика в районе 430 нм), просто чтобы понять, что это такое. Среди эпсоновских (читай - легко доступных в Москве) такая нашлась только одна, UltraSmooth Fine Art.
В ответ на мою жалобу на плохое разделение теней на матовой бумаги, мне посоветовали подкрутить драйвер, чтобы лил меньше чернил. Я послушался, результат мне кажется неудачным, но его стоит описать, дабы другие не ходили по тем же граблям.
После апгрейда драйверов Epson 3800 с версии 5.50 на 6.50 естественно потребовалось все перепрофилировать.
Предыдущие мои профили меня почти полностью удовлетворяли, за исключением поведения в глубоких тенях (L < 10 и темнее), особенно не нравились тени на матовых бумагах.
Естественно, с новыми драйверами пришли и новые профили от производителя, но практика показывает, что самодельные лучше. Кроме того, я все еще использую старые запасы бумаги ColorLife, профилей для которой у эпсона нет.
Новые драйвера стали лить еще больше чернил: мишени линеаризации здорово потемнели. Возникла идея поиграться с настройками драйвера: может если лить поменьше чернил, то и тени станут лучше.
Соответственно, я сделал два комплекта мишеней:
С рекомендуемыми всеми настройками: No Color Adjustment;
C включенной настройкой Color Controls (профиль: Adobe RGB, gamma 1.8)
В предыдущих сериях мы рассматривали ошибки обработки цвета, возникающие при использовании матричных профилей, т.е. таких, где преобразование в PCS (profile connection space) и обратно задается простой матрицей 3x3. В реальной жизни матричные профили используются как рабочие пространства, а на стадиях импорта изображений и печати используются табличные профили, описывающие нелинейности реальных устройств.
Методология тестирования подробно описана в первой и второй статьях серии.
Upd: включены данные по Argyll для линейной гаммы.
В первой части CMM-эпопеи с дистанции была снята CMS Argyll: в области с высокими насыщенностями наблюдались видимые взглядом артефакты. В то же время, на 16-битных файлах Argyll показала великолепные результаты, сравнимые, а на части данных и сильно лучшие, чем у лучших коммерческих CMM.
Как и я и обещал, я заслал автору баг-репорт. К моему приятному изумлению, ответ был получен через час и содержал патч к cctiff (тестовому приложению, которое я использовал в тестах). В самой CMM-engine ничего править не пришлось, там все было правильно.
Из опыта известно, что цифровой шум в тенях чаще всего возникает при обработке данных с линейной «гаммой», а это те изображения, которые мы получаем с линейных сенсоров: цифровых камер и сканеров. Давайте посмотрим, что будет с ошибками на тестовых примерах.