Поскольку эта версия полностью совместима (на уровне исходных текстов) с версиями 0.5 и 0.6, поддержка старых версий прекращается вот прямо сегодня.
Что нового
По отношению к 0.7-BETA5:
RAW-данные с сенсоров Fuji SuperCCD раскладываются по правильным цветовым каналам на этапе распаковки RAW, а не на фазе постпроцесинга, как оно было ранее.
Это важно для тех приложений, которые самостоятельно делают дебайеризацию и вообще постпроцессинг. Кроме того, пример 4channels стал правильно работать с файлами с вышеупомянутых камер.
По отношению к ветке 0.6.x:
Извлекаются (и доступны в приложении) данные черной рамки
Приложению доступны "совсем необработанные" RAW-данные: без вычитания точки черного, замазывания нулевых пикселов и наложенной тоновой кривой.
Новая input framework. На ее основе поддержано чтение из файла и из буфера в памяти, реализовать собственное чтение совсем несложно.
Для камер Fuji доступны исходные (неповернутые) позиции пикселов.
Новые тестовые приложения unprocessed_raw и 4channels, позволяющие посмотреть на непроцессированные данные.
Если вы используете LibRaw 0.6.14, то вам полезно было бы обновиться до 0.6.15. В предыдущей версии - обидная ошибка (переполнение) в генерации гамма-кривой.
Кроме того, в 0.6.15 и в 0.7-BETA5 инкорпорирована новая dcraw. Из существенного: улучшена и генерализована поддержка PEF-файлов Pentax.
Эта альфа завершает цикл крупных изменений, затеянных в версии 0.7. В последней версии новая схема чтения, реализованная поверх C++-враппера, коий враппер каждый может заточить под свои нужды (одна из высказанных пользователями нужд, например, это извлечение метаданных из начала файла, который качается по PTP).
Как обычно, я очень заинтересован в фидбеке, особенно от разработчиков использующих LibRaw, но и просто проблемные файлы (если у вас что-то упало или не так раскодировалось) весьма интересны.
Поправил сегодня серьезную багу в LibRaw, что заставило меня призадуматься о жизни. Если в подробностях, то:
У некоторых мыльниц (ряд моделей Nikon, Pentax, Samsung, Casio) режим RAW включается через инженерное (скрытое) меню.
В этих RAW нет никаких метаданных, а только данные с сенсора, обычно просто дамп байтов в каком-то некомпрессированном формате.
Метаданные сохраняются в JPEG-файле с обычным снимком, который записывается рядом (с тем же именем файла и другим расширением или же с другим номером файла).
В dcraw, а оттуда и в LibRaw есть поддержка этого составного формата: вычисляется имя файла, открывается, загружается EXIF.
И вот эта вот поддержка - категорически не работала. Даже хуже: наличие JPEG с метаданными приводило к неправильной распаковке собственно RAW, а отсутствие этого файла - к падениям.
Эта ошибка была начиная с LibRaw 0.0 и до сегодняшнего дня. И ни одна зараза - не заметила. Несмотря на то, что LibRaw уже несколько месяцев используется в digiKam и Krita, а у этих программ должны быть десятки тысяч пользователей, если не больше.
Расположение пикселов разной чувствительности и цвета на сенсоре SuperCCD, помимо того, что маркетинг Fuji изрядно запудрил всем уши, само по себе нетривиально. Я не уверен, что у меня получится легко про него рассказать (хотя это уже третий пост на данную тему), но буду пробовать.
Во-первых, диагональность. Диагонали на это сенсоре есть в том смысле, что классическое байеровское чередование G-R-G-R в одной строке и B-G-B-G в другой имеется именно по диагоналям. Если ходить по строкам и столбцам, то чередование более сложное (и не спрашивайте какое, тут стаканом не обойтись).
Отрываю ненужные куски от 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 случились две группы существенных идеологических изменений и одна группа несущественных:
Данные для камер FujiFilm распаковываются без поворота на 45 градусов. Это открывает путь к легкому получению 12-мегапиксельных картинок с Fuji S5Pro и прочим подобным радостям. При этом, горизонтальное разрешение должно быть заметно лучше, чем у 6-мегапиксельных, выдаваемых dcraw и всеми использующими этот код.
Посмотреть на реальные RAW-данные Fuji можно с помощью примера unprocessed_raw, очень поучительно (чтобы извлечь второй кадр, используйте ключ -s 1).
Не менее сильно поработали над PhaseOne:
Придуман и для PhaseOne реализован режим (не)фильтрации данных, отключающий тоновую кривую для RAW (более raw-данных вы еще не видели!). Идея мне настолько понравилась, что в следующих версиях тоновую кривую можно будет отключить для всех случаев, когда она есть (Nikon NEF, Adobe DNG, далее везде).
Рассчитанные камерой уровни черного доступны в метаданных
Исправлена ошибка расчета уровня черного, имеющаяся в dcraw (впрочем, на результат она влияет не очень сильно).
Ну и по мелочи: баги, ключ -s у unprocessed_raw, импортирована свежа версия dcraw.
... а только с целью тестирования LibRaw и улучшения ея качества.
Имеется острая нужда в RAW-файлах следующих форматов:
Sony DSC-F828 Огромное спасибо за помощь!
Задники Imacon Ixpress - нужны RAW-файлы в родном формате;
Задники PhaseOne - нужны RAW в нежатом формате;
Задники Sinar - нужны RAW-файлы, снятые в режиме 4-shot
Если у вас есть такое оборудование, либо же просто файлы в данном формате (что изображено - неважно, мне сами данные нужны) - свяжитесь со мной пожалуйста, придумаем способ как передать.
Это довольно важный релиз, открывающий массу новых (но пока - потенциальных) возможностей для разработчиков, над некоторыми вещами я в фоновом режиме думал с начала осени и тороплюсь поделиться:
Говоря о RAW-данных ("необработанные", "данные прямо с матрицы") большинство фотографов (да и не только фотографов) полагают, что сенсор - это очень простая штука: массив светочувствительных элементов, цветные фильтры, сбоку прикручен АЦП (или несколько). Появляется в рекламных буклетах производителей фраза "мы уменьшили зазор между микролинзами" - вспоминают еще и про микролинзы. Документации то разумной почти нет. Про острую нужду в кривых спектральной чувствительности мы уже писали в статье для Компьютерры, но есть острая нужда не только в этих данных.
Вот, например, "черная рамка" или маскированные пикселы. Они считываются с матрицы, но в финальное изображение - не попадают. Значения считанных оттуда пикселов - это источник данных для выставления уровня черного. Если читать исходные тексты dcraw, то видно, что для большого числа камер Dave Coffin (а за ним - и многие последователи) банально вычисляет среднее по некоему участку черной рамки (или же в последних версиях для некоторых камер делает чуть-чуть сложнее, считая отдельное среднее для четных и нечетных столбцов), затем это среднее вычитается из значений, считанных с активных пикселов и все.
Впрочем, некоторые производители завесу немножко приоткрывают. Вот, скажем, Kodak. В Кодаковских datasheets на сенсоры написано много всего интересного. И если почитать, например, документацию на KAF-50100 (картинка справа взята из нее), то становится понятно, что структура неактивных пикселов - сложная, тут и референс для выставления уровня черного и что-то тестовое и какие-то буферные пикселы.
Исправлена ошибка с утечкой файловых дескрипторов и памяти под буферы при извлечении thumbnails. Проявиться она могла только при некорректном использовании библиотеки, однако народ наступил на...
Мы с Ильей Боргом написали в Компьютерру статью, в которой постарались описать наше видение современного состояния дел с RAW-форматами. Прошло три недели с выхода журнала и, согласно первоначальной договоренности, перепечатываем у себя:
Позволю себе процитировать вводный раздел целиком.
За последние 10—15 лет цифровая фотография вытеснила фотопленку практически из всех традиционных областей применения. Конечным потребителям проданы сотни миллионов цифровых фотокамер, не считая камер, проданных в мобильных телефонах. Столь массовая индустрия не может существовать без стандартов — и таковые, казалось бы, имеются: стандартизованы устройства для хранения данных (flash-карточки) и формат изображений JPEG — наиболее массовый и удовлетворяющий потребности подавляющего числа пользователей.
Однако формат JPEG далеко не всегда удовлетворяет требованиям профессионалов — фотографов, дизайнеров, персонал prepress-бюро, а тем более фотобанков и фотоархивов. Зачастую не удовлетворяет он и требованиям "продвинутых" фотолюбителей. Именно поэтому многие модели фотокамер, обычно позиционируемые производителем как профессиональные и полупрофессиональные, поддерживают, кроме JPEG, и запись изображения в так называемом "формате RAW". У стороннего наблюдателя может создаться впечатление, что RAW — это тоже такой стандартный формат, обеспечивающий лучшее качество — "качество для профи".
В нашем маленьком тексте мы хотим показать, что на самом деле жизнь гораздо сложнее, а положение профессионалов на сегодняшнем цифровом фоторынке не просто ужасно, а совершенно ужасно, и к тому же еще и быстро ухудшается (в то время как у менее притязательных любителей — все отлично).
Как мне кажется, обсуждать данный текст лучше рядом с ним, поэтому комментарии тут я закрываю. LibRaw.SU дает комментировать без авторизации, хотя авторизованым пользователям доступно чуть больше пряников.
Поддержка Nikon D90 и P6000, Canon 50D, Sony A900, Panasonic FZ28 и LX3. При этом D90 и A900 поддержаны нормально, а для остальных нет таблиц RGBG-XYZ, цвета могут быть кривоваты (и будут еще апдейты).
Мы уже проползли в 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.
Импортирована последняя версия 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, но на многопроцессорных/многоядерных машинах работает в разы быстрее.
Содержание сейчас практически полностью эквивалентно русской версии, но со временем конечно разойдется (по форумам, по статьям).
Анонсирую тут с единственной целью - если кто-то постил ссылочки на русский вариант в англоязычные списки рассылки, то перепостите пожалуйста английский вариант.