LibRaw 0.19 (Beta1)

LibRaw 0.19 (beta1) (github)- это не только ценный мех, но и:

  • 1014 поддержаных камер
  • улучшенная обработка вложенных IFD в DNG
  • улучшенный разбор метаданных разных вендоров
  • улучшенная обработка превьюшек
  • вызов open_bayer для тех самоделкиных, кто дамп данных с сенсора имеет уже в памяти и без метаданных.
  • отсутствие поддержки LibRaw-demosaic-pack-GPLn, вместо них теперь сделаны callbacks, надеюсь что найдутся энтузиасты, которые demosaic packs прикрутят новым методом (а не через #ifdef как раньше).

Прошу любить, тестировать и жаловаться.

Comments

Самый неприятный момент для меня лично это, конечно, прикручивание методов демозаики из паков по-новому. Придется разбираться. Еще бы время найти на это )

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

Если нужна только демозаика, то дарю вот метод (но это, понятно, только для себя так можно)
1) пишем:
class MyLibRaw:: public LibRaw....
2) Всасываем туда все методы из demosaic packs
3) берем dcraw_process() от 0.18 (который позовет новые - всосаные на шаге 2 - методы)

Собственно и все.

UPD: а вообще этот хвост давно надо было резать. Т.е. уже много лет - при выпуске новой LibRaw - демозаик-паки только тегаются с тегом новой версии и все. Что означает, что жизни там нет (и всякие AMAZE и подобные - очень сильно устаревшие, Терапия то развивается)

А ведь это вы же просили правильный ColorMatrix из DNG вынимать?
Ну вот вроде оно: https://github.com/LibRaw/LibRaw/commit/291039ba1f8c546b9100261f769f1cf6...
(соотв. pull 0.19-stable с github)
Как говорится, works for me: https://www.dropbox.com/s/jmar7qqlhlx10rf/Screenshot%202018-03-11%2012.1...
(слева - было, справа - стало). Это - скриншот прямо вот с монитора моего, color space - практически AdobeRGB.

В флагах процессинга надо поставить битик:
imgdata.params.raw_processing_options |= LIBRAW_PROCESSING_CHECK_DNG_ILLUMINANT;

В ваших примерах там D65 в правильной матрице, но этот патч, если не найдено D65, поищет еще в округе....

Да, я просил. Я видел флаг, вроде работает. Спасибо. Под новую версию libraw много в своем софте перепиливать нужно, поэтому пока толком не проверял.

Если вдруг на жизненном пути попадутся DNG с тегом AsShotWhiteXY - пришлите пример.
Без примера неудобно, а этот тег в моем выправителе cmatrix - не задействован.

Я вроде таких не встречал. Эта координата меня лично несколько настораживает. Допустим, получаем мы 6348 кельвинов. Это D65 или как?

Я тоже не встречал, а тег такой есть.
Как замена поканальным балансам.

Да, хм.
"Перепиливать"?

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

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

Вот нашелся человек, которому это надо!
Может подхватите из наших слабеющих рук demosaic-packs?

Но конкретно с демозаикой - ставится callback для нее (хоть из производного класса) и натюрлих все работает (у меня тут на стенде есть *вообще совсем другая* демозаика, не из demosaic packs - работает).

Там два разных коллбека, один для байера, один для X-trans. Совсем по хорошему надо конечно три (байер 3-цвета/4 цвета, X-trans) чтобы на рантайме ничего не обрабатывать, если кто попросит - сделаем (моя "совсем другая" для 4 цветов просто делает fallback на VNG).

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

Вряд-ли вам нужны старые фовеоны (SD9-SD15).

В остальном же - там тривиально все прикручивается, если нужна помощь /советом или доп. callback/- пишите.

Решил погонять равы с Lumix GX80 (GX85).
Странная матрица в cam_xyz приходит. Левые цвета какие-то.
Для G8 - нормально.

