LibRaw 0.11.2

lexa - 11/Ноя/2010 23:01

По традиции, поспамлю тут немножко.

Вышла LibRaw 0.11.2 в которой:

  • Вычитание уровня черного производится всегда на стадии постпроцессинга (про что я тут уже писал), что сильно упрощает жизнь, особенно если у вас постпроцессинг свой: не надо разные камеры обрабатывать разными способами, черный или всегда сами вычитаете или всегда зовете LibRaw::subtract_black().
    Для пользователей постпроцессинга LibRaw в этом месте ничего вообще не изменилось, API старый, вычитание делается прозрачно для вас.
  • Сильно порефакторена AHD-интерполяция, если используется OpenMP, то на 4-процессорной машине оно теперь раза в полтора быстрее чем раньше (тоже с OpenMP) на полной обработке, т.е. AHD-стадия быстрее разика в 2-2.5
  • Новый I/O-layer, сделанный на iostreams, что для мультипоточных программ на Win32 и Linux сильно быстрее (на этих системах в FILE* I/O явно переборщили с блокировками). На FreeBSD/MacOS разницы никакой нет, что мне говорит об отсутствии там лишних блокировок (а кому-то еще - об убогости тамошней реализации iostreams :).
  • Поддержан мешочек новых камер (импортирована свежая dcraw 9.05):
    • Canon: G12, SX120, 60D,
    • Hasselblad H4D, Nokia X2, Olympus E-5,
    • Nikon: D3100, D7000, P7000,
    • Panasonic: FZ40, FZ100, LX5,
    • Pentax: K-r, K-5, 645D,
    • Samsung GX20, WB2000
  • Ну и по мелочи много поправлено, читайте Changelog.

Ну и на закуску: основная ветка разработки теперь дублируется на GitHub: github.com/LibRaw/LibRaw, отчего участие в наших развлечениях для сторонних желающих сильно облегчилось. Увы, но сил на дублирование всего репозитория не хватило, поэтому релизные боковые ветки - бэкпортятся в master, но вот самих боковых веток на github нету.

Comments

namgul (not verified) - 11/Ноя/2010 23:35

Можно оффтопик? Очень интересует вопрос - почему никто не умеет писать в raw, кроме камеры? Ведь вроде бы если умеешь читать - можно и писать в том же формате?

kika (not verified) - 12/Ноя/2010 00:12

EXIF или EXIF-оподобные тэги многие умеют писать, то есть всякую метаинформацию. А картинку как писать? Деинтерполировать ее в Байера обратно? То есть конечно можно нафантазировать такой байеровский узор, который после интерполяции даст похожую картинку, но это не будет иметь никакого отношения к исходному RAW.

namgul (not verified) - 12/Ноя/2010 00:34

зачем деинтерполировать? тот же libraw вполне умеет вытащить чистую картинку с каждой из четырех клеток матрицы, ее же по-идее и можно засунуть обратно

kika (not verified) - 12/Ноя/2010 01:34

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

J0hn - 12/Ноя/2010 02:32

может это имелось в виду: Признак 3: фотография в RAW

pavel_burov (not verified) - 12/Ноя/2010 04:56

> А в чем смысл-то тогда?

Например, RAW-файл подделать. Заменить метаданные, copyright-тэги и иже с ними. Дело полезное.

Чуть серьёзней можно попробовать что-то вроде цифрового кросс-процессинга проявка RAW с неродным вычислением цветовых компонент. Берём RAW-файл из, например, Canon и записываем его в .NEF а потом в Capture NX проявляем. Кое что из таких игрищ можно устроить в Adobe Camera Raw при помощи dcpTool, ну, например, попробовать вытащить олимпусовский цвет из совсем не олимпуса. Говорят (сам не проверял), если на Canon натравить Nikon'овские dcp-профили, иногда получаются интересные результаты.

kika (not verified) - 12/Ноя/2010 05:15

Тэги и метадату легко, и екзифтулом по-моему во многих случаях можно справиться.

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

lexa - 12/Ноя/2010 08:57

Спрос на редактирование RAW конечно будет, ибо эти RAW сейчас считаются *оригиналом*.

Лишнее убрать, усы подрисовать, все такое.

Но тул для этого не может быть публичным.

kika (not verified) - 12/Ноя/2010 09:50

Считаться-то они считаются, но экспертизу на вмешательство проходят точно так же как и джипеги. Так что это разве что для какого-нибудь мелкого страхового мошенничества.

lexa - 12/Ноя/2010 08:56

Ну вот допустим, научился я делать NEF из CR2.
Метаданные от какой камеры будем писать для Nikon Capture?

Чем-то это мне напоминает "проявку в моче", в разной, ослиной, козлиной, итп

lexa - 12/Ноя/2010 08:42

