LibRaw: все, что вы хотели прочитать из raw, но боялись

Спешу обрадовать народы мира: проект, над которым последние два месяца мы работали совместно с Ильей Боргом наконец выпущен на публику.

LibRaw - библиотека для чтения raw-файлов:

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

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

  • желающие имплементировать свои идеи по обработке raw-изображений вынуждены эти raw-данные как-то читать;
  • в подавляющем большинстве случаев это сводится к самостоятельному хаку dcraw;
  • но dcraw - не библиотека, поэтому авторы либо используют командную строку dcraw (что приводит к искажению данных так как даже в document mode там есть неотключаемые стадии обработки), либо делают библиотеку самостоятельно.
  • Помимо этого, dcraw может портить исходные данные прямо в процессе распаковки за счет неверного вычитания точки черного.

Наша задача, как мы ее видим, это:

  1. дать консистентный API разработчикам, таким образом поэкономить их человеко-часы и ресурсы CPU;
  2. избавить их от проблем dcraw, таким образом улучшив результаты работы их программ;
  3. дать повод задуматься о правильной обработке RAW (вычитании черного, нормализации на насыщение, линеаризации - это не такая простая штука...).

Freeware, Open-source, GPL v3 (возможно бесплатное лицензирование на других условиях, но с каждым разработчиком это обсуждается отдельно).

Ссылки:

Comments

а референс реализация команд-лайн утилитки будет (есть)?

кстати, по результатам разборок -- расположение тетрад GRGB (или еще какие есть) физическое, на матрице у всех одинаковое?

Ну там в примерах - есть несколько штук
http://www.libraw.su/docs/Samples-LibRaw-rus.html

Расположение пикселей - разное (и сильно разное), в этом месте интерфейс такой же, как у коффина - блок 2x8 описывается 32-битным числом, каждые 2 бита которого дают цвет пикселя.
http://www.libraw.su/docs/API-datastruct-rus.html#libraw_iparams_t поле filters

Круто, не писатель, но оценить навреное могу.

Вот вопрос такой: реально ли из 2-3 12-14битных равов собрать один 16битный именно рав? для того чтобы с ним можно было раобтать стандартными средствами...

16-битных равов в формате CR2 пока не бывает.
Но вот близко к тому, что ты хочешь:
http://www.guillermoluijk.com/software/zeronoise/index.htm

В этом месте, на самом деле, много всяких гитик.

я не про Cr2 а про dng...

програмульку посмотрю чуть позже

Как будто dng - это подарок.
DNG бывают двух видов - либо с сырыми данными, либо уже результаты демозаики. Демозаизированный - это совершенно непонятный мне формат (ибо демозаику нужно делать _после_ баланса белого), по сути - это просто 16-битный tiff, ты его можешь и dcraw получить, будет ничем не хуже.

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

Не, писать CR2, но не усредняя, а заменяя группы пикселов - это правильная идея, но по-моему не реализованая еще.

>>А который с сырыми данными

мы можем эти сырые данные изменить и записать обратно?

В теории - можем. В практике - готового кода в доступности не видно.

Еще в практике - мы наверное не можем записать их обратно 16-битными.

А может всё-таки не надо переписывать .cr2? Фиговая это затея, честное слово.

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

Я что-то слышал про такие проекты, но сейчас ничего определенного не смог впомнить.

У меня старые тёмнокомнатные привычки не трогать негативы :)

Ну так речь (у Стаса) о том, что мы берем 2-3 CR2 и склеиваем из них третий.

Исходники трогать никто не заставляет

http://www.pixelfixer.org/ - один из таких проектов.

JFYI: Оно у вас под линуксом не собирается. Если нужны подробности -- пиши в почту, т.к. каменты здесь я не отслеживаю.

Спасибо за сигнал - уже собирается.

Разработчикам:
1. Молодцы! :)
2. Есть ли планы по контакту с командой UFRaw?
3. Будет ли API поддерживать обработку задаваемого прямоугольника для 100% предосмотра?

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

API для _обработки_ развиваться в рамках данного проекта не будет. LibRaw - библиотека для чтения, обработка там унаследована от dcraw и менять ее в этом проекте мы не планируем, оно остается только для целей демонстрации.
Распаковка участка (прямоугольника) - на мой взгляд не нужна т.к. собственно распаковка очень быстрый процесс, а постобработка (участка или целиком) - задача вызвавшей программы.

Естественно, LibRaw - это подход к полному raw-конвертору, но на ближайшие месяцы таких планов нет, есть другие.

Ну, они как минимум должны о Вас узнать :).

Речь идет не о API обработки, а о де-Байере окна данных. Нормально это можно сделать, изменив dcraw - введя функцию. Вроде бы шумодав работает до обратного Байера, поэтому если он включен, процедура извлечения всей картинки не такая уж и быстрая. И картинки разные бывают, и машины. Предосмотр предполагает интерактивность. Осенью появится Сони с 24 Мп - там по определению дебайер (EAHD) быстрым не будет.

Теперь уже знают :)

Дебайер - не задача LibRaw. Да, мы берем код dcraw, чтобы можно было хоть какие-то демки слепить.

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

Целый RAW-конвертор в рамках библиотеки сделать не получится.

лелею надежду, что вы найдете кучу косяков в Adobe Lightroom и с кем нибудь на пару напишите оупенсорс аналог :)

Не все сразу. И end-юзерские вещи - вряд-ли opensource