P.S.: Последняя бета, но камера эта добавлена давненько.
P.P.S: Забыл (или не работают) пароли на libraw.org/blog.lexa.ru. Восстановление тоже не пришло на почту :(

PPS: обращайтесь к провайдеру, ukr.net этот (канадский) адрес режектит. Данный ответ вы на почту тоже не увидите.

По основному вопросу: https://www.dropbox.com/s/ca6jd8nnbpowh5a/Screenshot%202018-03-13%2021.2...
ACR/RawDigger (в диггере профили из LibRaw), катастрофы не вижу.

Если есть пример с катастрофой - хочу его видеть.

Пример с катастрофой: https://www.dropbox.com/s/fe2hw4dntvmfdvv/Screen%20Shot%202018-03-14%20a...

Читаю матрицу, как обычно, из imgdata.color.cam_xyz.
Потом, тоже как обычно, перевожу в xyz_cam D50 (инверсия, плюс перевод из D65 в D50).
Проблема такая выскочила первый раз.

Так а файлик то?

Ну не знаю: https://www.dropbox.com/s/zb19n0n241n63yw/Screenshot%202018-03-14%2009.0...
Справа ACR (все по нулям, профиль Adobe Standard), слева LibRaw (dcraw_emu -T -w -c 0)

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

Да, скриншот, как всегда "практически в Adobe RGB", монитор у меня от него отличается очень мало.

Тю...
Да, на скринах у вас кран желтый, а не оранжевый. И столбики не малиновые. Т.е. все норм
Интересно, где-это я (вдруг) с данными именно с этой камеры могу фейлиться... :(
А очень сложно вам дамп матрицы СС вытащить?
Буду разбираться со своей стороны.
Спасибо!

Сорри, промазал с ответом.

Какой из матриц?
Там же все лежит в исходнике (и для данной камеры - совпадает с адобовской матрицей D65).

Дальше можно применить adobe_coeff, тоже из исходника ж.

Собственно, raw-identify -v все ж выводит:

Camera2RGB matrix: (rgb_cam)
1.4813 -0.2314 -0.2499
-0.1884 1.6388 -0.4504
0.0090 -0.5138 1.5048

XYZ->CamRGB matrix (cam_xyz)
0.7771 -0.3020 -0.0629
-0.4029 1.1950 0.2345
-0.0821 0.1977 0.6119

Вот в этой строчке: "-0.4029 1.1950 0.2345" теряется "-" перед "0.4029"
В dcraw_common.cpp я его вижу, а в imgdata.color.cam_xyz его нет.
Может, я чего-то начудил, при обновлении Libraw. Сейчас пересоберу

raw-identify печатает из структур в памяти - т.е. там все на месте.

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

А нет ли у вас такого веселого эффекта, что *.h-файлы от одной версии, cpp - от другой...?

Вообщем я пока не понял, что именно, но что-то у меня не то в сборке Libraw, похоже.
У меня Libraw подключена к проекту не как 3rdpaty либа, а как часть проекта.
Использую старенький CMake, с которым она когда-то поставлялась.
Версию меняю заменой исходников. Мне стыдно, но "всегда работало" :).
Версия 18.8 теряет минус в матрице (той, о которой мы говорили), версия 19.1 не работает вообще.
Есть что-то в сборке, на что нужно обратить внимание (типа генерации кода или что-то подобное)?
Спасибо за помощь.

Начните с базовых вещей
make -f Makefile.dist
./bin/raw-identify -v тотфайл.rw2

Вообщем, пока разобрался с Libraw 0.18.8 только. Там действительно ошибка в данных:

{ "Panasonic DMC-GX85", -15, 0, /* markets: GX85 GX80 GX7MK2 */
{ 7771,-3020,-629,4029,11950,2345,-821,1977,6119 } },

То же самое для GX80/GX7MK2

Ага.
Я в 0.18 и не смотрел, смотрел в 0.19, там эти строчки исправлены

Собранная из консоли 0.19 работает (собрана, наверное, Apple LLVM version 9.0.0).
А в составе проекта собирается нормально, но не работает. В проект добавлены 6 файликов библиотеки. Выключена оптимизация и OpenMP. После вызова open_file - в данных ерунда. Пытался дебагом понять, но пока не понял, что не так.
Собираю на MacOS 10.13.12, clang 3.9.0.

Удостоверьтесь, что у вас не той версии libraw.h (и прочие потроха) не лежит в include path.

Инклуд верный вроде бы. Один подозрительный нашелся в портах, но он "не просматривается".
Буду разбираться, но штука, получается, достаточно интересная и пока даже представить не могу, что не так.
Приходилось подключать очень разные 3rd party библиотеки, но на такое наткнулся впервые.

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

Потроха то (содержимое class LibRaw) поменялось. Если где-то что-то (к примеру, precompiled headers) залипло - ну будет такой эффект.

Либо таки была libraw.h не та где-то (при сборке части проекта)

Было подобное, когда две версии libraw в проекте были. Я в какой-то момент забыл какой-то путь исправить, уже не помню какой. Каталог со старой версией переименовал и тогда получил ошибки, далее исправил везде пути и все стало на свои места.

Ну естественно ж. Внутри оно работает с одним libraw_data.h, вы снаружи с другим, все смещения - уехали в кукурузу.

Если кто на такое натыкается,есть вот макро в libraw_version.h:
#define LIBRAW_RUNTIME_CHECK_VERSION_EXACT() \
((LibRaw::versionNumber() & 0xffff00) == LIBRAW_MAKE_VERSION(LIBRAW_MAJOR_VERSION, LIBRAW_MINOR_VERSION, 0))

Пользуйтесь, оно ровно на такой случай (но неизменяемость внутренних структур мы гарантируем для MAJOR/MINOR, но не для snapshots)

Ну и там в libraw_version.h еще в таком духе есть макросы, все полезные если у кого бардак (у меня вот система сборки проверяет теги/бранчи гитовские)

LibRaw-0.19 перешла в стабильную версию?

Метастабильная :)

