LibRaw 0.13

По традиции, анонсируем LibRaw 0.13-Release.

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

  • Обновились распаковщики данных (на dcraw 9.06), отчего добавилась поддержка шести новых камер, включая Панасоники GH2 и GF2 и Sony A-580. Еще для девяти камер обновились цветовые данные.
  • Экспокоррекция со сжатием светов теперь работает просто по такой тоновой кривой, линейной внизу и корнекубичной вверху. Без всяких заумных контекстных расчетов яркости (изначально заимствованных из RawTherapee), которые подглюкивают на изображениях, сильно окрашенных в синие тона (и красные тоже, но в меньшей степени).
  • Ну и много всяких правок по мелочи.
Прошу любить и жаловаться.

Comments

А не написал ли кто какого-нибудь гуя к вашему этому чудесному либраву?

digiKam

Другой вопрос, что постпроцессинг в LibRaw - он вовсе не "чудесный", а "только пример", а digiKam использует именно его.

Почему никто не напишет что-то менее зависимое от среды? Хотел поставить digiKam, так весь KDE установиться хочет.
И вообще. Этот продукт полноценный или «только пример», который реально использовать нельзя?
Dcraw вовсе убог. Пользуюсь Bibble 5.

digiKam - полноценный продукт, по слухам (я не пользуюсь), но это больше Digital Asset Management, чем RAW-процессор.

А RAW-процессору хорошему - ему нужен другой постпроцессинг совсем. Если хорошему. Мало их, страшно далеки они от народа.

Ну ясно. Продолжу изучение указанного продукта, а за этим таки продолжу наблюдение. ;)

Три дополнительных метода подавления шума перед демозаикой:
Подавление banding
Подавление импульсного шума
Уравнивание зеленых каналов

- а как их можно протестировать? Только собрав вручную dcraw_emu?

К сожалению - да.

То что входит в дополнительные demosaic-pack-и, то не входит в собранные бинарные пакеты, ибо делать по три бинарных пакета слишком уж мучительно.

Можно взять готовый инсталлятор digiKam под винду, но или придется подождать пока "стабильная" версия digiKam обновится до LibRaw 0.13, либо найти бинарный пакет с 0.13-beta (я не уверен, что он есть, впрочем).

А почему не собирать в бинарные прямо с дополнительными возможностями? То есть, непонятно почему какие-то фичи в dcraw_emu включаются, а какие-то нет.

Если интересно - то я им пользуюсь, вот в жж выкладываю фотографии - это всё им проявлено. У меня интерес-то шкурный.

А banging noise у Canon 5d очень уж плохой, вот я думаю чем это лечить.

Проблема в том, что умножение сущностей увеличивает бардак. Шансов собрать или выложить не то, не так или не туда - много.

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

Ну грустно :-)

Ладно, посмотрю, может сам смогу собрать. Когда-то в институте я что-то компилировал и оно даже работало :-)

Я учту вашу боль, может быть релизы, не такие и частые, буду выкладывать в нескольких вариантах.
Беты - точно не буду.

Спасибо :-)

Я, в принципе, собираюсь в жж писать о том, как я фотографии "вручную" проявляю, и чем это лучше, чем просто так, в adobecameraraw

Раньше я dcraw использовал, теперь понял что dcraw_emu лучше, ну и проект всё-же более живой.

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

dcraw тоже жива, но получить оттуда feedback не всякому дано.

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

Что же до софта, раз не пугаетесь командной строки, то посмотрите на Argyll, он хороший и интересный и много умеет.

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

Argyll'ом и строил. Он табличные профили строит плохо. По-моему, проблема и в том, что 17 отсчётов на профиль мало.

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

А 17 отсчетов на табличный профиль, если я правильно понял что это LUT имеется в виду, конечно мало.

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

Это не значит, что нужно делать плохо, вовсе нет. Просто разница по цветам критична, даже на картинке 600 на 400 пикселей. Цвета и их естественность играют куда как большую роль в восприятии.

Другое дело, что сейчас никто камеры не профилирует, нет ничего под это. То что есть, часто очень убого. А если профилируют, то всё сводится к умножению цветов на матрицу, и расчёту этой матрицы.

Там не только муар, там false color, там вполне макро-эффекты могут быть.

Вроде таких вот: http://www.libraw.su/articles/bayer-moire.html
(это взбрыки интерполяции, а дальше out-of-gamut и целочисленный процессинг).
Прекрасно видно на превьюшках, да?

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

