Cannot get Darktable to recognize Lens

This appears to be a problem that could be caused by mismatching identification text for the subject lens.

For example, the metadata from my raw file includes an element called “Lens Model” with a value of “RF24-105mm F4 L IS USM”.

Then the LensFun file named “mil.canon.xml” contains a line with the text that follows:

“<model>RF24-105mm F4 L IS USM</model>”

I deduce this to be the LensFun identity for the subject Lens Model. This looks like a match. However, the lens identity displayed by Darktable is as follows:

DT-LensCorrect

Then there is another metadata element with the string “RF Lens Type Canon RF 24-105mm F4L IS USM” which is similar but NOT quite the same. In that, does NOT match anything I can find.

An obvious question then becomes where did Darktable get the value it is displaying from? However, the important question is how to get Darktable to recognize that LensFun does have data for my lens?

Hi David,

Odd. My lensfun has another name registered (also note position of spaces):

    <model>Canon RF 24-105mm F4L IS USM</model>

If you run exiftool on one of your images, what Lens Model is given?

Have fun!
Claes in Lund, Sweden

AFAIK dt obtains this info via exiv2 and hence it is again about dealing with ~/.exiv2

I am afk right now, hence cannot explain deeper.

I think we need a nice tutorial, which can be linked. Hope @Bruce_Williams would have one :blush:

You already have Exiv2, so use that one to get your lens nr.
$ exiv2 -pt file.CR3

Edit: Forget it, all RF lenses seem to have the same nr 61182.

You wrote the lens in mil-canon.xml is RF24-105mm F4L IS USM. That is wrong. It should be Canon RF 24-105mm F4L IS USM. The discussion here Use official Canon RF lens model names by cytrinox · Pull Request #1442 · lensfun/lensfun · GitHub

1 Like

RF lenses are handled differently by dt because of this 61182 aliasing problem: Try to handle Canon RF lenses differently to legacy ones · darktable-org/darktable@18394dc · GitHub

1 Like

I have some lenses which are recognised incorrectly by DT, but the problem is resolved by manually selecting the appropriate lens from the drop down options.

Which lenses?

One of them is a Sigma lenses on an earlier model pentax. It is available in the list but not correctly selected. Not a huge problem. It just pays to check what lens is selected.

You can try the method in the video. Or upload a sample file here and I can take a look.

The strings I referred to as metadata were obtained using ExifTool. Therefore, the Lens Model obtained from the metadata using ExifTool is “RF24-105mm F4 L IS USM” (within quotes).

I thought it should be possible for me to select a lens from a list but prior to making this post I was unable to figure out how. I thought the down arrows next to the button might be there for that purpose but selecting those did NOT produce a list. After seeing a reply to this post saying it was possible I went hunting again and figured out that selecting the button instead lead to the list.

Interestingly, in the case of RF lenses (i.e., for Canon mirrorless cameras) what appears in the list does match what’s found in LensFun file mil.canon.xml which seems to confirm that the list could have been created using the LensFun supplied data.

What’s odd is that for EF lenses (i.e., for Canon SLR cameras) the LensFun file slr.canon.xml appends the metadata value for Lens Model to the prefix "Canon " (i.e., the prefix is NOT included in the metadata) to obtain a value in the form mentioned (e.g., “Canon RF 24-105mm F4L IS USM”).

Your point about spacing is also interesting. The “F4L” rather than “F4 L” is a difference that appears in the metadata. The former (“F4L”) is what appears in the Makernotes element referred to as “RF Lens Type” rather than the Exif element referred to as “Lens Model” which contains “F4 L”.

Also, when I select the value “RF24-105mm F4 L IS USM” from the list Darktable displays it with a prefix of "Canon, ". The camera brand name “Canon” is the value used as the name of the applicable sub-folder that contains the lens models. This results in a string that is similar to but NOT quite the same as what is displayed in my screenshot where it says “Lens not found”. Therefore, I still haven’t figured out where the value displayed in my screenshot came from.

I am curious about the source of your LensFun data files.

With that said now that I know how to search the list of lens identifiers this is a much less serious problem.

I am curious about the source of your LensFun data files.

Straight from the source :slight_smile:

a) As root, perform

lensfun-update-date

b) as an ordinary user, perform

lensfun-update-date

Addendum: if you post one of your RAWs, I can check how
it behaves on my machine, if you like.

Have fun!
Claes in Lund, Sweden

From the code in the github link posted above.