Потому что в Beta2 добавили декодер для Panasonic GH5s (чтобы не выпускать отдельный патч) и ABI относительно 0.19-beta1 изменился.

Но больше планов на изменения 0.19 нет.

можно закомментить в var_defines.h
// VCD
#define eeci_refine (imgdata.params.eeci_refine)
#define es_med_passes (imgdata.params.es_med_passes)

Таки да :)

Оперативно )
Я не занудствую, но раз начали порядок наводить и лишнее отрезать, то я готов помошничать.

Так это, патчи в 0.19-stable прямо в github
Я их потом всосу в мастер.

(в обратном направлении, master->0.19 сложно, потому что наш мастер и гитхабовский - это два разных)

Хотелось бы ясности. В доке читаю такое:
void (LibRaw::*interpolate_bayer)()
Pointer to user-specified bayer interpolation function. If not null, this function to be called instead of standard one specified by user_qual (or not specified)
Указателя interpolate_bayer в LibRaw нет. Но имеем защищенную структуру libraw_callbacks_t callbacks;
в которую записать можно только наследуя класс (я так и сделал).
А сама функция выглядит как void (*process_step_callback)(void *ctx);

Это я к тому, что из доки непонятно как пользоваться колбэками.

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

Это ошибка в доке, спасибо.

Сначала ввели interpolate_bayer/_xtrans, они были прямо в общей структуре. Потом добавилось коллбеков, унесли в отдельную структуру callbacks, а доку - забыли.

Я поправлю доку ближе к вечеру.

Для хромаберраций и т.п - тоже прикручены все коллбеки (на место, где был вызов из demosaic pack).

Надо брать за основу LibRaw 0.18, тамошний dcraw_process и смотреть где звались старые функции - и какие вместо них теперь callbacks.

В libraw_cxx теперь такой код

/* median filter callback, if not set use own */
median_filter();
SET_PROC_FLAG(LIBRAW_PROGRESS_MEDIAN_FILTER);

При этом колбэка на свой фильтр нет возможности указать. Соответственно, старый код (ниже) для метода 8 не прикрутить.
if (quality == 8)
{
if (eeci_refine_fl == 1) refinement();
if (O.med_passes > 0) median_filter_new();
if (es_med_passes_fl > 0) es_median_filter();
}
м.б. добавить колбэк тут?

Ну сложный вопрос:
median_filter() не делает ничего, если med_passes == 0 (умолчание).
Тот другой код - звался только если user_qual == 8 (т.е. Mixed VCD/Modified AHD interpolation)

Поскольку user_qual==8 не известен "базовой" libraw, то вся эта логика с quality==8 должна быть в callbacks.post_interpolate_cb
Но median_filter_new() наверное должен опираться на какую-то свою переменную, не на med_passes

Понятно. Сейчас приколочу.

Возможно, мне нужно вот к вызову median_filter() добавить условие:

if(!callbacks.post_interpolate_cb)
median_filter();

Предполагая (и документировав, наверное), что если ставится такой вот callback, то вся фильтрация (включая и fallback в median) - его.

Как идея?

Логично. Мне нравится.

При всем уважении к Яну Владимировичу, нужен ли его исходник еще в Libraw?
wf_filtering.cpp
из dcraw_process убрали, следов больше не нашел.

Надо наверное в какой-то пак переместить.

Я не понимаю что делает этот код - и поддерживать соотв. не могу.

Добрый день. В методе демозаика Петрусевича в 32-разрядной венде ошибка всплывает из-за нехватки памяти. Файл aahd_demosaic.cpp
Нужно бы проверку добавить для
rgb_ahd[0] = (ushort3*) calloc(nr_height * nr_width,
(sizeof(ushort3) * 2 + sizeof(int3) * 2 + 3));

Ага, merror туда влеплю, спасибо

Благодарю!

merror не влепился, потому что protected, LibRaw::calloc - по той же причине, менять ABI не хочу ради такого мелкого повода.

Поэтому так: https://github.com/LibRaw/LibRaw/commit/c9b4a259b2424e17d11b1276f1b987ca...

Так тоже устраивает )