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

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

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

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

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

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

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

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

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

Вынужден с огорчением признать, что такая вот схема:

GitHub <--> локальный git <--> SVN-репозиторий

У меня это, правда, осложнялось тем, что в SVN-е запомнена долгая и трудная жизнь, а на GitHub я поэкспортил только /trunk/, только одного проекта, да и то не весь, а только начиная с публичных версий.

Некоторые пользователи LibRaw тусуются здесь, поэтому я тут и поспамлю немножко.

LibRaw 0.10 Release

Это формальный выпуск, признание того факта, что версия 0.10 - стабильна, каких-то значимых нареканий на нее за лето не было. Значимых отличий от 0.10-Beta3 нет.

LibRaw 0.11 Beta1

А это, наоборот, дивный новый мир с дополнениями и изменениями:

• Выходное изображение (результат) можно кропать. Кроппинг делается до постпроцессинга, поэтому для маленького выходного размера постпроцессинг будет очень быстрым^*.
• Сильно изменена обработка вычитания уровня черного: теперь для всех камер (за единственным, но никому не интересным исключением, которое я просто протестировать не могу^**) на этапе распаковки RAW-данных вычитание черного не производится. Дальше можно вычитать одним из трех способов: постпроцессинг (dcraw_process()) сделает все сам, если вы делаете демозаику и т.п. сами - вам подойдет новый вызов LibRaw::subtract_black(), ну и полностью самостоятельно все можно делать, данные черной рамки доступны и все такое.
• Ну и всякие изменения по мелочи, скажем аллоцированное dcraw_make_mem_image()(_mem_thumb()) теперь надо освобождать через dcraw_clear_mem(), обсуждению этого парадокса посвящен предыдущий пост.

Получил тут от одного индуса (не морального, а настоящего) 40-килобайтный патч к LibRaw, заменяющий мой руками-с-любовью написанный 4-килобайтный Makefile на всякий libtool, Makefile.am и прочие страшные слова (40 килобайт там по той причине, что еще раз, для надежности, включен текст LGPL).

Прикол в том, что никакого реального value не привнесено. Пищалки, перделки, configure, libtool, сверкает и переливается, но профита никакого (результаты работы тестовой фазы configure никак не используются и что будет, если, к примеру, strings.h не найден - неизвестно). А, нет, можно сделать ./configure --prefix=/tmp, но это и все.

Зато многое потерялось, вроде сборки с OpenMP. Еще добавилось много лишних сущностей, всякие враппер-скрипты от того же libtool, лишняя библиотека, библиотеки стали shared (а этого для текущей LibRaw категорически нельзя делать) и т.п.

Зато ВВП увеличен, автор потратил время на производство этого гуана, а я - на его обнюхивание.

Объясняю вышенаписанное автору патча, а он обижается. Вспоминается история с Apache2, когда туда IBM (? не помню точно) принес три мешка Software Engineering, отчего проект не мог выйти из беты лет пять.....

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

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

На картинке - два результата конверсии Адобом (другие конверторы - дают другие результаты, но интегрально не лучше), две Сигмы (DP2 и SD14) и один 5DmkII. Попробуйте угадать где что.

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

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

Подумываю, что если из LibRaw дропнуть поддержку Foveon, то большой беды не будет, снимающих на *такие* камеры мне не жалко, а проблем оная поддержка создает несообразно много.

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

Для читающих анонсы тут, а не на libraw.su/org

Вышли новые версии LibRaw. Все изменения довольно существенные:

• Поддержан Pentax K2000/K-m
• Поддержана правильная распаковка sRAW от Canon 5D Mark II с последней версией firmware
• При использовании встроенного постпроцессинга можно задать свою gamma-curve (с опциональным линейным участком в начале)

Поправил сегодня серьезную багу в 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 и улучшения ея качества.

Имеется острая нужда в RAW-файлах следующих форматов:

• Sony DSC-F828 Огромное спасибо за помощь!
• Задники Imacon Ixpress - нужны RAW-файлы в родном формате;
• Задники PhaseOne - нужны RAW в нежатом формате;
• Задники Sinar - нужны RAW-файлы, снятые в режиме 4-shot

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

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

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

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