А вот вещи, которой действительно очень не хватает, нет нигде. Это - автоматическое подавление хроматических аберраций. Причём тут штука, которая бы делала это до дебауризации, была бы как нельзя кстати.

Увы, существующие методы делают это плохо. Штука в том, что эти аберрации - они непостоянны по кадру. То есть, если два объекта находятся в пределах grip, но один ближе, другой дальше, то они будут разные. А в зоне расфокуса они тоже будут.

Поэтому плохо переводить в полярные координаты, и брать r'=f(r). Нужно делать что-то вроде r'=f(r,a), учитывая угол, ну, например. Ну, а кто будет это писать? Это большой и сложный оптимизационный проект.

Вполне себе есть в rawtherapee, а оттуда уже в других проектах ну и в libraw тоже.
Причем делает именно так, как вы хотите. Разбивает кадр на участки в 256 точек и для каждого участка пытается на автомате это дело пофиксить. Другое дело, что иногда это у нее не очень получается.

Вот что означает "есть в libraw"?

dcraw_emu -acae 0 0
(нули - включают автомат)

Ну это правильнее Алексей расскажет, но по коду:

dcraw_emu.cpp

if(!strcmp(optstr,"-acae"))
{
OUT.ca_correc = 1;
OUT.cared = (float)atof(argv[arg++]);
OUT.cablue = (float)atof(argv[arg++]);
}

libraw_cxx.cpp
if (O.ca_correc >0 ) {cablue=O.cablue; cared=O.cared; CA_correct_RT(cablue, cared);}

Вам ответили у меня в блоге (увы, но обратной трансляции каментов в ЖЖ у меня нет):
http://blog.lexa.ru/2011/02/07/libraw_013.html#comment-15139
===
Вполне себе есть в rawtherapee, а оттуда уже в других проектах ну и в libraw тоже.
Причем делает именно так, как вы хотите. Разбивает кадр на участки в 256 точек и для каждого участка пытается на автомате это дело пофиксить. Другое дело, что иногда это у нее не очень получается.
===

Кстати, там плохо сделан эксперимент.

Размывалось в ImageMagik, да?

А там размытие в gamma пространстве.

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

Вот пример, как это влияет на муар.

Насколько я понимаю, ImageMagick перед размытием не конвертирует в линейное, правильно?

Ну так и потом никто не конвертирует, прямо эти данные становятся "линейными" в DNG, т.е. разницы нет.

А картинка с муаром красивая, спасибо!

Вот не знаю по поводу blur, но осмелюсь предположить что он (ImageMagick) сделает именно то, о чем вы его попросите. По аналогии с примером из документации и комментарии к нему

Many image processing algorithms assume your image is in a linear-light coding. If your image is gamma-corrected, you can remove the nonlinear gamma correction, apply the transform, then restore it like this:

convert portrait.jpg -gamma .45455 -resize 25% -gamma 2.2 \
-quality 92 passport.jpg

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

C1 использует LUT размерностью 33

А табличные профили, я верно понимаю, применяются для каждого канала независимо?

Да нет, что вы, так не будет работать (это будут поканальные кривые тогда).

Там 3 значения на входе, 3 на выходе и (какая-то) интерполяция

:) Ну да, табличный профиль - не поканальная кривая. А какже тогда табличный профиль применять до демозайки?

Да, там есть проблема курицы и яйца, я знаю. В этом и фишка.

Там три значения на входе, 16 бит точности.
Потом к ним применяются кривые.
Потом табличная функция трёхмерная, вероятно с какой-то интерполяцией.
Потом - опять кривые.
Ещё где-то применяется умножение на матрицу, но обычно она единичная.

Держите в рамках спонсорской помощи:

http://www.libraw.su/data/LibRaw-0.13.0-with-GPL2-GPL3-demosaic-packs-Wi...

Мне однократно несложно собрать, а на систематическую основу - наверное тоже поставлю, давно пора....

Да, собрал, проверил что запускается и все :)

Начал тестировать

Во-первых, -fbdd N как-то очень сильно искажает баланс белого.

А, если можно, на что влияют -aclean <l c> -agreen <g> -aline <l> - вот эти l, c и g?

Спасибо!

На неделе попробую, напишу что как

