Menu
▾
▴
#41 Mention LF_NO_DATABASE in 0.3.2 release notes
The addition of LF_NO_DATABASE broke part of my code (which again would have suggested at least a minor version change IMO ;)). What I do in my python wrapper is to load any custom db files and then also the global ones (if not disabled by a flag). Previously, when global ones do not exist, there would be no error (code 0), but now it is an error, so I have to handle it etc. Just saying, this different error code behavior should be mentioned in the release notes. I will see the problem anyway in my automated builds/tests when preparing to jump to a new lensfun version, but still.
Yes that was missing in the release notes, sorry for that. However, I am not aware how this would cause problems as everything should be backwards compatible...
Currently database loading should be done by using the lfDatabase::Load() command without any parameters. In this case lensfun will check and read the correct database folders. The other functions exist and may work, but are not intended for public usage. Now you might ask why it is not declared private :) Well, unfortunately the whole API was not purely object oriented C++ since its beginning and we did not find the time for a complete redesign :/
Haha! Those "private" database functions are extremely useful! I think they should be part of the public api. For example, I wrote a software that stored distortion profiles in a database and then invoked lensfun with an on-the-fly constructed XML string to apply the correction. How else would I do that without diving deep into the lensfun API and construct all relevant objects etc. manually? I also used the function for loading a single xml file in my python wrapper for Windows and Mac since I bundle the database files myself in some random place (not "global"), so this was the obvious thing to do, but maybe there's a way to tell lensfun where the global db folder is prior to invoking load(). But still, I see these more granular functions as extremely useful and without them lensfun would just be less flexible and be a pain to use for my use cases.
If these functions are of any use we should improve them and make them official or extend the API in order to add the functionality you need. The way you currently use lensfun seems to be quite dangerous to me and may break with every new release.
I admit that lensfuns code base and API is messy in many aspects, but instead of inventing work arounds the best help would be to fix lensfun or to at least report everything. We will then do our best to improve things where we can with our limited time.
BTW: if you want to add new calibrations data on the fly it is best to create an lfLens object and add the calibration data with the respective functions. Then you can apply the corrections with an lfModifier. Can you show me an example code where I can see how you would like to use lensfun and what functions are missing?
EDIT: In particular the loading of database files on win and mac is problematic as we do not have a reliable default location. As we do not use win/mac frequently any suggestions how we could improve loading on non linux OS is highly appreciated.
Last edit: seebk 2015-12-07
Well, the fix to the Win/Mac workaround in my library would be that lfDatabase::Load() supports a database folder path as argument (or similar) since my application will know where the database files are, and I think this is true for any application built for Win/Mac that uses lensfun. This would be far better than me having to scan the directory and load each db file manually.
I thought about my xml-string-reading and I agree that it makes more sense to create an lfLens object directly. I'll see if I can easily implement that. The xml string was just a very easy way to do it, especially since you could copy paste from the existing xml files. But no, it's not the right way. You're right.
Is the lfDatabase::LoadDirectory() function suitable for the purpose to load files from an arbitrary directory?
I guess so, but this function does not have a C equivalent currently, right?
Oh, you are right. The C wrapper was missing. I have now added lf_db_load_directory() and also tried to clarify the documentation.
Ok looks good to me. But since the C wrapper is new, please try not to break the lf_db_load_file() function in the immediate future.