Thanks. Seems a bug in exiv2, when decoding the Exif.CanonCs.LensType tag. Darktable (also based on exiv2) shows the same info FYI
Understood, thank you.
Can you report the bug or shall I?
B.
I think it would be better if you do it, since you have the equipment, in case the exiv2 guys need more samples/tests to figure out what is going on…
Understood, will do. I’ll report back. Thank you.
Edit: Reported here: Lens ID mismatch: Canon RF 100-500 has 2x extender added to ID · Issue #2202 · Exiv2/exiv2 · GitHub
Edit: A previous similar bug was reported and iiuc the source code shows ALL RF lenses having the same internal ID in Exiv2:
I don’t know if ART gets partial lens ID from only Exiv2 or partially from its own parsing of EXIF data, but sometimes the lens detail is correct, sometimes not.
B.
I believe the “LensID” is just a number and that number is then mapped onto the lens name. Since the teleconverter doesn’t modify the number it is impossible to discern what is using the teleconverter and what isn’t.
1 Like
This is definitely an exiv2 bug. ART gets the info via exiv2::lensName, if exiv2 can’t be sure about LensID, it should use something else. Now, I can certainly think of working around that, but this doesn’t mean it’s not a bug 
2 Likes
ART (so Exiv2) sometimes gets it wrong, sometimes right, but that may be a false +ve. I’ll try with other lenses…
I have pushed a possible workaround. Can you please check that it works as intended? Thanks!
Where is the latest? The nightly builds folder has one built on 04/04…
the latest is always in git master – you need to build from source. The only binaries I’m providing are for releases, sorry
1 Like
This.
lensName() is just a convenience function that works most of the time for vanilla cases. The internal exiv2 (and exiftool btw) ID number to string lookup databases are mostly guesswork unfortunately and don’t/can’t really handle ID clashes.
If you’re aware of the exceptions to these simple mappings, you’ll need to dig through the Exif and MakerNote data yourself to create a better mapping (i.e. try to figure out via some other tag if a teleconverter has been used). For example, in dt there are many exceptions in lens identification, and Canon ones (like this case) are still not covered perfectly…
Thank all the camera and lens vendors for having (or have had) a custom lens identification and metadata storage scheme. For example, only recently have some of them started using the standard Exif.Photo.LensModel and Exif.Photo.LensMake as expected.
Thanks for the explanation. I understand the issue, but my opinion is that, in principle, what you describe should be done by exiv2 inside the implementation of lensName. Otherwise, they should deprecate the function or at least warn about its limitations. I see no mention of this in the API docs though.
This is the principle. Then, in practice, I’m already adding exceptions and workarounds when people report them…
Patches are always welcome.
Thanks! I’ll keep that in mind (I don’t understand the hostility though)
I’m sorry if you took it that way. Exiv2 does genuinely need help, and can’t be realistically expected to deal w/ this lens identification shenanigans “perfectly” on everyone’s behalf.
Just lobbing “exiv2 bugs” over when it comes to lens identification isn’t necessarily always constructive (hope you can see that perspective as well).
Understood, but my sw building days are over I can wait for the next release, whenever. TVM.
Alright, I’m glad this was just a simple misunderstanding then.
Btw, reading the most recent comment to the the github issue opened by @BarryThomas, it seems the problem might already have been fixed in the current master.
When it comes to making better info in certain Canon MakerNote tags available, yes, but not sure it’ll address the simplistic lensName() assumptions…