Canon lens handling regression in 0.28.0 #2746
Comments
|
seems to be dependent on camera or lens: Canon 7D: Canon M6: Canon 5DmIV: Canon R6 - EF Lens: Canon R6 - RF Lens: |
|
I've noticed something interesting about the My Canon EOS 100D with 18-55mm kit lens reports: 422576128 in hex is I spotted this while investigating #2138 - is it possible that |
|
A brief follow-up: Yesterday, motivated by CVE-2023-44398, I finally put together a workaround that restored functionality (and then some) for Canon lenses with extenders. To get it to work right, two patches were needed:
My strategy isn't generally applicable because it removes all support for 3rd party EF mount lenses with conflicting ID numbers, but it probably points in the direction of how to resolve the problem. And it is well to note, the problem seems to be a system-level interaction between exiv2 and lensfun. Lensfun patch attached for reference. |
|
Hello all.... I have similar case (gentoo, exiv2-0.28.1) but with Nikon camera and Tamron lense (70/200 2.8 Di G2) it was recognized well in the past, but not anymore. It get listed as ID=226, even well implemented in ~/.exiv2 |
|
BTW gentoo also has a lensfun trouble. Only Version 0.3.4_rc1 is available, which is afaik not the official stable version. With that 0.3.4_rc1, the lensfun-update-data does not work (bug is opened since long time). Donno how much this can be related |
Yes, please. For example |
|
@kmilos per your request :) the current situation: and here the output of -Pkvt and here comes the former scenario (hopefully because I cannot downgrade to exiv2-0.27...... first a screenshot: and here the output of -Pkvt exiv2_former-scenario_Pkvt_20240109.txt I used diff and there is no difference :-( my .exiv2 Tonight I have to focus on other priorities, so please understand, I will be a bit silent, but that topic really bothers me... |
|
Thanks for the data.
As the output between 0.27.x and 0.28.x is the same, and this lens was never in the internal database, can't really say this is the same bug. Now added in #2889 |
|
@kmilos my data "former scenario" was also created with exiv2-0.28.1, just old files, where I did refresh the metadata via darktable at that time. I have dependency blockage and hence cannot downgrade exiv2. That blockage is tricky for some reason, but this would digress here too much. Maybe in the next few days that resolves (as kde currently not fully upgraded due to missing other deps) My major trouble is, that the ~/.exiv2 is not obayed |
Well, that's not very useful here.
Back to square one then. We'll just have to wait until someone w/ "skin in the game" (or otherwise interested) digs into the code and fires up a debugger. |
I am really sorry for this. Currently I do not see a way to downgrade exiv2 in gentoo.
I will amend as soon as any possible |
|
I made it to downgrade exiv-0.27.7 (finally it was my boon mistake why I stuck, I am embarrassed :-( ) The output of "exiv2 ex [File]" looks same but actually the files are not same, when I diff them exiv2-0.28.1 exiv-028_2023-12-29_151301_AG7_9385.exv.zip exiv2-0.28_current_Pkvt_20240109.txt exiv2-0.27.7 exiv-027_2023-12-29_151301_AG7_9385.exv.zip exiv2-0.27_current_Pkvt_20240112.txt So if I do a diff between the two Pkvt outputs, I get: |
|
Thanks @AxelG-DE for your effort, that's more useful. 👍 However, I can't reproduce locally (w/ 0.28.x branch), using either of your I get |
|
Just a wild guess: perhaps Gentoo maintainers (and other distros having similar issues) forgot to add and enable the inih dependency needed for parsing these config files since 0.28.0? Edit: Yep. Didn't forget, but not enabled on Gentoo - @douzzer as well, so please file bug there so it's tracked somewhere. @MStraeten your (Canon only?) case might still be different/unrelated I think. |
|
@kmilos seems you have the right smell from the ebuild (that controls how a package will be built and installed): |
|
Yep. As requested, let's please not discuss the Gentoo problem here any further but move it to their tracker (as Team Exiv2 has nothing to do with how distros package), and leave this to analysing the remaining issue @MStraeten is seeing. |
|
@kmilos I have filed an upstream bug https://bugs.gentoo.org/921937 |
We must have this enabled as it's an important feature. Also, I was wrong before, we just needed to make inih multilib. Bug: Exiv2/exiv2#2746 Closes: https://bugs.gentoo.org/921937 Signed-off-by: Sam James <sam@gentoo.org>
|
I can confirm that this bug also affect myself. Is there change that you'll fix this? |
|
files are shared under CC0 and I am willing to share the original CR2 files under the same license for testing |
|
to answer your early question and make things weirder exiv2 0.28.2 on MacOS however repeat of your test held % exiv2 -pa -g LensType IMG_*.exv search for lens model did not flinch % exiv2 -pa -g LensModel IMG_*.exv On MacOS Preview Inspector Exif tab lenses ids are shown twice, first as "EF...." and then as "Canon EF..." Last, the Metadata Converter app on MacOS correctly identifies the lenses on all cases May I hint that this is a problem with the exiv2 implementation for MacOS? |
I already hinted above |
|
Another idea: regex could also be affected by locale settings? |
|
@joaobrisson My test was also on macOS. Are you on an ARM based mac (like M1-M3 processor) or x86?
@kmilos without a reproducer or actual evidence, just blaming it on |
|
x86 64 bit % exiv2 --version --verbose file $(which exiv2) % otool -L $(which exiv2) % locale |
|
@zisoft is reproducing this on macOS as well |
|
@zisoft also on a x86 mac? |
|
The weird thing for me is, that the command line gives fine results for my Sigma lens but darktable reports To me, it looks like |
Yes, MacBook Pro 2019 (Intel) |
How about locales, are both terminal and darktable running as de_DE for you? |
Good catch! |
|
Yeah! So, for the time being, the workaround seems to be to set the locale to the UK or the US when importing to darktable while waiting for the exiv2 team to come up with some fix |
Sure it is macOS only? |
|
Sure it is macOS only?
Yes, I have tried both DE and PT locales and exiv2 and darktable fail
But when I switched to UK locale, everything worked to perfection
|
|
My questions was, is this a general locale issue in exiv2 on each system, or is this macOS specific? |
|
@hassec |
|
@hassec Maybe swicth to |
|
We had a similar issue in darktable recently: Fix locale for aperture filter. There Solution was to switch locale for |
|
@zisoft Looks like it's better to avoid switching locale altogether, especially from a library... Since exiv2 requires C++17 anyway,
|
Describe the bug
Up to and including 0.27.7-release, I'm able to get correct lens detection for this lens setup in Darktable, by putting this in
~/.exiv2:But with 0.28.0-release, that doesn't work anymore, and the lens is misdetected as Tamron. Nothing else I've tried has worked. In particular, when I tried patching out the conflicting Tamron lenses, Darktable reported "Lens 748 not found" or words to that effect, even though obviously the Canon 748 entry is still there. This is the patch I tried:
The most worrisome syndrome though is that the override entry in
~/.exiv2is being ignored.To Reproduce
I've posted a CR2 with this lens here
(github has a 25MB attachment limit, and doesn't allow CR2 files besides.)
I'm running Darktable 4.4.2 but it wasn't the variable, and it's detecting the lens correctly when built and linked against exiv2-0.27.7.
To see the syndrome, set up the
~/.exiv2above, import the picture into DT, and admire the detected lens ID on the left.Note that you'll see the no-lens-info error in the lens correction tool for both the Canon and Tamron versions of ID 748. I run a Lensfun with the correction data for the Canon setup patched in.
Expected behavior
In the left pane with the image attributes, the lens entry should read
(Which is what it says when built+linked with v0.27.7, and it's what I have in my
~/.exiv2.)Desktop (please complete the following information):
Additional context
I believe this DT issue relates: darktable-org/darktable#14882
The text was updated successfully, but these errors were encountered: