LensSerious 0.1
Lens-correction mathematics as data, not as a library of callbacks
Loading...
Searching...
No Matches
import_lensfun_xml.c File Reference

The periodic rebuild: upstream XML in, one SQLite file out. More...

#include "lensserious_import.h"
#include <stdio.h>
+ Include dependency graph for import_lensfun_xml.c:

Go to the source code of this file.

Functions

int main (int argc, char **argv)
 

Detailed Description

The periodic rebuild: upstream XML in, one SQLite file out.

Command-line front end to ls_import_run().

This tool reads the XML through liblensfun, and that is a deliberate choice worth defending, because at first glance it looks like the one dependency this project exists to remove.

It is not the same dependency. What LensSerious replaces is lensfun's RUNTIME: the ~90 ms XML parse in every session, the process-wide database object, the mutex every lookup serialises on, the callback machinery that can only produce a displacement map on one CPU thread. None of that is here. This is an offline tool, run when upstream publishes new calibrations, on a maintainer's machine or in CI. Its dependencies cost a rendered frame nothing.

What using liblensfun buys is correctness that would otherwise have to be re-earned. The XML is not a straightforward document: a lens's focal and aperture RANGES are usually absent and inferred from its model string by lfLens::GuessParameters(), and those ranges feed the vignetting interpolation's distance metric – get them wrong and every vignetting lookup on that lens is silently off. Reimplementing that heuristic blind, against 1562 lenses, is a large surface of quiet errors. Reading through the library that already does it means the database contains, by construction, exactly what lensfun itself would have computed. tests/parity_db.c then asserts that end to end.

The exit is open: nothing in the schema or in lensserious_db.c knows liblensfun exists. When a native XML reader is written it replaces this file alone, and the parity test is already there to hold it to the same standard.

The rebuild contract

The database is written to a temporary file beside the target and renamed into place. Readers open with immutable=1 and take no locks (see lensserious_db.h); that promise only holds if a live file is never edited. rename(2) is atomic within a filesystem, so a reader gets one whole version or the other, and a reader that already had the old file open keeps reading the inode it opened.

The conversion itself is in src/lensserious_import.c, because this is not its only caller: a consumer shipping the database also has to be able to rebuild it on a user's machine, against that machine's own lensfun installation and their own profiles. Both go through the same function.

Definition in file import_lensfun_xml.c.

Function Documentation

◆ main()

int main ( int argc,
char ** argv )

Definition at line 22 of file import_lensfun_xml.c.

References ls_import_run().