Windows 64 build with integration of lensfun

So does here!

FYI, I’m working on allowing RT to use its own “private” lensfun database

Wild guesses, but could it be that if it finds more than one DB then the DB-choosing logic fails, or maybe tries to load more items than can be loaded in a combobox?

@agriggio surely when I tested I had some lensfun DB laying somewhere without knowing!
But I still think at this time RT lensfun accessed …/share/lensfun, but I must be wrong!

If I am careful about that and suppress all lensfun DB existing here and there, effectively it seems own local DB is not accessed. still testing.

I much prefer RT lensfun uses its own private DB as otherwise there is the risk that some other app interfere or include incompatible data in a global DB. That’not good practice unless you are able to control the configuration of all apps.

@agriggio
I think it’s my fault.
I built an up to date lensfun version and linked it in a test version. I think this version acccess the DB in appdata.

When building dev branch, I forgot to come back to the MSYS2 lensfun version.
So I am rebuilding now to verify.

I just pushed a changeset that allows RT to use its own copy of the lensfun db. Here’s how it works. There’s a new config section in the options file:

[Lensfun]
DBDirectory=/path/to/lensfun/db

If /path/to/lensfun/db is empty, the normal logic of lensfun is used to load the database (this is described at http://lensfun.sourceforge.net/manual/dbsearch.html).
Otherwise, the db is loaded from the given directory.

The default value for the config setting can be controlled at compile-time, by setting the cmake variable LENSFUNDBDIR:

$ cmake -DLENSFUNDBDIR=/path/to/default/lensfundbdir

If unset (the default), the empty path will be used. So, by default we have the current behaviour, that is lensfun does its own search system-wide.

At compile-time, /path/to/default/lensfundbdir can also be a relative path. In this case, it is interpreted relative to DATADIR. So, people building RT in “bundle mode” can also include a copy of the lensfun DB, to make sure there are no clashes with other versions/DBs in the system.

I hope this solves the issue. If not, please let me know (and open a bug report on github).

2 Likes

Ok, rereading now I understand what you mean. Here’s how I would do this with dynamic profiles:

  1. create a rule that applies the following partial profile whenever your camera is found:
[LensProfile]
UseLensfun=true
LFAutoMatch=true
LFCameraMake=MY CAMERA MAKE
LFCameraModel=MY CAMERA MODEL

Notice that LFAutoMatch is still set to true here.

  1. add a rule for your lens that is not picked up automatically by lensfun, overriding LFAutoMatch:
[LensProfile]
LFAutoMatch=false
LFLens=MY LENS
  1. Make sure the rule for the lens comes after that for the camera, so that LFAutoMatch is properly overridden. Then you should be good to go.

If I want lDB located in …/share/lensfun, what exactly I have to write in DLENSFUNDBDIR?

Hey everyone,

Given you’re all talking about the lensfun addtion, I just did my usual git pull and compile and I get the following error:

-- Checking for module 'lensfun>=0.2'
--   
CMake Error at /usr/share/cmake-3.5/Modules/FindPkgConfig.cmake:367 (message):
  A required package was not found
Call Stack (most recent call first):
  /usr/share/cmake-3.5/Modules/FindPkgConfig.cmake:532 (_pkg_check_modules_internal)
  CMakeLists.txt:279 (pkg_check_modules)


-- Configuring incomplete, errors occurred!
See also "/home/pete/repo-rt/build/CMakeFiles/CMakeOutput.log".
make: *** No rule to make target 'install'.  Stop.
mv: cannot stat 'release': No such file or directory

You have to install the liblensfun-dev package (exact name depends on your distribution).

Whoops, yes, thanks. Just read about it in another thread on the site…

Added it and it’s now compiling.

Thanks.

Latest dev segfaults at start of RT (Windows 7).

@plaven If you get a segfault at start of rt, you can git checkout 5b3d60b. That should work.

1 Like

Is this what you mean?

pete@kanga~/rt $ ./rawtherapee

(rawtherapee:16493): GLib-CRITICAL **: g_file_get_contents: assertion 'filename != NULL' failed
Segmentation fault (core dumped)

yes, though I only get a segfault without the GLib-CRITICAL…

I’m just waiting for the build to finish now.

88%…

94%…

100%… man that’s fun to watch… :slight_smile:

@heckflosse, I can confirm that RT starts fine now.

I just pushed a fix for the segfault to dev

1 Like

Hey Ingo,

Just pulled and compiled, after the first start up and a crash, starting the second time it worked fine.

Peter.

What kind of crash was that? Can you try to reproduce?

It’s a crash that occurs every now and then, and I think it’s possibly due to PP3 files in a directory.

pete@kanga~/rt $ ./rawtherapee
*** Error in `./rawtherapee': realloc(): invalid pointer: 0x00007fe23281ad00 ***

There’s a back trace, in the console, not sure it’s what you’d need though.

The problem often though is that a second restart clears the issue and RT starts fine.

I have tried in the past to run it under gdb but it doesn’t fail.

Yes, please! :smiley: Please file a bug over at GitHub, so we can track it in the long run. Thanks!

I can’t answer this question. But you have to pull again if you want to use cmake variable LENSFUNDIR