А вы какой баланс белого используете? Автомат может и искажаться наверное, а так - я по тону разницы между -fbdd 1 -fbdd 2 и отсутствием - не вижу.

По второму вопросу давайте я вас к документации отошлю (doc/API-datastruct-rus.html), пора ее на сайте поапдейтить, кстати.

-aclean:
int cfa_clean; float lclean,cclean;
Подавляет импульсный (высокочастотный) шум.
cfa_clean: положительное значение включает подавление.
lclean,cclean - Степень подавления для яркостного (lclean)
(соответственно, для автомата нужно -aclean 0 0 и это отличается от отсутствия ключа -aclean вовсе)
Ну и так далее:
-agreen - это про cfa_green
-aline - cfaline

Про доки - ок, я ступил

Проявляю вот таким bat файлом:

set common=-v -q 6 -6 -T -f -v -H 0
set additional=-fbdd 2
set outcolor=-o 0 -g 2.2 0.0
set whitebalance=-r 1.000 1.000 1.000 1.000

Вот, это опции все перечислены. Вот на на -fbdd разница просто драматическая. Если не будет, готов даже cr2 файл выложить, но у меня на любом.

-f несовместима с fbdd. Это, наверное, баг, надо его сделать фичей (т.е. описать в документации).

В 0.13.1 поправлю

0.13.1 (собранная с demosaic packs) доступна с сайта: http://www.libraw.su/download

* Обновлена документация dcraw_emu
* Обновлены файлы ./configure для более корректной линковки на некоторых системах
* Алгоритм подавления FBDD выключен для полноцветных (не байеровских) и 4-цветных байеровских файлов из-за несовместимости (включая псевдо-4-цветный байер, включенный опцией four_color_rgb)

Это на работу софта не влияет, но может всетаки meta вернуть в документацию для тупых гляделок типа mc. Только поставить там charset=UTF8, как оно и есть на самом деле и как написано в index.html, а не 1251 . А то изредка нажмешь F3 в мс, а там иероглифы, ну и вообще не нажимаешь.

Я вроде везде BOM поставил, все кто понимают UTF8 - должны сами фишку просечь.

Значит у меня совсем тупой.
Добавишь - ляпота. Не добавишь - понять сложно.
Ну и фиг с ним с тупым. Может со временем поумнеет.

После добавишь - еще были слова про мету, чарсет, utf8. Скушались кем то по дороге.

Я поправил.

У меня для счастья надо <code> ставить

BOM-а нет в API-notes-rus, добавил.

В остальных русских - есть и все клиенты обязаны фишку сечь (без этого с UTF вообще жизни нет)

git pull

Значит это у меня косяк где-то. Мозилла - понимает mc, lynx - нет. В общем то не критично.

mc-4.6.2-8mdv2009.1
lynx-2.8.6-4mdv2009.1


env|grep -i lang
LANG=en_US.UTF-8
LANGUAGE=en_US.UTF-8:en_US:en

env|grep LC
LC_PAPER=en_US.UTF-8
LC_ADDRESS=en_US.UTF-8
LC_MONETARY=en_US.UTF-8
LC_SOURCED=1
LC_NUMERIC=en_US.UTF-8
LC_TELEPHONE=en_US.UTF-8
LC_MESSAGES=en_US.UTF-8
LC_IDENTIFICATION=en_US.UTF-8
LC_COLLATE=en_US.UTF-8
LC_MEASUREMENT=en_US.UTF-8
LC_CTYPE=en_US.UTF-8
LC_TIME=en_US.UTF-8
LC_NAME=en_US.UTF-8

Я тут читаю про фотодатчики всякие -- у всех ПО СУТИ выход -- это ватты на квадратный метр. Что бы пересчитать в люксы (из которых уже делаются EV) надо знать спектр падающего света. КАК работают все внешние экспонометры!? Они же не колориметры (кроме тех, что колориметры за оченьмногобабла)! Ты не знаешь ответ на этот вопрос?

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

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

Да, вроде как так и есть, и датчик такой я нашёл. вот только его выход -- ток от 10E-4 до 10E3 микроампер (!). Такое мерят -- то ещё удовольстиве. С нужной точностью. Он линейный по люксам, гад. Наверху так точно и не надо (EV-то --- логарифмические), а куда деваться? :)