It really is “Canon RF 24-105mm F4L IS USM” in the latest version of the database (for the last 14 months or so, you can click “View git blame” on that line to see when it came in…).

Btw, the spaces shouldn’t really matter - AFAIK, lensfun database matching is done ignoring the letter case and the spaces, but everything else should match up.

So the dt detected “Canon RF 24-105mm F4 L IS USM” doesn’t match your outdated database entry of “RF24-105mm F4 L IS USM” because of the missing Canon prefix and that is why you get the message.

And lensfun-update-data won’t work on Windows unfortunately, so please search the forum for ways to update your lensfun database on Windows specifically, there are some workarounds available…

Gulp! Is he on Windows???

/Claes

I think he is on windows 7. I dont know what version of darktable.

Yes! My apologies I should have made it clear that I’m using Windows 7 and Darktable 3.8.1.

Also, I do have Linux systems and I could create databases there. However, unless someone has good reason to believe that the current Lensfun database on Linux will work with my Windows version of Lensfun I’d rather NOT experiment.

It will work. Just copy the new mil-canon.xml

Sorry for creeping off on a tangent here, but if you can load the latest version of DT V4.0 on a windows 7 computer I would upgrade as it has some nice improvements. Also, when microsoft pulled the support on Windows 7 I changed a couple of my computers to Linux Mint and really like what was improved speed and performance for me on those computers. I appreciate that not everyone can or wants to switch to linux. I still run mainly windows 10 computers because I have so many programs requiring windows. However, I see in my longer term future a switch to Linux mainstream for me. I would be concerned running a Windows 7 computer if there was any sensitive data on it like banking. That being said, I have instruments at work running on Windows XP, but I don’t allow them to be connected to the internet. Good luck.

1 Like

Hi Peter, thanks for the offer but it is such a non-issue for me to just select the correct lens manually if DT gets it wrong. I hope the original poster’s problem can be sorted. I just put my five cents worth in in case selecting the lens manually was an option for him. Take care.

What I like about Windows is its’ ability to run applications stored on portable USB drives. I do sort of understand that Windows 7 is problematic because software eventually has a way of adapting new capabilities only found in newer versions of Windows. So far very few of a rather sizeable number of programs I use have gone this route which I think has something to do with my like and reliance on open source software. Those developers don’t have much need or desire to migrate to newer versions of the underlying software just for the sake of doing it. Unless it offers something they really need or desire they’d rather spend their time working on their specialty than simple being up to date on Windows.

My method of portable operation allows me to install new versions of most packages (Linux term) without making any alteration to the existing ones that work fine. For example, in the case of Rawtherapee I think I’m up to about 10 different versions where I can choose to run any one of them. This can be useful in photo development because in my workflow I keep track of what version was used to develop any particular photo, Therefore, should I want to do some further development of an old photo I can pick up right where I left off some years ago with the same software.

With that said Darktable is an outlier. While capable of being installed in this manner it runs very poorly on my jump drives (i.e., flash memory). At present it looks to me like this is caused by DT’s library and the fact that jump drives are pretty slow to write to. In my case, I’m only interested in the Darkroom aspect of DT and the library complexity is gross overkill, in my opinion, for what is needed in the Darkroom. If on the other hand you like the Lighttable for organizing your picture files then it probably is useful. As a result, I’ve figured out a way to locate the library on temporary storage and this seems to solve the performance issues. It does have the affect of diminishing portability a bit. In that, should you move to a different computer you either need to create a new library or you get the one that was previously in effect on that machine. Not a problem for me but could be for others. Possibly most others for all I know.

Finally, I’m wedded enough to Windows 7 that I went to quite a bit of trouble a few years ago to build what I think still qualifies as a powerful computer but using the best available components capable of running Windows 7. When this computer dies I’ll have to move on but my portable installations run fine on Windows 10.

Wishful thinking I’m afraid. As it turns out my Linux systems are pretty old and, in my case, running on 32bit machines. I think this seriously limits how up to date I could make them. When I installed Darktable I got Version 2 which I deduced would NOT solve this problem.

On the other hand I’ve had similar problems to this one, in the past, with Rawtherapee. When I went back and researched how I dealt with that I was reminded of a website that has been dealing with this problem for a while and still seems to be staying up-to-date. If you scroll down to the bottom of this page you’ll find downloads for some files that pretty directly address this problem. That version of mil.canon.xml appears to resolve my problem.