обработка raw

После трех месяцев разработки и тестирования вышла LibRaw 0.14.

По уже сложившейся традиции, помещу тут несколько отредактированный Changelog.

В этой версии одно принципиальное изменение, влекущее за собой множество мелких:

Разрешены повторные вызовы постобработки (LibRaw::dcraw_process) без переоткрытия файла парой вызовов open()/unpack(). При этом, постобработку можно повторять меняя любые параметры обработки (за исключением выбора кадра через shot_select).

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

• "Почти realtime" показ изменений изображения при смене параметров RAW-конвертации в режиме половинного разрешения. На 40-мегапиксельное изображение уходит примерно 250 мсек (т.к. half-mode, то выдается 10 мегапикселей, что сильно больше любого современного монитора).
• "Совсем realtime" показ изменений небольшого окошка (например, вокруг курсора) в полном разрешениии с настоящей демозаикой (получается 30-50 кадров/сек для окошка 450x300)

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

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

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

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

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

Несколько тезисов

Сенсор цифровой камеры - он цифровой, считает электроны

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

Емкость одного пикселя (сенселя) - конечна

Один пиксель может накопить не очень много электронов, десятки тысяч. Емкость пикселя определяется его площадью в первую очередь. У Роджера Кларка есть красивая табличка с парой десятков камер Canon/Nikon, у него же описана методика самостоятельного определения характеристик камеры.

После считывания с сенсора, сигнал может быть усилен

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

Динамический диапазон определяется отношением сигнала к шуму

Шумы при этом - это и шум квантования на сенсоре (т.к. число электронов всегда целое) и шум усилителя и тепловые шумы (электроны, возникшие сами по себе, без упавших фотонов) и шум квантования на АЦП.

Update: дописал два абзаца про синий канал, высокие ISO и лампы накаливания. Если не хотите огорчаться, лучше не читайте.

Павел Косенко, заполучив непубличную бету Raw Photo Processor с профилями пленки, дразнит своих читателей результатами финальной обработки.

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

Кроме того, я терпеливо дождался появления этой функциональности в публично доступной версии, вчера вышел RPP 4.1.3 в котором профили пленок есть.

На картинке слева - фрагмент изображения (жмякните, чтобы увеличить), к левой половине применен профиль V50 (Velvia 50) и снижен до -6 контраст (для изображения с богатыми тенями профиль Вельвии излишне контрастен), правая половина - рендеринг по-умолчанию. Впечатление, как вы можете видеть, что левую половину просто протерли тряпкой от пыли.

Естественно, подобный эффект легко достижим через, например, HIRALOAM (Unsharp Mask с HIgh-RAdius-LOw-AMount), но важно что профильное преобразование - локальное, с каждым пикселем отдельно, никаких нелокальных побочных эффектов вроде гало - не возникает.

почти копия анонса с сайта

По многочисленным заявкам нелюбителей GPL выпущена LibRaw-Lite

Как следует из названия, это облегченная версия LibRaw, основные отличия которой от полной версии таковы:

• Лицензия LGPL, что позволяет использовать (немодифицированную) библиотеку в не-опенсорсных приложениях.
• (увы) нет поддержки Foveon в силу лицензионных ограничений на этот кусок dcraw (откуда растут ноги у LibRaw). Мы работаем над этим и возможно предложим какую-то замену.
• Нет целого ряда улучшений (сделанных нами относительно функциональности dcraw):
  • черная рамка (маскированные пикселы) не извлекается, эти пикселы приложению не доступны;
  • вычитание точки черного и прочая пред-интерполяционная обработка RAW-данных не отключается;
  • способ, которым получены цветовые данные (матрицы RGB-XYZ и т.п.) не запоминается;
  • нет поддержки OpenMP.

Другими словами, все то хорошее что мы сделали в расчете на разработчиков RAW-конверторов, анализаторов RAW и прочие программы, которым нужен доступ к исходным RAW-данным - в Lite-версии отсутствует.

В комментариях к технике мезурбации в очередной раз всплыла тема оценки уровня шума.

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

Сначала о проблеме:

