LibRaw 0.19 (Beta1)
lexa - 28/Фев/2018 12:31
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 в правильной матрице, но этот патч, если не найдено 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/- пишите.
GX80/GX85
Решил погонять равы с Lumix GX80 (GX85).
Странная матрица в cam_xyz приходит. Левые цвета какие-то.
Для G8 - нормально.
P.S.: Последняя бета, но камера эта добавлена давненько.
P.P.S: Забыл (или не работают) пароли на libraw.org/blog.lexa.ru. Восстановление тоже не пришло на почту :(
PPS: обращайтесь к провайдеру
PPS: обращайтесь к провайдеру, ukr.net этот (канадский) адрес режектит. Данный ответ вы на почту тоже не увидите.
По основному вопросу: https://www.dropbox.com/s/ca6jd8nnbpowh5a/Screenshot%202018-03-13%2021.2...
ACR/RawDigger (в диггере профили из LibRaw), катастрофы не вижу.
Если есть пример с катастрофой - хочу его видеть.
Пример с катастрофой: https:/
Пример с катастрофой: https://www.dropbox.com/s/fe2hw4dntvmfdvv/Screen%20Shot%202018-03-14%20a...
Читаю матрицу, как обычно, из imgdata.color.cam_xyz.
Потом, тоже как обычно, перевожу в xyz_cam D50 (инверсия, плюс перевод из D65 в D50).
Проблема такая выскочила первый раз.
Так а файлик то?
Так а файлик то?
https://s3.amazonaws.com
https://s3.amazonaws.com/files.dpreview.com/sample_galleries/5699693136/...
Ну не знаю: https://www
Ну не знаю: 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
Собственно, 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
Вот в этой строчке: "-0.4029 1.1950 0.2345" теряется "-" перед "0.4029"
В dcraw_common.cpp я его вижу, а в imgdata.color.cam_xyz его нет.
Может, я чего-то начудил, при обновлении Libraw. Сейчас пересоберу
raw-identify печатает из
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
Собранная из консоли 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
Потроха то (содержимое 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
можно закомментить в var_defines.h
// VCD
#define eeci_refine (imgdata.params.eeci_refine)
#define es_med_passes (imgdata.params.es_med_passes)
Таки да :)
Таки да :)
https://github.com/LibRaw
https://github.com/LibRaw/LibRaw/commit/2bab92b70f025c6d915a381a91f9e196...
Оперативно )
Оперативно )
Я не занудствую, но раз начали порядок наводить и лишнее отрезать, то я готов помошничать.
Так это, патчи в 0.19-stable
Так это, патчи в 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.
В таком вот аксепте: https:/
В таком вот аксепте: https://github.com/LibRaw/LibRaw/commit/3b0d18e22de933d8f39cc0b7b6b271e7...
В libraw_cxx теперь такой код
В 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) - его.
Как идея?
Логично. Мне нравится.
Логично. Мне нравится.
https://github.com/LibRaw
https://github.com/LibRaw/LibRaw/commit/f46156debc810b3187b23cfbbf37c88d...
При всем уважении к Яну
При всем уважении к Яну Владимировичу, нужен ли его исходник еще в Libraw?
wf_filtering.cpp
из dcraw_process убрали, следов больше не нашел.
Надо наверное в какой-то пак
Надо наверное в какой-то пак переместить.
Я не понимаю что делает этот код - и поддерживать соотв. не могу.
https://github.com/LibRaw
https://github.com/LibRaw/LibRaw-demosaic-pack-GPL2/commit/a559dbfd1b71f...
Проверка нужна
Добрый день. В методе демозаика Петрусевича в 32-разрядной венде ошибка всплывает из-за нехватки памяти. Файл aahd_demosaic.cpp
Нужно бы проверку добавить для
rgb_ahd[0] = (ushort3*) calloc(nr_height * nr_width,
(sizeof(ushort3) * 2 + sizeof(int3) * 2 + 3));
Ага, merror туда влеплю,
Ага, merror туда влеплю, спасибо
Благодарю!
Благодарю!
merror не влепился, потому
merror не влепился, потому что protected, LibRaw::calloc - по той же причине, менять ABI не хочу ради такого мелкого повода.
Поэтому так: https://github.com/LibRaw/LibRaw/commit/c9b4a259b2424e17d11b1276f1b987ca...
Так тоже устраивает )
Так тоже устраивает )