обработка raw

О светах у Nikon D3

А вот возьмем полностью засвеченный кадр с Nikon D3 и загрузим его в RawDigger.

Пойдем в Preferences (Ctrl-P), выключим Subtract Black, жмякнем OK и посмотрим на статистику по всему изображению:

Минимальный минимум по всем 4-м каналам - 15587. Откроем еще раз Preferences, включим обратно Subtract Black, Black Level: Manual, значение 15587:
(замечание: пользователи версии более старой, чем 0.9.9 не смогут так сделать, в старых версиях максимальное значение Black Level был 9999).

Что мы сделали? Мы (небольшой) диапазон колебания значений в засвеченном кадре растянули на весь диапазон яркостей.

Нам откроется прекрасное (трафик!):

О линейности RAW и ETTR

Рядовой Иванов, о чем вы думаете, глядя на эту кучу кирпича?

На картинке - кривая, которая применяется к RAW-данным камеры Sony NEX-C3 при их распаковке. NEX-C3 просто первая попалась под руку, в компрессированных RAW A77 или A900 совершенно такая же по смыслу кривая, немножно отличается в деталях.

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

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

Собственно, ничего плохого в такой компрессии светов нет. От того, что в верхнем стопе будет не 2048 градаций (предполагая 12-битный АЦП), а "всего" около 600 - становится только хорошо, потому что поэкономленные 1400 градаций переезжают на второй и третий стопы сверху (полутона и следующий стоп за ними).

LibRaw 0.14.0 (Release)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Полстраницы о высоких ISO у ЦФК

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

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

Сенсор цифровой камеры - он цифровой, считает электроны
Прибывающие фотоны превращаются в заряд с какой-то квантовой эффективностью, вот прямо в штуки электронов. Квантовая эффективность современных сенсоров - порядка 0.5, два фотона в один электрон (зависит от длины волны, для самых синих все много хуже), это уже после байеровских светофильтров.
Емкость одного пикселя (сенселя) - конечна
Один пиксель может накопить не очень много электронов, десятки тысяч. Емкость пикселя определяется его площадью в первую очередь. У Роджера Кларка есть красивая табличка с парой десятков камер Canon/Nikon, у него же описана методика самостоятельного определения характеристик камеры.
После считывания с сенсора, сигнал может быть усилен
Усиление используется, чтобы привести слабый сигнал к удобному для АЦП диапазону.
Заметим в скобках, что цифровые камеры получаются "дважды цифровыми": сначала дискретные отсчеты на сенсоре, потом оцифровка их на АЦП
Динамический диапазон определяется отношением сигнала к шуму
Шумы при этом - это и шум квантования на сенсоре (т.к. число электронов всегда целое) и шум усилителя и тепловые шумы (электроны, возникшие сами по себе, без упавших фотонов) и шум квантования на АЦП.
Теперь перейдем к простому примеру.

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

Ши-дэвыр 2

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

Исходник (кликабельно):

Результат наложения профиля Velvia 50 (тоже кликабельно):

Я не собираюсь утверждать, что это что-то феноменальное, кривая по L, потом Lab Color Boost от Маргулиса сделают что-то довольно похожее. Но вышепоказанное преобразование накладывается одной кнопкой и выглядит вполне "в меру". Ну и тени посинели, чистая вельвия :).

Это конверсия RAW со стандартными параметрами плюс профиль, больше вообще ничего.

Кнопка Шыдевыр

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

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

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

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

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

Тайна розовых облаков

Если вы пользователь RAW-конверторов Adobe последних версий, то с проблемой, показанной на картинке слева, вы скорее всего никогда не сталкивались (или сталкивались, но не в таком масштабе). Большинство остальных конверторов, особенно основанных на dcraw (и LibRaw) имели ее в полный рост на многих камерах, в том числ на кэноновских (и для них - особенно заметно на дробных ISO, для последних моделей камер самые неудачные в этом смысле чувствительности находятся в ряду 160-320-640-1280).

Причина проста, тривиальна, но заслуживает рассказа о ней.

Вот берем, к примеру, Canon 50D.

14-битная камера, значит максимальное значение (насыщение) мы вправе ожидать равным 16383. Ну, после вычитания уровня черного - на ~1000 поменьше.