ориентировочные картинки spectral responce
фотоматериалов
http://photo.net/photo/edscott/pss00010.htm
некоторых экспонометров
http://photo.net/photo/edscott/pss00020.htm
и любимого раньше изготовителями экспонометров CDS
фоторезистора
http://ronja.twibright.com/datasheets/cds-resistor-pgm.pdf

Кошмар :) CD(S.Se) ещё на что-то "похож". Хотя я уже нашёл двухдиодные датчики которые компенсируются почти точно до глаза (уже в цифре, после оцифровки). Но медленные все like hell -- вспышку ими не померить, у них время интеграции 400ms типичное!
Да и диапазон 1-100'000 люкс не тянут.

вот фотодиод за зелёным фильтром (BPW-21R) уже реально использовать, но там очень серьёзно кондиционировать сигнал придётся.

Есть такая волшебная штучка:
http://www.w-r-e.de/robotik/data/opt/tcs230.pdf
На ней вообще всё что угодно можно сделать.
Например французы колорметр ваяют:
http://www.homecinema-fr.com/colorimetre/sonde.php
и не только французы
http://fuzzcraft.com/colorimeter.html
вот по поводу чувствительности - не уверен, что хватит.

TCS230 я видел, конечно, у него спектральная чувствительность та ещё, выправлять надо, а не ясно -- как. У него выход именно что в uW/cm^2, и при неправильной чувствительности есть та самая проблема с которой я начал этот тредик.
Чувствительности у него хватает, я считал.

>выправлять надо, а не ясно -- как.
Программно? Всё-равно он за собой микроконтроллер тащит...

Тут хитрость в том, что программное выправление зависит от спектра источника. TCS230 (без буковки R) может и спектр померять, конечно, но "по очереди" что для флэшметра не очень-то пригодно. Выход у него, заразы, один. А что он меряет -- R, G, B или Clear -- переключается, и это занимает время.

Для флэшметра - конечно...
Как вариант - поставить 3-4 штуки,
Размеры-то небольшие. Но для спотметра - тоже неочень :)
Для флэшметра и CDS, ЕМНИМС не годится, инерционен
больно...

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

Я вас читаю с восторгом.

Но неужто не проще на Ebay купить б/у секоник 308?

А кто что говорит про "проще"? :)
Или даже про "дешевле"? :)

Кстати, у L-308S нет приоритета диафрагмы (как и у моего спотметра Minolta Spotmerter F). Почему -- ума не приложу, бред какой-то.
А ещё ряд выдержек моего спотметра не совпадает с рядом выдержек затвора моего плёночного аппарата :) Там же есть два ряда :) И это не переключается. про L-308S не знаю, не смотрел.

А.

Если о проще/дешевле разговору нет, то я умолкаю. Действительно, самому - прикольнее.

А вот, кстати, приехал мне с инджапана sekonic 558.
И сразу дурацкий вопрос возник, а что, у него экспокоррекция
с другим знаком, по сравнению с кэноновским внутрикамерным?
Ну т.е. на кэноне я кручу вправо к +2 и получаю экспозицию больше.
А на секонике кручу на +2 и получаю экспозицию меньше...

Пардон, а что вы "крутите"?

Там же при кручении меняется экспопара, а если хочется поправки, то это делается кнопками iso1/iso2

Ну,собственно Jog wheel и кручу, разумеется нажав предварительно iso1/iso2
одновременно. На индикаторе Adj, число и +/-.
Так вот если на индикаторе + то он потом экспозицию уменьшает,
в отличии от внутрикамерного...

Ну да, все правильно:
- "если мы поставим ISO на 2 стопа выше, то экспонировать среднесерое надо так-то".

Я на кнопку ISO2 повесил "headroom" (запас в экспозиции в светах) камеры (-3.3). Т.е. если замерять света, то по нажатию ISO2 получим такую экспозицию, что в светах еще не будет вылета.

>>"если мы поставим ISO на 2 стопа выше, то экспонировать среднесерое надо так-то".
т.е. заточено приблизительно под такое:
"взяли плёнку из новой партии, стандартно экспонировали, стандартно проявили
(ну или нестандартно,но как-то одинаково). Увидели, что чутьё больше написаного
на коробке на 1.3 стопа , накрутили экспокоррекцию +1.3" ?
То-есть экспокоррекция в терминах чувствительности?
А на камере:
" Посмотрел на гистограмму, матюгнулся - опять замер на "такой сцене" мажет
в минус, крутну ка я колёсико в + "
А то что-то в голове не утаптывается...

