Now that I think about it, it might be okay to not have coverage of Pentax and Nikon SLRs as long as the mirrorless mounts that actually require correction get coverage, which they do; Nikon Z does it properly and so do all the others I’ve checked. I totally forgot about that.
Compacts are another question; you identify it by the camera, I guess, rather than the lens?
I’m picking at the exiv2 code, found this:
class Nikon3MakerNote {
public:
...
//! Print lens name
static std::ostream& printLensId(std::ostream& os, const Value& value, const ExifData* metadata, const std::string& group);
in nikonmn_int.hpp/cpp, but it isn’t exposed in the .hpp files of the API. Looking for how this class is used in other classes… it is the class that encases all the lookup tables for the Nikon lenses; haven’t inspected the Pentax classes, but assume something similar is done there.
That’s bottom-up; top-down from exiv2.cpp yielded an Actions class from which a task is created, but I haven’t dug deeper than that. C++ isn’t my “first” language, so between that and my old-dude dementia I’m having to work hard to find the goezintas/comesoutas…
Still, I think there’s still going to be the need for a manual lens lookup…
Yes, I do plan on having manual lens lookup. But I don’t have to worry about it not being automatic, because distortion and vignetting correction is more or less optional for SLR lenses, and Auto CA correct handles chromatic aberration.
Oooookay, took a bit of digging, but here’s how you access the lens nomenclature:
// nikonlensprint.cpp
// Sample program to print the Nikon lens nomenclature of a NEF file
// Compile: g++ -o nikonlensprint nikonlensprint.cpp -lexiv2
// Usage: ./nikonlensid DSC_xxxx.NEF
#include <exiv2/exiv2.hpp>
#include <cassert>
int main(int argc, char* const argv[])
{
if (argc != 2) {
std::cout << "Usage: " << argv[0] << " file\n";
return 1;
}
Exiv2::Image::AutoPtr image = Exiv2::ImageFactory::open(argv[1]);
assert(image.get() != 0);
image->readMetadata();
Exiv2::ExifData &exifData = image->exifData();
if (exifData.empty()) {
std::string error(argv[1]);
printf(": No Exif data found in the file\n");
exit(1);
}
Exiv2::Exifdatum metadatum = exifData["Exif.NikonLd3.LensIDNumber"];
std::string lensNomenclature = metadatum.print(&image->exifData()); //passing the image to the print method exposes the lens lookup print...
std::cout << lensNomenclature << std::endl;
}
Fourth-to-last line is the money shot; passing the image to the print method exposes the lens nomenclature lookup. Note the previous line finds the relevant Nikon tag; use exiv2 to determine the equivalent Pentax flag.
Now I need a beer or three…
Thanks to your discovery, I now have lens identification working.
https://github.com/CarVac/filmulator-gui/blob/lensfun/filmulator-gui/database/exifFunctions.cpp#L195
I also integrated lensfun into both my qmake and cmake builds.
Next is to actually try to search lensfun for the lenses (and bodies) I have identified.
so, just toString() did the trick?
I had to convert the actual exifdatum to a string to check that its length was nonzero before passing the exifdata to the print method, because it would segfault if the tag was nonexistent in that raw file.
Other than that, it was pretty simple. Panasonic I just convert the tag directly to a string, and for Nikon and Pentax I used the method you found.
This is the first time I’ve heard of Filmulator. I went to the GitHub page for more info but the question that is still outstanding is: is Filmulator intended to replace darktable and the like or compliment them?
It’s a standalone editor with basic library management that does 95% of what I need in a very streamlined manner. But since they’re all free, you can certainly use them to complement one another.
Sometimes I use RawTherapee or GIMP to perform some operations on the output from Filmulator that I haven’t yet included (or won’t include), but that’s not often for my style of shooting.
I’ve decided that in order to streamline the code for lens selection and such, I’m not going to use Lensfun 3.2 at all, since 3.95+ has multiple possible profiles per lens and I don’t want to have to change this in the future.
Dependency stuff is no big deal, since it’s primarily going to be distributed as an AppImage on Linux, and with libraries included on Windows.
I was working toward that, but the crashes in database lookups compelled me to abandon 0.3.95. That was before solitary confinement; now, I might have some time to track those bugs down.
Okay, now I think I need to co-opt your updating code, or perhaps translate it into Qt so I don’t need quite so many other libraries.
Qt has libcurl and libarchive functions? That’d be handy…
Oh, it doesn’t have those.
I guess I can basically use it intact (after finding the implementations for the strutil.h functions).
the strutil.h file contains the full functions. I did it this way so I could pull the other source files intact into the rawproc tree, where I already have a gimage/strutil.h and strutil.cpp.
gimage/strutil.h is the one that the lensfun update function uses though.
I wonder if I can just replace everything with QStrings and use Qt’s string utilities.
Don’t know why not. split() is a common function; string_format could just be replaced with snprintf(). Or, wait for C++20 to get std::format for split() 
I have had a temporary setback: I discovered today that I forgot to upgrade Ubuntu for long enough that they closed the 19.04 repositories.
Time to do my first reinstall on this computer since 2014.
Does a simple sudo do-release-upgrade not work?
Huh, I didn’t try that. update-manager -d was failing when it couldn’t find the 19.04 repositories, but that seems to be working.