I’m using dynamic profiles. And here the problem occurs.
The 1st profile is some kind of default w/o camera and w/o lens. This profile is setup for automatic camera and lens detection.
The result of the lens profile setting is like this:
As this lens is not a Nikon but a Tamron lens, I switch to manual and select the lens.
As I want to do this via a dynamic profile I add a 2nd profile where I just switch the lens profile section in the following way
[LensProfile]
LFAutoMatch=false
LFLens=Tamron …
However, the lens profile block gets fully cleared and then has just these two settings. The autodetection from the previous profile is completely lost.
I do the same with my ISO profiles, just switching single fields in the profile. And this works perfectly.
So it would be nice, if the pure existence of the [LensProfile] section would only touch the fields, which are listed in that block.
BTW, if I load this partial profile manually it works as expected.
On the contrary, you should be proud We rely on users to report bugs and help us improve RT, for the benefit of everybody.
In this case, however, I’m not sure I’d call it a bug. If you turn off auto matching, you are expected to provide both a camera and a lens. A lens alone is not sufficient. Did you try adding also the camera info? If that doesn’t work, then it’s definitely a bug (and in that case I’d appreciate if you could report it on github as well).
I have added a partial camera profile that it sets the manual mode, the maker and the model. Then it works. But 1st now I do no longer have the automatic mode and 2nd I always need a partial camera profile or a lens profile for each camera I can use it with …
However it works that way. But I still think it is an error, as it works w/o dynamic profile just by manually loading partial profiles. I guess, the fields are populated just before the screen appears the 2st time. That would explain why it works in manual mode, but not with dynamic profiles.
@ChasingShadows I’m a bit confused, I think I don’t understand Can you send me both the partial profile and the dynamic rule you are using? Thanks!
I’m seeing the same issue as @vilmantasr, no lensfun database, on a Win10 laptop. Common cameras and lenses, that are in the database, clean installation, the RT directory in AppData removed.
Nothing is available in manual mode. Multiple lensfun databases installed (3 x Gimp, 2 x darktable, Photivo, UFRaw …) in respective directories in Program Files, plus Photivo has it also in AppData. This is obviously crowded …
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:
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).