Исторически это выглядело так:
- взяли пленку из новой партии (пусть ISO50 по номиналу)
- сняли ее как ISO32,40,50,64,80
- проявили, посмотрели, дальше снимаем с тем ISO, который больше понравился.

А разница в "знаках" она связана с тем, что на камере колесиком меняется *экспозиция*, а на экспонометре - *чувствительность*

>>Я на кнопку ISO2 повесил "headroom" (запас в экспозиции в светах) камеры (-3.3)
В терминах Секоника имеется ввиду Filter compensation ?

Ага.

О спасибо, интересный приём, уже накрутил...
:)

У меня теперь такой вопрос - а подавление banding там как сделано?

В принципе, я пробовал, и если честно - мне показалось, что оно всё-таки слишком много деталей убирает.

Вот, скажем, в topaz denoize debanding работает на удивление хорошо. Причём на больших ISO у 5dmk2 - это must have, я бы сказал...

Честно хотите? Да я понятия не имею :)

Контрибуторы спи перенесли код из RawTherappe, я посмотрел на результат, изображение он не убивает (бывает и иначе: http://blog.lexa.ru/2010/06/06/beda_kol_sapogi_nachnet_pechi.html ) - и оставил.

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

Ну раз обратные посты не работают, чтобы Алексею почтальоном не работать.

Если вы про ключ -aline - вот ссылка на аторское объяснение (второй пост)
http://www.rawtherapee.com/forum/viewtopic.php?t=2240

Если про то о чем Алексей написал (-agreen) - то это другая история. И мне показалось оно (оригинал) работает не намного лучше (на том, что мне попадалось). Может просто показалось?
Чтобы не голословно туда же пошлю:
http://www.rawtherapee.com/forum/viewtopic.php?t=2650

As for what the algorithm does, it performs a Discrete Cosine Transform in 8x8 blocks (separately within each RGGB subarray of the bayer mosaic raw data) and then damps those Fourier coefficients that are related to vertical and horizontal lines, if the contrast is low enough (high contrast vertical and horizontal lines are treated as detail). The slider sets the contrast threshold below which the debanding is allowed to operate. Long story short -- yes it does blend neighboring pixels.

(вздыхая) ну что сказать. Они, конечно, тупые уроды, слов нет.

Я начинаю подумывать, чтобы внести в LibRaw свой код, а это вообще можно?

Да можно, конечно. Лучше, конечно, в основной пакет, а не в demosaic packs. Т.е. под тройной лицензией (LGPL/CDDL/LibRaw)

Наилучший способо: делаете свой клон на GitHub (https://github.com/LibRaw/LibRaw) правите как вам нравится, а потом свистите в свисток чтобы я помержил в основное дерево.

Но и просто измененные исходные тексты я тоже приму, хотя технологически это неудобнее для меня.

делаете свой клон
В терминах GitHub это называется fork

Ок, я задам ещё один глупый, но волнующий меня вопрос :-)

Я когда-то писал программы на C/C++, лет 8-10 тому назад. И сейчас зарабатываю на жизнь, в общем, программированием, правда на ABAP, SQL и VBA.

Что нужно сделать, чтобы это дело открыть в VC, и, грубо говоря, начать писать свой код, по запросу получая exe файл или в окошке отлаживая кусочки? Там есть готовый для открытия проект в VS, да и каким сейчас Visual Studio пользоваться модно, уже 2008-м, да?

Нужно там подключать что-то?

Мне стыдно, но готового проекта для VS нету.
Я не умею его делать отчуждаемым, чтобы он не содержал локальных путей и всего такого прочего. Надо один раз постичь, но все руки не доходят.

Вот Makefile.msvc для Visual C++/nmake - есть.
Из него сделать проект несложно, все нужные дефайны там перечислены, но всякий раз когда мне надо - я руками леплю проект, там дела то на три минуты (добавить нужные исходники и нужные дефайны препроцессору).

Проект - попробую сделать с помощью qmake, оно, по идее, генерирует их как-то независимо. Но не сегодня, скорее всего, сегодня я по уши в Qt

Сделал .sln (группа проектов) и отдельные проекты для DLL и всех примеров. Через посредство qmake

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

На github уже лежит.

А касаемо сути замечания: меня тоже временами удивляет, что делают в опенсорсных графических приложениях.

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

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

И что, теперь молчать!? :)