Hallöchen! During the holidays, I started some work on Lensfun which turns out to become quite extensive, so I want to put in on discussion.
The big picture is that we keep the current C/C++ API, and build a new one parallel to it. The new API will be easier to use and to extend. Moreover, I want to change the XML file format. The new Lensfun would not be able to read old XML files. There will be, however, a script which converts old to new. My motivation is that we now know very well which parts of Lensfun are difficult to extend, and how programs use Lensfun typically. Therefore, it makes sense to overhaul Lensfun in one big effort, so that the downstream programs can adapt at their convenience, and further changes can be made without mandatory downsteam changes. The steps are the following (in this order): 1. Add unit tests for the coordinate transformations. 2. Add unique IDs to <camera> and <lens>. 3. Put every model (e.g. ptlens, poly3, tca, vignetting, ...) into classes or at least C++ files of its own. 4. Change the internal coordinate system to "1 = half diagonal of the image sensor". 5. Change the XML file format extensively. 6. Allow internally the usage of calibrations of different crop factors in the same lfModifier. 7. Implement the new API. (Current draft is at https://sourceforge.net/p/lensfun/wiki/lfModifier%20API/) About (3): I'd like to do this because due to (4), we need an additional function for every model that transforms the coefficients so that they match the new coordinate system. Thus, there will be at least a forward callback, a reverse callback, a coefficient transformer, and possibly a postprocessor after the raw data was read from the DB -- for *every* model. And we have a lot of them. For the sake of readability, I'd like to create a file called e.g. "ptlens.cpp" which contains everything for the ptlens model. Or a singleton class instead? About (4): The current internal coordinate system is "1 = half height of the *calibration* sensor". This makes sense if you only support PT-based distortion and TCA models. More critically, you can only use one calibration sensor size for one correction. Therefore, we need a new common coordinate system anyway, and I propose the vignetting coordinate system for the *image* sensor. This moved any ugliness out of Lensfun's core into the model files. About (5): Lensfun offers an API for its DB, so the DB itself is in a way an internal format. Of course, many Lensfun users maintain local XML files, so there will be a tool for converting the current to the new format. Moreover, the current Git DB will be converted into all older versions every night. The changes that I propose are: 1. Assign unique integer IDs to cameras and lenses. All numbers < 1000 are reserved for private/local use. Anything which is not a positive integer (this includes 0) is an invalid ID. (Mount uses its name as ID.) 2. <aperture> is renamed to <f-stop>. 3. Move the <cropfactor> and the <aspect-ratio> element out of <lens> into the <calibration> element as attributes. 4. Introduce a <min-crop-factor> element in <lens> which denotes the maximal image circle the lens can illuminate. This will be used like the old <cropfactor> for filtering matching lenses. 5. Move <real-focal-length> tags as attributes into <distortion>. (Already done.) 6. Collect all <calibration> elements of one lens model in one <lens> entry. 7. Add optional "camera" attribute to <calibration>. Any comments are welcome! Tschö, Torsten. -- Torsten Bronger Jabber ID: torsten.bron...@jabber.rwth-aachen.de ------------------------------------------------------------------------------ _______________________________________________ Lensfun-users mailing list Lensfun-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lensfun-users
