Обработка RAW

Выпустил LibRaw 0.7-BETA1.

Каких-либо изменений собственно библиотеки в сравнении с предыдущей Alpha6 нет, но зато добавлено новое тестовое приложение, которое мне кажется очень полезным в хозяйстве:

4channels - сохраняет RAW-файл в виде четырех отдельных TIFF-файлов, по одному на канал.

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

Надо сказать, что Adobe DNG Converter креативно пользуется этими возможностями. Скажем, для новых камер Canon (смотрел 50D и 5DmkII) считается только базовое значение, тогда как для старых (смотрел 400D) считается уровень черного для каждой строки. И это правильно, товарищи!

Но вот dcraw, а за ней и все приложения, использующие её код, начиная с LightZone и ACDSee, а заканчивая LibRaw, поступают с этими данными тупо и глупо: все что есть в DNG-файле усредняется и это среднее вычитается из всех значений.

Естественно, это все касается только тех форматов данных, где вычитание базового черного не делает сама камера. Из распространенных - это камеры Canon (все), ряд моделей Sony и многие P&S камеры.

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

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

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

Я точно знаю, что есть люди, читающие анонсы 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, скачивать с той же страницы

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

Чтобы не писать очередного update к предыдущей записи напишу я новую.

Все упражнения с поворотом, а затем с масштабированием файлов Fuji S5, которые проводятся в dcraw - они конечно интересны. Но ровно до тех пор, пока в руки не попадется "12-мегапиксельный" JPEG, который делает сама камера. Из его размеров становится очевидным, что камера делает очень просто: растягивает файл вдоль короткой стороны, отчего он из (примерно) 4300x1400 становится 4300x2800. И все, собственно.

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

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

Меж тем, Fuji - не первая компания, использующая сей нехитрый трюк. Как мне напомнили, у Nikon D1X та же фигня: пиксели прямоугольные, разрешение сенсора 4028x1324, правда камера масштабировала эту картинку в примерно 6 мегапикселей, а не в 10.5. При этом, разница горизонтального и вертикального разрешения у D1X (по DPReview) очень даже есть.

Вот пишут мне знакомые в почту, что всем российским покупателям Vuescan автор предлагает халявно проапгрейдиться по случаю появления русского перевода. Даже тем, кто стандартную версию покупал с годом апгрейдов. Я, правда, не сумел вспомнить E-mail на который свою копию регистрировал и подозреваю, что это был профуканый мой мейлбокс на rambler.ru.

Сходил Vuescan-у на сайт, прослезился, вспомнил молодость. Оказывается, впрочем, разовый бесплатный апгрейд предлагают всем покупателям, по случаю 10-летия программы.

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