В реальности же это значение порядка 15750 (до вычитания черного) для ISO 200-250-400-500, 13400 - для ISO 100 и 125, 12800 для ISO 160-320-итд. И только для 6400 и 12800 имеем честные 16383, соответствующие общей теории всего.

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

LibRaw Lite

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

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

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

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

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

LibRaw 0.7 Release

Вышла 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, позволяющие посмотреть на непроцессированные данные.

Шумел камыш

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

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

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

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

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

Кратко о чувствительности цифровых камер

Я несколько опережаю события и фактически презентую незаконченное микро-исследование, но мне кажется полезным немножко обсудить методику с сообществом, прежде чем доделывать работу до конца.

Текущие стандарты (ISO 12232) на чувствительность цифровых камер довольно креативны: специфицируется значение, которое должен иметь средний тон (18%-й серый) в sRGB-файле, а про RAW ничего не говорится. Неявно предполагается, что RAW обрабатывается каким-то проявителем конвертором и, соответственно, чувствительность оценивается у всего комплекса камера-конвертор. Собственно, оно так и было в пленочном мире, пока не проявишь - ничего не понятно.

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

LibRaw 0.7.0 Alpha5

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

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

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

Вопрос про firmware ф/а Canon

Граждане читающие,

А может кто знает:

  • Позволяют ли DSLR Canon даунгрейд прошивки (скажем, стоит 1.06, могу ли я обновиться до 1.05)? Камера - 5D Mark II, но я думаю что это для всех свежих одинаково.
  • (при положительном ответе на первый вопрос) - где взять образ прошивки 1.06 для вышеупомянутой камеры? Может быть ее можно как-то из камеры списать? На официальном сайте лежит, естественно, только последняя, 1.07

Очень хочу поизучать черные точки и что с ними сделали в прошивке 1.07, но хочется иметь возможность откатиться назад, если "что с ними сделали" мне не понравится.... (на руках камера с прошивкой 1.06)

Записки разработчика RAW-обработчика

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

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

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

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

Fuji SuperCCD: сложно о сложном

Расположение пикселов разной чувствительности и цвета на сенсоре SuperCCD, помимо того, что маркетинг Fuji изрядно запудрил всем уши, само по себе нетривиально. Я не уверен, что у меня получится легко про него рассказать (хотя это уже третий пост на данную тему), но буду пробовать.

Во-первых, диагональность. Диагонали на это сенсоре есть в том смысле, что классическое байеровское чередование G-R-G-R в одной строке и B-G-B-G в другой имеется именно по диагоналям. Если ходить по строкам и столбцам, то чередование более сложное (и не спрашивайте какое, тут стаканом не обойтись).

RAW еще сырее: LibRaw 0.7.0-A4

Отрываю ненужные куски от 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 падает на каком-то файле, то я хочу этот файл пощупать.

LibRaw 0.7.0 Alpha-3: еще более RAW

Я точно знаю, что есть люди, читающие анонсы LibRaw именно здесь, остальным придется потерпеть.

В третьей альфе LibRaw 0.7.0 случились две группы существенных идеологических изменений и одна группа несущественных:

  1. Данные для камер FujiFilm распаковываются без поворота на 45 градусов. Это открывает путь к легкому получению 12-мегапиксельных картинок с Fuji S5Pro и прочим подобным радостям. При этом, горизонтальное разрешение должно быть заметно лучше, чем у 6-мегапиксельных, выдаваемых dcraw и всеми использующими этот код.
    Посмотреть на реальные RAW-данные Fuji можно с помощью примера unprocessed_raw, очень поучительно (чтобы извлечь второй кадр, используйте ключ -s 1).
  2. Не менее сильно поработали над PhaseOne:
    • Придуман и для PhaseOne реализован режим (не)фильтрации данных, отключающий тоновую кривую для RAW (более raw-данных вы еще не видели!). Идея мне настолько понравилась, что в следующих версиях тоновую кривую можно будет отключить для всех случаев, когда она есть (Nikon NEF, Adobe DNG, далее везде).
    • Рассчитанные камерой уровни черного доступны в метаданных
    • Исправлена ошибка расчета уровня черного, имеющаяся в dcraw (впрочем, на результат она влияет не очень сильно).
  3. Ну и по мелочи: баги, ключ -s у unprocessed_raw, импортирована свежа версия dcraw.

Более подробно и более формально в changelog, скачивать с той же страницы

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

Pages

Subscribe to обработка raw