Фото

О стандартных форматах

Программировал тут вывод в формат CGATS (это в котором всякие цветовые замеры выводятся, пример ниже), по которому я тут уже немного проехался.

Заодно посмотрел много (десятки) примеров таких файликов, чтобы слова списать. Ну и исходники Argyll на предмет "как это читают".

Если кто-то имеет иллюзию, что это такой вот стандартный формат, который все понимают одинаково и все такое прочее, того жизнь еще не била. Даже форматы данных Пенсионного Фонда РФ - луч света в темном царстве в сравнении с CGATS.

Вот, например, загадка:

  • Допустим, у меня в файле есть и LAB и RGB значения.
  • Допустим, там же есть и стандартные отклонения замеров. Начинаем называть колонки: STDEV_L, STDEV_A, STDEV_B, STDEV_R, STDEV_G, STDEV_что?
  • С XYZ/CMYK, кстати, аналогично.

О постоянстве физических констант

На картинке два Цейсса 28-мм. Год выпуска разный, слева новый (как я нашел в интернетах, объявлен в 2007-м), справа - старый (год точно свежее 1985-го, потому что MM-mount, а точнее я не стал искать). Светосила тоже разная, но для наших целей это несущественно.

Как мы видим, за 20 лет у Цейсса довольно сильно изменилось представление о глубине резкости. Старый объектив на f/16 и фокусировке на бесконечность давал резкое изображение "от 1 метра", а новый - примерно "от 1.7".

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

Интереснее другое, банальная проверка на DOF-калькуляторе показывает:

О Qt и рисовании прямоугольничков

Мой опыт с Qt достаточно своеобразен: как только я начинал лобзиком выпиливать что-то свое руками, внезапно обнаруживалось, что все украдено до нас и есть уже готовое или почти готовое решение. Из последних открытий в этом месте: QGraphicsItemGroup, подошедший мне на 98% после того, как я изготовил свое частное решение (которое, конечно, выкинул после этого).

Но вот столкнулся с задачкой, которая, вроде бы, не решена:

Дано: картинка (разноцветная), на которой рисуются прямоугольнички (selections). Чтобы они были видны на любом фоне, нужно делать XOR в каком-то виде. Или что-то подобное.

В-принципе, QPainter это все умеет, у него есть CompositionMode, где все подобные преобразования можно задать. Но:

Много неясного в странной стране

Сижу, пишу секретный варез, отлаживаюсь на попавшихся под руку кадрах с Nikon D700.

И вот у этого D700 в области довольно сильного пересвета:

  • В синем канале - насыщение, нулевая дисперсия.
  • В красном канале - можно найти места с нулевой дисперсией, хотя и трудно. И в этих местах значения красного - выше чем у синего.
  • А в зеленых каналах (которые засвечены, по идее, сильнее, ибо это выбив на облаке, дневной свет) - сигма около 50, а сами значения зеленого примерно на 200 единиц пониже чем синий канал. При этом, каналы я рассматриваю отдельно, т.е. речь не о бэндинге между зелеными каналами.

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

О чем мы думаем, когда глядим на эту кучу кирпича видим такую хрень?

Ну, особого конструктива у меня нет (и камеры такой нет, чтобы поглумиться), но вот соображение о том, что RAW - это необработанный сигнал с сенсора я, видя такую вот хрень, отметаю с порога.

Да, кстати, разные поканальные максимумы могут дать интересные оттенки в пересветах. Разница, конечно, крохотная, но она есть.

LibRaw 0.13

По традиции, анонсируем LibRaw 0.13-Release.

В сравнении с бетой-1 (анонсированной ранее), случились некоторые изменения к лучшему:

  • Обновились распаковщики данных (на dcraw 9.06), отчего добавилась поддержка шести новых камер, включая Панасоники GH2 и GF2 и Sony A-580. Еще для девяти камер обновились цветовые данные.
  • Экспокоррекция со сжатием светов теперь работает просто по такой тоновой кривой, линейной внизу и корнекубичной вверху. Без всяких заумных контекстных расчетов яркости (изначально заимствованных из RawTherapee), которые подглюкивают на изображениях, сильно окрашенных в синие тона (и красные тоже, но в меньшей степени).
  • Ну и много всяких правок по мелочи.
Прошу любить и жаловаться.

Beware: Kipon tilt adapter

Если вы обдумываете покупку Kipon-овского Tilt-адаптера на micro-4/3 или Sony NEX, мой вам совет - не делайте этого. По двум причинам:

  • Если вы работаете "по таблицам", то вам нужна шкала, на сколько градусов наклонили. А ее нет.
  • А если вы хотите креативного эффекта, то берите лучше Lensbaby Tilt Transformer, там тоже нет шкалы, но зато предельный угол поворота сильно больше.

Увы, но мне этого никто не посоветовал. Учитесь на моей ошибке.

Об адаптации глаза. И о профилировании тоже....

