Good points. I’ll be reshooting the calibration shots. In the camera, I had mistakenly entered 1090 instead of 1000 mm for the non-CPU lens info. It does seem darktable is sensitive to lens or camera attributes. I’ve made some ‘progress’ in getting corrections applied but there seem to be a whole bunch of inconsistencies or else unexplained behaviors in the lens correction module. E.g. if ‘only vignetting’ is chosen for ‘corrections’, ‘corrections applied’ reports ‘none’ even though some vignetting correction seems to be applied, and the histogram clearly changes shape. The f (stops) and d(istance) parameters in the module show a bunch of other apertures and distances than what are in the lensfun database for the lens, which could simply be darktable inter- and/or extrapolating the given values. I need to start from a clean slate instead of trying to understand idiosyncrasies that are probably due to bad input data. Also slowly familiarizing myself with darktable’s sqlite database.
Then, there’s some debate as to whether the camera (body) applies vignetting correction. Models other than the Z8 and Z9 would only apply that (and distortion and presumably tca) to jpeg but not to raw. The interwebs speaks of the Z8 and Z9 applying that to raw as well, and I checked the camera had vignetting corrections enabled (which I would not want for the calibration shots). I can’t imagine it would apply corrections to a non-CPU lens, and checking exif info doesn’t show any vignetting correction applied on the raw images, fwiw.
Yeah, thanks for pointing that out. I had already noticed arch and gentoo discussions on a packaging error, as well as a fix in something like 0.3.4. The fedora 39 rpm is ~0.3.3, but the version is not necessarily to blame as debian 12 also has ~0.3.3 and lensfun-update-data works fine on debian. I had copied the xml updates from debian to fedora as debian has its own troubles with the Z8, notably in darktable.
I’m (slowly) getting there.