• Вот, допустим, имеются камеры A и B, примерно одинаковой мегапиксельности и формата кадра.
• Пусть, для удобства дальнейших рассуждений, максимальный уровень снимаемого сигнала (он же - приблизительно - разрядность АЦП) у этих камер одинаков, скажем 16000.
• При формально одинаковой установленной чувствительности и одинаковой сцене - экспонометры на камерах покажут одинаковую экспозицию, совпадающую с показаниями внешнего экспонометра (разницей в методиках матричного замера пренебрежем, допустим мы замеряем серую карту спотметром).
• Дальше мы экспонируем по экспонометру и получаем уровень сигнала в RAW для вышеупомянутой серой карты: для одной камеры - 1100, для другой - 2400 т.е. более чем вдвое (реальный headroom намеряный для современных 20+-мегапиксельных dSLR так и отличается, от 2.7 до 3.8 стопа).
• В предположении, что уровень шума одинаков, получаем вдвое отличающееся отношение сигнал/шум.
• Как следствие, при несколько разных методологиях мы можем получить заметно разные результаты (о чем я уже писал): одни напишут, что более шумная камера А, а другие - что камера B.

Другими словами, очень важное соображение о том, что "формальная" и "реальная" чувствительности - это две большие разницы не может игнорироваться методологией.

Спешу анонсировать LibRaw 0.7.0-Alpha-5

Эта альфа завершает цикл крупных изменений, затеянных в версии 0.7. В последней версии новая схема чтения, реализованная поверх C++-враппера, коий враппер каждый может заточить под свои нужды (одна из высказанных пользователями нужд, например, это извлечение метаданных из начала файла, который качается по PTP).

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

Поправил сегодня серьезную багу в LibRaw, что заставило меня призадуматься о жизни. Если в подробностях, то:

• У некоторых мыльниц (ряд моделей Nikon, Pentax, Samsung, Casio) режим RAW включается через инженерное (скрытое) меню.
• В этих RAW нет никаких метаданных, а только данные с сенсора, обычно просто дамп байтов в каком-то некомпрессированном формате.
• Метаданные сохраняются в JPEG-файле с обычным снимком, который записывается рядом (с тем же именем файла и другим расширением или же с другим номером файла).
• В dcraw, а оттуда и в LibRaw есть поддержка этого составного формата: вычисляется имя файла, открывается, загружается EXIF.

И вот эта вот поддержка - категорически не работала. Даже хуже: наличие JPEG с метаданными приводило к неправильной распаковке собственно RAW, а отсутствие этого файла - к падениям.

Эта ошибка была начиная с LibRaw 0.0 и до сегодняшнего дня. И ни одна зараза - не заметила. Несмотря на то, что LibRaw уже несколько месяцев используется в digiKam и Krita, а у этих программ должны быть десятки тысяч пользователей, если не больше.

Отрываю ненужные куски от LibRaw (попавшие туда из dcraw) и никак не могу остановиться. В очередной версии сделал отключаемым пропускание RAW-данных через тоновую кривую.

Естественно, этот режим работы может быть интересен только тем, кто сам пишет RAW-конверторы или анализаторы RAW или подобные вещи. Ну и любопытствующим, ибо поставляемый в составе библиотеки пример unprocessed_raw (в версиях под Win32/Mac/Linux он лежит скомпилированным и готовым к использованию) способен эту опцию включить и показать ваши данные прямо как они из файла раскодированы.

Тоновая кривая есть не во всех камерах и форматах данных, среди распространенных это Nikon (compresssed NEF) и Sony A700/A900 (8-битный cRAW)

Достаточно очевидно, что от тоновой кривой нет вреда (или практически нет вреда) если выходное пространство шире чем входное, скажем из 8 бит делаем 12 (как оно у Sony). А вот если входное и выходное пространство имеют одинаковую битность, а кривая отлична от линейной, то мы обязательно потеряем градации. Такое должно случаться, насколько я понимаю, с 12-битными NEF-ами, было бы прикольно, если бы кто-то проверил.

Аналогично предыдущему анонсу просьба: если unprocessed_raw -N падает на каком-то файле, то я хочу этот файл пощупать.