Возьмем красивые разноцветные объекты при дневном освещении:

Особое внимание обратите на две крайние палатки, оранжевую слева и "хаки" справа. По центру - баня, к сожалению на втором кадре ее не будет, она была бы показательной тоже...

А теперь возьмем их же, но при другом освещении:

Фотошопные кривые для фотографа

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

Давайте теперь разбираться с кривыми, которые контраст меняют.

Начнем, как водится, с определения:

Фотографическим контрастом кривой назовем угол наклона передаточной кривой в логарифмических (фотографических) координатах. Такими координатами могут быть:

  • Кривая "логарифм количества света" - "оптическая плотность". Это наиболее привычный вид для фотографа, в таком виде публикуются характеристические кривые пленки/бумаги. На всякий случай напомню, что фотографические стопы - это и есть логарифмическая шкала, каждый стоп соответствует изменению "количества света" вдвое.
  • Вместо оптической плотности можно рисовать логарифм яркости (или коэффициента отражения). Графики будут направлены в другую сторону, но это и вся разница.
  • Для передаточных кривых, вместо "количества света" можно рисовать входное значение.

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

Перейдем теперь к простейшим случаям.

Кривые: ответ на вопрос 1

Вопрос 1 (ЖЖ-ссылка) посмотрело уже достаточно народу, а в комментариях уже практически описан ответ. Пришло время сформулировать его окончательно: Обе кривые не меняют контраст, хотя пользователю фотошопа это может быть удивительно.

Давайте двигаться постепенно и начнем с определений.

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

Фотографы и кривые: вопрос 1

Как-то тема кривых редактирования контраста не нашла того отклика, на который я надеялся. Давайте попробуем более мелкими шагами.

Вот есть две фотошоповские "кривые", первая и вторая:

В каких это (фотошоповских) координатах - несущественно, поверьте. Либо кривая по L в Lab, либо композитная кривая в каком-то RGB. Давайте для простоты считать, что это - в Adobe RGB, у этого пространства, в отличие от Lab и sRGB, нет нижнего линейного участка.

Теперь возьмем две пленки, позитивную и негативную:

Кривой контраст

Вот представим себе, значит, такую кривую, как на картинке. Вот в Lab - это просто умножение на константу. В RGB - тоже умножение на константу (если начало координат немножко подвигать).

Более того, если мы посмотрим, что происходит с интенсивностями (а не со значениями в файле) - то это опять умножение на (другую) константу: и Lab и RGB - это в первом приближении степенной закон (линейным участком в начале Lab/sRGB проще пренебречь).

Другими словами, такая вот линейная кривая в фотошопе - является линейной во всех возможных смыслах.

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

Если же мы развернем логарифмы опять к линейному, то прямые линии в "фотографических" логарифмических координатах - перестанут быть таковыми в любом пространстве редактирования, хоть в Lab, хоть в RGB, хоть в линейном.

Вот я и думаю, кто кидает фотографов, Adobe вместе с ICC и всеми прочими, или же Kodak, который характеристики фотоматериалов за сто лет выстрадал?

LibRaw 0.13-Beta1

Отметим завершение каникул анонсом LibRaw 0.13-Beta1.

Сегодня на экране:

  • Ускорение распаковки хаффмана за счет более правильной буферизации (а для файлов .CR2 - еще и за счет правильного пред-расчета смещений). В результате LibRaw::unpack() работает раза в полтора быстрее для .CR2 и на 20-30% быстрее для других подобных форматов (NEF, packed DNG).
  • Масса новых плюшек в demosaic packs (похоже, пора их переименовывать в feature packs):
    • Шумопонижение разных видов (подавление banding, подавление импульсного шума, выравнивание зеленых каналов).
    • Новый, более правильный, алгоритм автоподавления хроматических аберраций.
    • Правильная экспокоррекция с возможностью сохранять детали в светах (аналог compressed exposure в RPP).
    • Ускорение медианных фильтров при помощи OpenMP
  • Ну и, естественно, все фиксы из ветки 0.12
Все это благолепие - скоро в digiKam (собственно, кроме экспокоррекции - оно уже там).

Кому война....

Кому черезвычайная ситуация, а кому - выставка ледяной скульптуры.

P.S. Света еще немножко есть....

Rawspeed: записки на манжетах

Есть такая библиотека RawSpeed, которая натурально написана с душой и склонностью к правильным оптимизациям. Например, файлы .CR2 распаковываются раз в пять быстрее чем это делает LibRaw.

В стремлении эту несуразность поправить, фтыкаю в ее исходники одним глазом, вторым и третьим - в результаты прогона профайлера на LibRaw и RawSpeed на одном и том же файле.

И вижу интересное (в исходниках, не в профайле): Canon 1D Mark III обрабатывается у Коффина в dcraw (и у нас) специфическим способом. Там, как обычно, грубый хак, но работающий. Касается этот хак буквально двух пикселов по ширине на рамке, видимой части изображения - не касается. Ага, сказали мужики и достали лом побольше пошаговый отладчик и grep.

