blog.lexa.ru

В качестве алаверды к предыдущему посту имею сообщить, что хвалимый многими модуль дисплейной калибровки Argyll CMS мне не понравился:

• Задача-максимум: добиться одинакового визуального воспроизведения нейтральных плашек на двух мониторах не достигнута. Формально dE меньше единицы, но реально глаз видит разницу (которую можно устранить кривой в зеленом, но удобных средств редактирования LUT монитора у меня под рукой не было).
• Задача-минимум, собственно калибровка и профилирование, выполняются относительно неплохо, но калибровка идет средствами LUT видеокарты (т.е. 8-битной таблицы на DVI), точность работы средств, пищущих в LUT монитора - сильно выше (это видно при рассмотрении серого ступенчатого клина). Матричные профили имени Argyll мне при этом вполне нравятся, табличные - не нравятся.
• Использовать сам Argyll (коммандлайновые утилиты) необычайно мучительно, GUI сильно упрощает процесс. dispcalGUI задачу управления вполне решает.

С учетом вышесказанного, остался жить с basICColor.

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

• Калибровка и рабочий профиль у меня совпадают по точке белого (D50) и тоновой кривой (L*).
• Берем ступенчатый серый клин (я использую мишень от Norman Koren) в пространстве sRGB (D65 и степенная гамма-кривая), выводим фотошопом на экран, получаем (видимую) разноцветность по патчам.
• Image->Convert to RGB -> Beta-Lstar (рабочий профиль) - разноцветность патчей пропадает.

Эффект проявляется только для табличных (LUT) профилей и связан, естественно, с ошибками интерполяции содержащихся там таблиц (при построении условного device-link профиля пространство файла-пространство монитора). Для матричных профилей такой пересчет интерполяции не требует и, соответственно, ошибок не создает.

Я уже столько раз ругался на измерения пресловутого ДД, что даже сбился со счета. Существующие в сети измерения меня не устраивают по куче причин:

• Обычно методика описана очень приблизительно (при этом опубликованные результаты - странные).
• Из (приблизительного) описания методики удается понять, что снималась контрастная мишень одним кадром, а такая съемка сама по себе проблемная по многим причинам:
  • в системе объектив-камера-(сенсор) падает контраст;
  • протяженная (на весь кадр) мишень будет иметь падение освещенности по краям кадра.
• Как правило, изучается различимость больших плашек, что не имеет большого смысла с точки зрения фотографической задачи: получения детализации в тенях и светах.

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

Эта тема уже обсуждалась, но на качественном уровне. Однако наделанный в последнее время инструментарий позволяет померять эффекты засветки количественно.

Сначала сформулируем вопросы:

• Есть ли в системе оптика-камера значимое светорассеяние?
• Каково же оно?

В прошлый раз я помещал в кадр светодиодный фонарик, который был стопов на 12 ярче сцены и получал подъем теней аж на стоп (это вполне видимо глазом на снимке). В этот раз захотелось измерить более тонкие эффекты и количественно, поэтому методика изменилась:

• Берем монитор, заливаем его темно-серым (я брал R-G-B=6). Если ничем не заливать, то видна неравномерность подсветки.
• Снимаем, чтобы это темно-серое гарантированно было выше уровня шумов камеры, но в глубокой тени. Я снимал с экспопоправкой (от спотметра) -5 EV, зная что общий динамический диапазон камеры (для больших плашек) никак не меньше 10 стопов, а вверх от спотметра есть запас чуть менее 4EV.
• Выводим в углу монитора белый прямоугольник (см. картинку). На моем мониторе он на 8 стопов ярче "темно-серого", снимаем с той же экспозицией, что и в прошлый раз. Да, при этом контрасте белый прямоугольник еще не насыщен, даже в зеленом канале остается где-то треть стопа в светах. Т.е. можно говорить о довольно контрастной (8 стопов) сцене.
• Усредняем серединки кадров необработанных данных (для извлечения необработанных данных использовалась программа 4channels из LibRaw, анализировался только зеленый канал) и сравниваем средние значения.

Drupal закричал мне, что у меня все устарело, нужно срочно апгредиться. Ну, как он любит. Поапгрейдил, в том числе и Comment Notify до версии 1.2, про натягивание которого на Postgresql я уже писал.

Поапгрейдив, имею вопрос: а что, в MySQL у поля написано NOT NULL, то там самостоятельно появится еще и DEFAULT ...? Потому что я не верю, что автор Comment Notify его совсем не тестирует, однако в нем:

• В таблице заводится крайне полезное поле, позволяющее не слать повторные нотификации если комментарий редактировался. Но оно NOT NULL и без DEFAULT.
• Вставка в эту таблицу делается без инициализации данного поля.

Патчить можно или сам модуль или процедуру инсталляции/апгрейда. Точнее, без правки .install никак не обойтись, поэтому вот минимальный патч, который превращает Comment Notify 1.2 в работающий под Postgresql (про MySQL ничего не знаю, не проверял):

comment-notify-1.2-install.diff.gz

Если вы переезжаете с Comment Subscribe, то нужно выполнить еще две SQL-команды (чтобы уже разосланные нотификации не рассылались повторно):

UPDATE comment_notify set notified=1;
UPDATE comment_notify set notify=1 where cid in (SELECT cid FROM z_com
mentsubscribe WHERE subscribe > 0);

Вышла LibRaw 0.7. В том смысле, что "не бета".

Поскольку эта версия полностью совместима (на уровне исходных текстов) с версиями 0.5 и 0.6, поддержка старых версий прекращается вот прямо сегодня.

Что нового

По отношению к 0.7-BETA5:

RAW-данные с сенсоров Fuji SuperCCD раскладываются по правильным цветовым каналам на этапе распаковки RAW, а не на фазе постпроцесинга, как оно было ранее.

Это важно для тех приложений, которые самостоятельно делают дебайеризацию и вообще постпроцессинг. Кроме того, пример 4channels стал правильно работать с файлами с вышеупомянутых камер.

По отношению к ветке 0.6.x:

• Извлекаются (и доступны в приложении) данные черной рамки
• Приложению доступны "совсем необработанные" RAW-данные: без вычитания точки черного, замазывания нулевых пикселов и наложенной тоновой кривой.
• Новая input framework. На ее основе поддержано чтение из файла и из буфера в памяти, реализовать собственное чтение совсем несложно.
• Для камер Fuji доступны исходные (неповернутые) позиции пикселов.
• Новые тестовые приложения unprocessed_raw и 4channels, позволяющие посмотреть на непроцессированные данные.