В DNG пишите, есть адобовский SDK для этого.

Только вот *зачем* ?

3jia5l_ca6aka (not verified) - 12/Ноя/2010 02:33

сформировать можно, а зачем?
на вскидку ни одной области применения не приходит в голову

namgul (not verified) - 12/Ноя/2010 09:06

Во всех wildlife фотоконкурсах сейчас требуется предоставление оригинала фото в raw (DNG понятно что для этого не интересен). Правило ввели после нескольких скандалов с фотошопом. Вот мне и интересно, насколько вероятно что смогут до подделки raw добраться. Интерес чисто теоретический, естественно.

lexa - 12/Ноя/2010 09:18

Для DNG - никаких проблем вообще нет, в том смысле что средства есть, надо из них составить программу для этого.
При том, что существуют камеры, которые пишут только в DNG, поэтому формат не может быть "неинтересен".

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

В NEF и у Sony - есть криптованые (Nikon) и "криптованые" (Sony) поля, их не факт что получится воспроизвести. Но можно скопировать целиком с другого снимка, например.

Конкретно Canon имеет для единичек какое-то криптографическое подписывание и средство верификации. За отдельные деньги.
Думаю, что в судебно-полицейской практике такое станет обязательно постепенно (да и то, не факт, что нельзя имея камеру для опытов - заставить ее подписать что угодно).

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

kika (not verified) - 12/Ноя/2010 09:54

Конкретно Canon имеет для единичек какое-то криптографическое подписывание и средство верификации. За отдельные деньги.
Думаю, что в судебно-полицейской практике такое станет обязательно постепенно (да и то, не факт, что нельзя имея камеру для опытов - заставить ее подписать что угодно).

Матрицы документированы. Выпаиваем матрицу и на ее место впаиваем FPGA с интерфейсом к компьютеру. Получаем подписанный RAW со сценой [подставить плод больного воображения]. Я думаю что это проект на несколько месяцев с бюджетом в стольник, если наколенно делать.

lexa - 12/Ноя/2010 10:01

Да матрица тут вообще никоим боком, там же подписывается сигнал, который с АЦП снимается, а не с матрицы.

kika (not verified) - 12/Ноя/2010 10:33

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

oleg_kotenko (not verified) - 12/Ноя/2010 10:01

Особенно прикольно в этом списке выглядит Nokia. Телефоны тоже научились делать RAW?

lexa - 12/Ноя/2010 10:08

Ну да.
Nоkia и Motorola.
У меня даже сампл с моторолы есть в тестовом наборе (с Нокии - нет).

Притом, у Нокии - они честно 10-битные, судя по коду распаковки.
У Моторолы, насколько я помню, 8 бит и тоновая кривая, как у очень многих старых мыльниц.

oleg_kotenko (not verified) - 12/Ноя/2010 10:14

Сурово. Если захотят, могут и потеснить на рынке разнообразные компакты.

lexa - 12/Ноя/2010 10:44

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

Если считать и по количеству проданных агрегатов и, как мне кажется, по количеству кадров.

oleg_kotenko (not verified) - 12/Ноя/2010 10:50

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

lexa - 12/Ноя/2010 10:58

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

То есть я не уверен, что вся эта реклама телефонов со словами "5-мегапиксельная камера" (а такой рекламы реально много) - бьет в пустоту, дороговато в пустоту фигачить....

pavel_burov (not verified) - 13/Ноя/2010 00:18

> Сейчас камера в телефоне воспринимается пока ещё как приятное дополнение.

Пардон, скорее наоборот.

Современная фотография явление более социальное, чем менее художественное. Современная фотография это визуальное тэггирование жизни. В современном фотоаппарате главное кнопка отправить во flickr/facebook/twitter . Самый главный фотоаппарат в США в этом году Apple iPhone, им сделано (по осторожным оценкам) снимков чуть поболе, чем всеми остальными вместе взятыми.

В целом и общем, есть тенденция вымирания фотоаппаратов как отдельного класса устройств. Первые цифрокомпакты заменяли плёнкокомпакты. Предназначены были для протоколирования значительных событий в жизни (снимок я и Эйфелева башня , печать, рассылка родственникам и копию в свой альбом). Сейчас фокус сместился на сиюминутное (снимок жру вкусного кальмара! Завидовать в комментах ), на визуальную ленту как я провёл этим жизнью . Технология стала настолько доступной и хорошо отлаженной, что допускает бытовое её использование, не только по поводу .

J0hn - 12/Ноя/2010 11:25

autoconf/automake явно фашисты придумали.
всё-таки иногда принцип "одна тулза - малый набор возможностей + интерфейс к другим таким тулзкам" даёт эпически уродливые результаты: например.
Надо будет выделить время, чтобы попробовать познакомить libraw с cmake.

