No installer included. Extract the folder “RawTherapee_lensfun-dev” to e.g. your Desktop and run “rawtherapee.exe” inside this folder.
Cache and settings are saved into “localappdata\RawTherapee-lensfun-dev”. It leaves your existing installation untouched. The lensfun database is located in share\lensfun.
Version: 5.2-180-gb1ce30c7
Branch: dev
Commit: b1ce30c7
Commit date: 2017-09-17
Compiler: gcc 7.2.0
Processor: generic x86
System: Windows
Bit depth: 64 bits
Gtkmm: V3.22.0
Lensfun: V0.3.2.0
Build type: release
Build flags: -mwin32 -m64 -mthreads -msse2 -std=c++11 -mtune=generic -Werror=unused-label -fopenmp -Werror=unknown-pragmas -Wall -Wno-unused-result -Wno-deprecated-declarations -Wno-aggressive-loop-optimizations -DNDEBUG -O3
Link flags: -m64 -mthreads -static-libgcc -mtune=generic -s -O3
OpenMP support: ON
MMAP support: ON
The database in Ver. 5.2-169-g952ada55 is lensdatabase version="2" (timestamp 1502862887), so it doesn’t work with your build. With a ver. 1, timestamp 1502862887, borrowed from the last darktable for Win, it works fine.
No, I didn’t. I’ve build from dev. The release version of lensfun works fine without any issues finding the database. The test @jascal made shows that there is a different behaviour between the release and development version of lensfun, or in other words there’s a bug in the developement version.
Nope, sorry. There is a bug in dev in locating the lensfun db if a custom path is set and RT is built in bundle mode. I believe now I have fixed it in lensfun-db-path-bundle (the version from yesterday was still buggy).
With the current dev:
$ /home/alb/src/RawTherapee/build_clang_dbg/Debug/rawtherapee
[...]
Loading lensfun database from './share/lensfun'...FAIL
[...]
With the current lensfun-db-path-bundle:
$ /home/alb/src/RawTherapee/build_clang_dbg/Debug/rawtherapee
[...]
Loading lensfun database from '/home/alb/src/RawTherapee/build_clang_dbg/Debug/./share/lensfun'...OK
[...]
Same lensfun version.
EDIT: both configured with BUILD_BUNDLE=1 and LENSFUNDBDIR=share/lensfun
No, in general it’s not necessary. But it is useful if e.g. you have multiple versions of lensfun installed in your system, and you want to make sure that RT is not affected by them (see a few posts above for a concrete scenario).
@gaaned92, I suggest not to set a lensfun path for Windows builds. The “share” folder inside RT has the highest priority, so everything should work fine without the path.
I found the issue I experienced was due to unmatched dll’s and the lens data. Basically, I used the dll’s came from the MSYS2 installed lensfun and the data from the build you created (I guess you build the lensfun package yourself).
After I build the lensfun package and replaced the liblensfun.dll, everything works perfectly.
I believe it’s worth noting that lensfun package installed by MSYS2 has a much older lens database than the one you can build from the source code.
I think you should test that the lensfun-db-path-bundle works properly on windows. I tested on linux and it seems fine, but given that the problem is most likely to be more visible on windows (on linux I suppose most people will either use the stock lensfun provided by their distro and/or will be ready to deal with a custom lensfun themselves), I’d appreciate a confirmation that it works as intended also there. Meaning: it should only find the db in the LENSFUNDBDIR path, everything else should be ignored.
Once we get some evidence that the above branch works ok, I’ll merge it into dev
did you delete the options file among the tests? the only difference between the two branches is in how the default path is initialized. the difference might seem minor, but for users installing a lensfun-enabled RT for the first time, it’s the default that matters…