Зная, что меня читают некоторые пользователи RawSpeed, имею сказать, исключительно в информационных целях:

  • RawSpeed извлекает уровень черного только из DNG и NEF, в остальных случаях берется predefined-значение из базы данных по камерам.
  • Уровень черного - это одно число. Даже не два, как в LibRaw/dcraw и не сложная структура, как оно бывает в некоторых камерах вроде PhaseOne (да и DNG - тоже. DNG-шные теги усредняются).
В результате будет два интересных эффекта:

О цвете

Вынесу, пожалуй, из каментов, это существенное соображение.

Нам пишут, дескать при использовании dcraw -o 0 в тесте алгоритмов интерполяции, получающаяся "интерференция" не столь ужасна, как была с цветом по-умолчанию (sRGB output).

Отвечаем: ну да, в тестовом DNG такая цветовая матрица (это от лени случайно совпало специально сделано), что при попытке привести ее к sRGB, значения в матрице поворота будут большие (по модулю). В результате, наступает клиппинг, который видимость "интерференционных эффектов" усиливает. Если к тем же DNG-данным приписать sRGB ColorMatrix1 (или выключить color processing, что приведет к тем же результатам), то такого усиления видимости - да, не будет.

Да, в ICC-терминах движок LibRaw/dcraw работает в Absolute Colormetric: точка белого никак не правится, все выходящее за gamut - обрезается.

Вместе с тем, воспроизводимость получаемых в LibRaw/dcraw эффектов в коммерческих приложениях (ACR, HDR Studio) наводит нас на мысль, что тамошний цветовой движок в точности такой же - Absolute Colormetric и с обрезкой gamut. Соответственно, это надо учитывать и тестировать в реальной работе (смотреть что ушло в клиппинг и все такое...).

LibRaw 0.12

Тем временем, зарелизили LibRaw 0.12:

  • Поддержка дополнительных алгоритмов, распространяемых на условиях GPL2/GPL3:
    • demosaic-pack-GPL2: алгоритмы интерполяции AFD, LMMSE, VCD, modified AHD, AHD+VCD; дополнительные методы медианной фильтрации изображения; поддержка сенсоров Foveon.
    • demosaic-pack-GPL3: алгоритм AMaZE и подавление хроматических аберраций для AMaZE.
  • Дополнительный алгоритм интерполяции (DCB) и шумопонижения (FBDD) включены в состав основной LibRaw.
  • Поддержка LCMS 2.x
  • Новый механизм ./configure на базе GNU autotools.
  • Исправлены ошибки:
    • Исправления в green_matching для некоторых layouts (как это по нашему?) байеровских матриц.
    • Исправлена ошибка в вызове add_masked_borders_to_bitmap(), которая проявлялась на камерах с нечетной шириной черной рамки.
  • Новые параметры командной строки примера unprocessed_raw: -B - вычитать уровень черного, -M - добавлять маскированную рамку к изображению.

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

О плавающей точке и точности вычислений...

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

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

Ну, за линейность!

Вот, кстати, интересные картинки на тему (якобы) линейности сенсора камеры

www.maxmax.com/nikon_d700_study.htm. Там еще есть, для D200, D300 и 40D

То есть, для меня вопрос, что именно они меряли (не значения ли в JPEG, судя по максимуму, хоть и написано "raw linearity graphs"), но ступенька в красном в любом разе весьма удивительна.

Update: судя по длинам выдержек, это привет от внутрикамерных шумодавов разных систем.

Вжик, сказала пила.....

Как и обещал ранее, я тут засунул лом в японскую бензопилу сделал мишеньку для выведения алгоритмов интерполяции на чистую воду.

В том смысле, что преобразовал показанную слева картинку в DNG и скормил двенадцати демозаикам в LibRaw. Ну и тройке настоящих конверторов, попавших под горячую руку.

Ну и написал на эту тему статью, как водится, читайте: Байеровский муар.

Комментировать и обсуждать лучше там, но для тех кому лень, я комментарии тут тоже не закрываю.

Lens Shift для micro-4/3

Fotodiox сделал шифт адаптеры для micro-4/3. Под все что шевелится на 135-м формате.

каталог.

Без тильта, хоть раздел в каталоге и называется Tilt-Shift. Но сдвигается на 10 мм в каждую сторону и крутится. Любителям панорам будет в самый раз.

Я у них всегда покупал через eBay, доходило все в лучшем виде, но сейчас в eBay-store у них этих адаптеров отчего-то нет, а на сайте - есть. На eBay есть с виду такие же, но от шведского и китайского продавцов и по $300. За 300 проще панорамную голову купить....

Ждем того же самого с тильтом, хотя на micro-4/3 оно будет странновато смотреться.

Pages

Subscribe to Фото