lexa - 12/Ноя/2010 11:32

Ага, фашисты.

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

С CMake оно уже тоже знакомо, надо из KDE просто этот кусок вытащить и добавить. Я все надеюсь, что автор digiKam возьмет и покоммитит это мне, надо ему намекнуть...:)

Но ./configure - к сожалению стало стандартом. Хотя вот при пересборке FreeBSD-шной машины недавно - всего-то сотня пакетов - я замаялся смотреть на "проверяем, strstr в линейное время ли работает..." (а если нет, то что?)

J0hn - 28/Ноя/2010 01:21

Кстате, CMake это не только ценный мех, а ещё и CTest, CDash, CPack.
CTest+CDash позволят легко запускать тесты, делать им mem prof (valgrind/purify), coverage (только gcc), и отсылать результаты на сервер CDash (есть free public: http://my.cdash.org/ ).
А вот пример, к VTK они прикрутили visual diff с gold'ами:
http://www.cdash.org/CDash/testDetails.php?test=67528963&build=736817 . Как именно, наверное можно в VTK посмотреть. Если вам не нужно exact compare, можно и tolerance задать... (естественно такое можно и без CDash сделать..) Это должно немного убрать головной боли типа http://blog.lexa.ru/2010/06/06/beda_kol_sapogi_nachnet_pechi.html .
Кстати, а как как оно сейчас тестится? Или ещё нет гигиены?

Вот презентации
http://www.youtube.com/watch?v=8Ut9o4OdSC0
http://www.kde.org/kdeslides/CampKDE2010/CampKDE2010-MarcusHanwell.pdf

lexa - 28/Ноя/2010 10:55

С тестами, где я знаю бинарный результат оно так и тестится:
dcraw_emu .... большой набор RAW
md5 результат >md5
сравнить с эталоном.
Но так можно сравнивать, например, результаты экстракции RAW-данных, которые действительно детерминированы (лежат в исходных файлах). По счастью, основная задача LibRaw - именно в этом, а постпроцессинг интересен (авторам библиотеки, не пользователям) не очень.

Проблема же в том, что всякие улучшения алгоритмов обработки - так протестировать невозможно. То бишь бинарный результат будет отличаться, а стало ли от этого лучше или хуже - это же только пролетарским чутьем и внимательным рассматриванием, причем не факт что по одному файлу. Или "в 99% стало лучше, а в 1% - сильно хуже".

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

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

J0hn - 28/Ноя/2010 16:25

Смысл же тестирования не только в контроле качества конечных изображений, но например также контроль того, чтобы тупо что-то не отвалилось: на каких-то тестах может работать, а на каких-то нет..
Например с помощью cmake/ctest/cdash легко настроить запуск сборки и тестирование одним скриптом разных конфигураций, в разных средах. Например я тестирую сборку и тесты в следующих конфигурациях [VS2005,VS2008,VS2010]x[x32,x64]x[Normal,OpenMP] на win, и [gcc41,gcc34]x[x32,x64]x[Normal,OpenMP] linux. И результаты едут в CDash, и чуть что - build error/warrning, test fail, mem leak (и другие прелести valgrind), сразу всё видно, и всё в одном месте.
Вот например в windows и linux fpu по-умолчанию находится в разных режимах точности, или например в VS C++ x64 нету _asm{} (алтернатива - линковка с masm и т.п. бинарниками), разный синтаксис asm'ских вставок у vs и gcc (intel и at&t), или ещё что-то env-зависимое, и уже другой результат, что-то не работает и т.п...

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

lexa - 28/Ноя/2010 16:38

Я вот почитал этот ужас: 20 конфигураций, перемножить на десяток бинарных параметров (on/off) и еще на какое-то количество с большим числом значений (включая float) и понимаю, что даже одного тестового прогона не дождусь (еще ~390 поддерживаемых камер вообще-то).

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

Не такой у меня (пока) большой варез, чтобы начать разваливаться под собственным весом

J0hn - 28/Ноя/2010 16:58

Тестирование запускается одной командой, тесты могут запускаться параллельно, можно запускать отдельные группы тестов, у make -j и т.п. я думаю конфигураций 100 протестируется за ночь.
Потом, вам не обязательно сразу запускать все тесты во всех конфигурациях.. кто-то может отсылать результаты по windows, кто-то по linux, кто-то по freebsd, а результаты будут отправляться в общий cdash ( пример http://www.cdash.org/CDash/index.php?project=ParaView ). Когда всё настроено на лёгкое тестирование и отправку, имхо люди сами будут запускать тестирование, многие торчат от шума вентиляторов, и от бегущих строчек по экрану.

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

lexa - 28/Ноя/2010 17:29

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

lexa - 28/Ноя/2010 16:46

Вдогонку.

Я не против тестирования, честно!, много раз видел от него пользу. Ну и вред тоже.

Но. По личному (~25-летнему, если fortran на перфокартах в школе считать) опыту вижу, что в относительно небольших проектах (несколько девелоперов x несколько лет или меньше) просто думать передней головой куда полезнее (в смысле расхода ресурсов), чем разводить полноценный тестовый стенд.
В частности по той причине, что тестовый стенд и ложные срабатывания тоже имеет в ненулевом количестве.

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

Но я стараюсь до такого не доводить.

J0hn - 28/Ноя/2010 17:16

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

И я считаю если идёт просмотр ста картинок вручную после каждой сборки, то это дело необходимо автоматизировать(это не про libraw, как там я не знаю, это в общем), по крайней мере такая мысль должна периодически возникать.

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

lexa - 28/Ноя/2010 17:25

Не, понятно что тесты должны запускаться по одной кнопке и, по возможности, быть автоматическими.

Но я многажды уже видел, когда за частоколом тотального тестирования вообще и юнит-тестов в частности - не видно окружающего мира.

Если буду страдать от контрибьюторов (от себя то - наврядли), введу военное время, пока я от них наслаждаюсь скорее.

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

J0hn - 29/Ноя/2010 04:07

Но я многажды уже видел, когда за частоколом тотального тестирования вообще и юнит-тестов в частности - не видно окружающего мира.

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

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

and_lv (not verified) - 20/Ноя/2010 02:26

Можно еще один оффтопик?
А по какой причине откатили LibRaw-demosaic-pack-GPL3?
Там беда какая то в результатах обнаружилась или не смогли ri->defgain победить?
Просто не хочется зря время тратить на проверку, раз уже кто то прошел этот путь.

lexa - 20/Ноя/2010 07:09

Откатил нерабочую версию. Она падала.

Сегодня буду разбираться подробнее.

Просто в master покоммитил то, что мне Christos прислал, а он такой, он не всегда присылает рабочее с первого раза.

P.S. Вообще, у меня сейчас приоритет - быстро выпустить рабочую Beta-1 (о которой объявить), может быть и со старым AMAZE, а уже потом улучшать и демозаики и вообще.

and_lv (not verified) - 20/Ноя/2010 11:52

Аха. Понял. Спасибо. Значит можно будет попробовать. А до imgdata.color.pre_mul если достукиваться извне не будет противоречить корректному пользованию libraw?

lexa - 20/Ноя/2010 12:38

ну естественно можно, вы же без этого баланс-цвет не сделаете нормально

lexa - 20/Ноя/2010 18:34

Не вижу, чтобы вы были на GitHub в watchers, поэтому тут поспамлю.

Все пропушено и даже потегано как 0.12.0-Beta1

Сегодня tarball(ы) выпущу.

and_lv (not verified) - 20/Ноя/2010 19:49

Алексей, спасибо.
Мы с вами чуть чуть общались на линуксграфикс. В 0.7 это уже не войдет. Останется со старой. А в следующей версии локомотив пошел другим путем. Демозаик там отдельно вынесен. Но все равно надо туда это будет прикручивать.
CA corrections кстати давал замечательную зеленую окантовку и зеленые волосы на фотографиях со вспышкой (по крайней мере у меня). Надо будет глянуть, починили или нет.

lexa - 20/Ноя/2010 19:55

Ну так никто не мешает вместо LibRaw::dcraw_process() написать свою такую же (или примерно такую же).

То бишь, какие-то куски из LibRaw, какие-то - свои, пропорции - по вкусу.

Меж тем, я очень рад, что хоть кто-то из пользователей LibRaw пишет свой постпроцессинг.

lexa - 20/Ноя/2010 19:57

Да, кстати, с предыдущего анонса все перетегано еще раза три. Там в ./configure.ac были досадные недоделки.

Но вот уже сейчас меня результат совсем устраивает (и src-тарболлы готовы, поужинаю и займусь бинарными)

lexa - 20/Ноя/2010 07:12

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

чтобы потом мержить через git merge

and_lv (not verified) - 20/Ноя/2010 11:46

Ну да. С SVN это было удобно. Вендор branch. А с гитом, как я понял, только ручками коммиты выбирать.
Про кошерность: мне показалось они одинаковые, за исключением работы в окне. Правда не понимаю такую уж большую необходимость. Ну получат результат на 1 секунду быстрее. А сдвинул окно и снова жди. Правда для libraw окна в тему.

lexa - 20/Ноя/2010 12:41

Да нет, с git оно еще волшебнее работает, я уже попробовал c основной LibRaw:

git checkout dcraw-dist-track
...копируем новую dcraw поверх...
git commit -a ;
git checkout master
git merge dcraw-dist-track

И мержатся только те коммиты, которые еще не мержены ранее.

А мержилка у гита лучше.