RAW

(частичная) Поддержка Fujifilm GFX 50s

Фуджи продолжает традицию выпуска техасских леек и отметилась на этот раз 50-мегапиксельной "среднеформатной" (33x44мм) беззеркалкой.

RAW-файлы второй день есть тут: http://www.photographyblog.com/previews/fujifilm_gfx_50s_photos/

Там бывают uncompressed (~110Mb) и compressed (~45-48Mb).

Uncompressed мы поддерживаем в наисвежайших версиях FRV и RawDigger:

FRV: http://www.fastrawviewer.com/blog/FastRawViewer-1-3-8-release-candidate ну и в этом тексте ссылки обновлены.

RawDigger: http://www.rawdigger.com/news/rawdigger-1-2-18-beta

Поддержки compressed-формата пока нет.

О 16-битных цифрозадниках

Наткнулся в ЖЖ Ильи Борга на такой вопрос к нему:
Я уточнить хотел к предыдущему вопросу. В MF цифровых камерах согласно всяким там заявленным характеристикам вроде часто стоит 16 битный АЦП. Это якобы заметно повышает ДД камеры (настолько что как обсуждалось некоторыми товарищами в той ссылке оставляет все DSLR с ихними 14 битами далеко позади). Это действительно так? Какй нибудь сильный выигрыш в тенях от этого получается?
Так вот, вот вам ответ для PhaseOne (компрессированный формат):
// dcraw.c, строчки в районе 1550-й, немножко упрощая
void CLASS phase_one_load_raw_c()
{
....
    for (col=0; col < raw_width; col++) {
      RAW(row,col) = (pixel[col] << 2) - ph1.black + black[row][col >= ph1.split_col];
    }
...
}
Если простыми словами, то в pixel[] содержится распакованая (из хаффмана) строка, дальше значение пиксела сдвигается на два бита (умножается на 4), потом вычитается уровень черного и все это кладется в 16-битный (unsigned short) буфер.

Какой вывод мы можем сделать? А такой, что АЦП - 14-битный, а в младших битах 16-битных значений до вычитания черного были такие вот кругленькие нолики.

В нежатом формате - не так, но нежатый формат я видел только на очень старых задниках, а все что видел нового - жатое. И на P45 и на P65+ и на IQ180 - везде в данных 14 реальных бит.

Справедливости ради, в материалах на сайте PhaseOne ничего про 16-битный АЦП не написано. Все гораздо более обтекаемо, "16-bit OptiColor"...

P.S. Написанное выше - конкретно про PhaseOne. Невозможность имения в этом формате 16-битных RAW-данных вытекает просто из процедуры распаковки. Для других форматов все не так прозрачно.

О синем цвете и зеленых каналах: Panasonic G3

Я уже про это писал, но во-первых чисто умозрительно (на пальцах), а во-вторых не полностью верно, пришло время вернуться.

Чтобы не троллить больше владельцев Sony A77, возьмем для примера Panasonic G3. А именно, возьмем с imaging resource снимки мишени CoolorChecker и постараемся разобраться, что же камера с них выдает.

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

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

Для начала, сформулируем тезисы, которые ниже я пытаюсь проиллюстрировать.

Суть проблемы (профилирования)

Проблему я формулирую так:

  • Все поля мишени с точки зрения программы профилирования - равнозначны. В лучшем случае профилировщик учтет дисперсию сигнала в данном поле, да и то, скорее интегральную, а не поканальную.
  • С точки же зрения камеры, величина ошибки по полям и по каналам - очень разная. Тут и шум и разная чувствительность каналов и ступенчатость восприятия, особенно на высоких ISO.
Естественно, проблема касается не только профилирования, но и вообще захвата слабых каналов. Посмотрим с этой точки зрения на изучаемый панасоник.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сенсор цифровой камеры - он цифровой, считает электроны
Прибывающие фотоны превращаются в заряд с какой-то квантовой эффективностью, вот прямо в штуки электронов. Квантовая эффективность современных сенсоров - порядка 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), но важно что профильное преобразование - локальное, с каждым пикселем отдельно, никаких нелокальных побочных эффектов вроде гало - не возникает.

Dan Margulis on RAW module

dan_margulis_2008sm.jpg На LibRaw появился новый автор: Dan Margulis. Хочется надеяться, что сотрудничество будет не разовым, но гарантировать я это не могу. Пока же представляем вниманию читателей один текст на двух языках:

Dan Margulis on RAW module
The question that needs an answer is, for what purpose is the module designed. I can think of four different approaches to acquisition.
  1. I want the module to do nothing more than open the file without damage. I understand that it will probably be flat and colorless if I do this. I intend to fix the problems in Photoshop.
  2. Although I will refine the image in Photoshop, I would like to be able to make quick, obvious moves in the acquisition module to make life easier later.
  3. ....
Дан Маргулис: Мысли о назначении и некоторых проблемах конверторов RAW
Вопрос, которым следует задаться в первую очередь, - это место RAW конвертора в цепочке обработки изображения. Иными словами, требуется определить те цели, которые должны быть решены на этапе конвертации RAW-данных. Я могу представить себе 4 различных подхода к определению задач этого модуля.
  1. От модуля требуется лишь преобразование RAW-данных без потери качества. Мы отдаем себе отчет в том, что результат будет плоским (малоконтрастным) с ненасыщеными цветами. Для того чтобы вернуть изображение к жизни мы будем использовать Photoshop.
  2. ...

Ручная работа!

5d2-mask.png

Если рассматривать черную рамку у 5D Mark II, взяв кадры с разных камер, то становится очевидно, что матрицы делаются вручную (китайские крестьяне в своих фанзах?). Вот, собственно, пример: два кадра (сложены слоями в фотошопе со смещением), оба ISO 100, камеры разные. У одного по верхнему краю просто насечки от шестеренки, а у другого - еще и темная полоса.

As RAW as possible

kaf50100.png Говоря о RAW-данных ("необработанные", "данные прямо с матрицы") большинство фотографов (да и не только фотографов) полагают, что сенсор - это очень простая штука: массив светочувствительных элементов, цветные фильтры, сбоку прикручен АЦП (или несколько). Появляется в рекламных буклетах производителей фраза "мы уменьшили зазор между микролинзами" - вспоминают еще и про микролинзы. Документации то разумной почти нет. Про острую нужду в кривых спектральной чувствительности мы уже писали в статье для Компьютерры, но есть острая нужда не только в этих данных.

Вот, например, "черная рамка" или маскированные пикселы. Они считываются с матрицы, но в финальное изображение - не попадают. Значения считанных оттуда пикселов - это источник данных для выставления уровня черного. Если читать исходные тексты dcraw, то видно, что для большого числа камер Dave Coffin (а за ним - и многие последователи) банально вычисляет среднее по некоему участку черной рамки (или же в последних версиях для некоторых камер делает чуть-чуть сложнее, считая отдельное среднее для четных и нечетных столбцов), затем это среднее вычитается из значений, считанных с активных пикселов и все.

Впрочем, некоторые производители завесу немножко приоткрывают. Вот, скажем, Kodak. В Кодаковских datasheets на сенсоры написано много всего интересного. И если почитать, например, документацию на KAF-50100 (картинка справа взята из нее), то становится понятно, что структура неактивных пикселов - сложная, тут и референс для выставления уровня черного и что-то тестовое и какие-то буферные пикселы.

LibRaw 0.6.4

C Новым Годом, товарищи читатели!

Использующим LibRaw мой новогодний подарок: LibRaw 0.6.4.

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

Все ли хорошо в RAW?

Мы с Ильей Боргом написали в Компьютерру статью, в которой постарались описать наше видение современного состояния дел с RAW-форматами. Прошло три недели с выхода журнала и, согласно первоначальной договоренности, перепечатываем у себя:

Позволю себе процитировать вводный раздел целиком.

Два пути в никуда: в поисках утраченного смысла

За последние 10—15 лет цифровая фотография вытеснила фотопленку практически из всех традиционных областей применения. Конечным потребителям проданы сотни миллионов цифровых фотокамер, не считая камер, проданных в мобильных телефонах. Столь массовая индустрия не может существовать без стандартов — и таковые, казалось бы, имеются: стандартизованы устройства для хранения данных (flash-карточки) и формат изображений JPEG — наиболее массовый и удовлетворяющий потребности подавляющего числа пользователей.

Однако формат JPEG далеко не всегда удовлетворяет требованиям профессионалов — фотографов, дизайнеров, персонал prepress-бюро, а тем более фотобанков и фотоархивов. Зачастую не удовлетворяет он и требованиям "продвинутых" фотолюбителей. Именно поэтому многие модели фотокамер, обычно позиционируемые производителем как профессиональные и полупрофессиональные, поддерживают, кроме JPEG, и запись изображения в так называемом "формате RAW". У стороннего наблюдателя может создаться впечатление, что RAW — это тоже такой стандартный формат, обеспечивающий лучшее качество — "качество для профи".

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

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

LibRaw 0.6.2

