Свежие комментарии

Title Comment
Так это, патчи в 0.19-stable

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

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

Оперативно )

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

https://github.com/LibRaw

https://github.com/LibRaw/LibRaw/commit/2bab92b70f025c6d915a381a91f9e196...

Таки да :)

Таки да :)

можно закомментить в var

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

Замер был точкой?

Замер был точкой?

Глянул тут с помощью RD пару

Глянул тут с помощью RD пару снимков, на одном выдержка ставилась по серому (зданию), на другом по светлому (снегу), у меня выходят средние значения по этим участкам 1900 и 3000 соответственно. Не должны они по логике быть одинаковы ? Т.е. получается, что если будем ставить по снегу, который считаем светами, в каких-то других условиях, то поправка составит больше или меньше, в зависимости от освещенности.

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

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

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

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

Стабильная?

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

Все камеры что я проверял

Все камеры что я проверял (давно) - в понятных условиях (ровное поле, если матричный замер) - камерный замер совпадал с секоником.

Алексей, 2 момента, почему

Алексей, 2 момента, почему может внутрикамерный замер давать как правило на +0.7 больше, чем внешний секоник (у которого около 118 в sRGB) ? И тенденция такая, что чем ярче света, по которым точкой мерим, тем ближе они к границе вылета, а тени, соответственно наоборот ? Контрастность объектива или никон этот чудит в раве ? Так то конечно, была б камера линейна, было бы проще этим методом пользоваться.

> судя по рисункам, для

> судя по рисункам, для пикселей фазового АФ другую глубину фотодиода (в новых) делают.

а можно пример (URL) ?

хм а разве не попадалось

хм а разве не попадалось случая, чтобы смывание фильтров было недостаточно? теоретически кроме фильтра, фотодиоды могут еще чем-то различаться. судя по рисункам, для пикселей фазового АФ другую глубину фотодиода (в новых) делают. могут разную глубину и для обычных делать..

Родными - да. Неродными (у

Родными - да. Неродными (у меня их совсем мало ручных) - ну совсем редко, наверное на этой камере еще даже и не.

А вообще мануальщиной

А вообще мануальщиной пользуетесь на ней?

Я тачскрин тамошний за 5

Я тачскрин тамошний за 5 минут не понял и выключил.

Я думал о "лупе" ручной

Я думал о "лупе" ручной фокусировки. Она тачскрином не управляется, да?

А какой у мануальщины

А какой у мануальщины автофокус?

А вот пишут, есть сенсорный икран

для выбора точек фокусировки. Интересно, он с неродной мануальщиной работает?

Ну естественно ж. Внутри оно

Ну естественно ж. Внутри оно работает с одним 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 в проекте были. Я в какой-то момент забыл какой-то путь исправить, уже не помню какой. Каталог со старой версией переименовал и тогда получил ошибки, далее исправил везде пути и все стало на свои места.

Потроха то (содержимое class

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

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

Вообщем, после каких-то

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

Инклуд верный вроде бы. Один

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

Удостоверьтесь, что у вас не

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

Собранная из консоли 0.19

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

Ага.

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

Вообщем, пока разобрался с

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

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

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

Начните с базовых вещей

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

Вообщем я пока не понял, что

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

Pages

Subscribe to comments_recent_new