По случаю позавчерашнего выхода новой dcraw обновилась и библиотека LibRaw:

  • Поддержка новых камер: Canon G10 and 5D Mark II, Leaf AFi 7, Leica D-LUX4, Panasonic FX150 and G1, Fujifilm IS Pro
  • Изменения в цветовых таблицах для камер из предыдущего апдейта: Canon 50D, Nikon D90 and P6000, Panasonic LX3 and FZ28, Sony A900
  • Исправлена ошибка в обработке файлов Panasonic .RW2, которая проявлялась только на thread-safe версии библиотеки.

Успешно протестировано, в том числе практически на полном списке файлов от новых камер (кроме Leaf и FX150).

Скачать можно где всегда. Пользователи KDE тоже уже осчастливлены, но им нужно обновить libkdcraw.

LibRaw 0.6.0 Release

Я понимаю, что уже опротивел за последние три дня, поэтому буду краток.

LibRaw 0.6.0 Release берут отсюда. Полный Changelog там, а краткий вот:
  • Поддержка Nikon D90 и P6000, Canon 50D, Sony A900, Panasonic FZ28 и LX3. При этом D90 и A900 поддержаны нормально, а для остальных нет таблиц RGBG-XYZ, цвета могут быть кривоваты (и будут еще апдейты).
  • Примитивное подавление бэндинга для камер Canon.

LibRaw 0.5.5 и LibRaw 0.6.0 Beta2

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

Скачивать тут, Changelog тоже тут

Мы уже проползли в KDE (в 4.2, это даже не бета :) отчего масса софта уже использует LibRaw (конечно, если вы возьмете свежую libkdcraw и соберете), цитирую:

  • digiKam - photo management software
  • kphotoalbum, an alternative to digiKam but with less features.
  • gwenview, a image viewer, used to show thumbs in icon view.
  • dolphin, a file manager, used to show thumbs in icon view.
  • darkroom, a experimental RAW converter
  • krita, a image editor, used as RAW image loader
Поздравления принимаются

LibRaw 0.6.0 Beta1

По требованиям французских и немецких трудящихся, была добавлена разнообразная функциональность:

  • Обработанное изображение можно получить в виде RGB-битмэпа (ранее только в виде квадрупляев R-G-B-unused)
  • Добавлены вызовы для индикации стадий обработки (рисования прогресс-баров) и досрочного прекращения обработки.
  • Добавлена работа с профилем камеры/выходным профилем через LCMS
  • Вспомогательные вызовы: получение списка поддерживаемых камер, получение информации о версии.
  • поддержка работы с картой плохих пикселей и вычитанием темнового кадра.
  • поддержка OpenMP для AHD-интерполяции и шумопонижения.
  • исправлена одна ошибка в adjust_sizes_info_only

Скачать эту версию можно c сайта LibRaw со страницы downloads в разделе бета-версий.

LibRaw имеет шансы появиться в digiKam, куда оно проникает через libkdegraphics.

LibRaw 0.5.4

Вышла LibRaw 0.5.4. Краткий список изменений:

  • Импортирована последняя версия dcraw (8.87), добавлена поддержка шести новых камер: Canon 1000D, A720, SD300; Nikon D700, Olympus E-520,Kodak C603.
  • Ввод-вывод через mmap() заменен на (старый) ввод-вывод через FILE. Скорость не пострадала, памяти нужно меньше.
  • Лицензирование изменено с GNU GPL v3 (или новее) на GNU GPL v2 (или новее).

Пользуюсь случаем, чтобы напомнить:

LibRaw - это библиотека для чтения RAW-файлов, получаемых с цифровых фотокамер (CRW/CR2,NEF,RAF,DNG и других).
LibRaw основана на исходных текстах утилиты dcraw, часть недостатков которой исправлена, а часть будет исправлена в дальнейшем. Пользователям библиотеки предлагается API для встраивания в свои программы.
Если вы не программист, а фотограф, то вам может быть полезна входящая в поставку утилита half_mt, которая функционально эквивалентна dcraw -h, но на многопроцессорных/многоядерных машинах работает в разы быстрее.

Нужен ли CIECAM02 фотографу ?

CAM_Obl_thumb.jpg При редактировании изображений фотографы пользуются 3-4 компонентными моделями цвета , которые растут либо из особенностей устройства воспроизведения (RGB, CMYK), либо из классических цветовых моделей (LAB). (Затрудняюсь сказать, откуда растут HSB/HSL, классически вероятно из Манселловских атласов, но современные варианты - скорее всего пересчет из LAB по известным формулам.).

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

По случаю дождя и нежелательности выхода на улицу, у меня родился следующий текст:

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

Pages

Subscribe to RAW