Project

General

Profile

Bug #10239

Olympus lenses not recognized for lensfun functionality

Added by Jan Niklas Fingerle over 5 years ago. Updated over 5 years ago.

Status:
Fixed
Priority:
Low
Assignee:
-
Category:
-
Start date:
12/18/2014
Due date:
% Done:

100%

Estimated time:
Affected Version:
1.6.0
System:
Ubuntu
bitness:
64-bit
hardware architecture:
amd64/x86

Description

This is a regression of #9794 introduced in https://github.com/darktable-org/darktable/commit/09bac2436d5cbbc13e71ad8649394bada005a53f

I'm not sure, that LF_VERSION is available at this point. Regardless, there is no point in this check since everything works perfectly fine with lensfun 0.2.8 and even if it were not the case, it could easily be fixed by updating the xml data files. On the other hand the old behaviour is just broken for Four Third cameras and lenses (not MFT). The old behaviour reads some generic value for thoses lenses that sometimes matches more than one lens in real life. The new behaviour will always yield a value specific to the lens. This doesn't have anything to do with lensfun at all, it's only about how the lens data is written by Olympus FT cameras.

It cannot break more with the new behaviour, even if lensfun wouldn't work. In that case the new behaviour would at least provide us with a specific string to match in rules. The old behaviour is broken in that respect as well.

Please roll back the bug introduced in https://github.com/darktable-org/darktable/commit/09bac2436d5cbbc13e71ad8649394bada005a53f


Related issues

Related to darktable - Bug #10284: Leica DG Summilux 15mm f/1.7 lens is no longer displayed in DTs image information (left side of lighttable) - just some numbers appearFixed01/13/2015

History

#2 Updated by Pascal de Bruijn over 5 years ago

  • Target version set to Candidate for next patch release

Would you mind summarizing the issue with a concrete example case?

#3 Updated by Jan Niklas Fingerle over 5 years ago

Ok, I'll try:

For those two lines of code that I think should be removed there are four cases thinkable:

(1) Images and installations where lenses are recognized fine with or without those lines.
(2) Images and installations where lenses aren't recognized correctly with or without those lines.
(3) Images and installations where lenses are only recognized correctly with those lines.
(4) Images and installations where lenses are only recognized correctly without those lines.

(1) and (2) don't matter, since those two lines of code don't make a difference.

I cannot imagine any scenario for (3). Therefore I cannot give an example,

An example for (4) would be the raw found at https://www.dropbox.com/s/4wv5yuznt3qegvr/P9221384.ORF?dl=0 This will not be recognized for lens correction (? .. Objektivkorrektur in the german translation) with the current stable packages for ubuntu LTS (on Linux Mint), but it will be recognized when using a self compiled tar ball of darktable 1.6.0 with those two lines removed and no other packages changed or updated (i.e. with the same version of lensfun). (You have to remove and re-import the image for this to take effect.)

tl;dr: I know cases where removing those two lines helps (example given above) and I cannot imagine cases where it would make things worse.

#4 Updated by Pascal de Bruijn over 5 years ago

  • % Done changed from 0 to 100
  • Status changed from New to Fixed

Ah!

Master:
https://github.com/darktable-org/darktable/commit/09ea65d7c041f6f6a0cda719c115d77c21570dac

darktable-1.6.x:
https://github.com/darktable-org/darktable/commit/0b81e29be3d23ba10dc94c66db2d1be2cd7cc58a

So this should be just in time for 1.6.1. Thanks!

Small sidenote though, my PPA for 14.04LTS actually has the lensfun 0.3.0 database backported into the 0.2.8 package, so users will benefit from the lens naming cleanups, with little risk of library regression.

#5 Updated by Jan Niklas Fingerle over 5 years ago

Thanks :-)

#6 Updated by Michael Born over 5 years ago

This commit breaks the detection of my Leica Summilux lens.
Please, see http://www.darktable.org/redmine/issues/10284

#7 Updated by Roman Lebedev over 5 years ago

  • Related to Bug #10284: Leica DG Summilux 15mm f/1.7 lens is no longer displayed in DTs image information (left side of lighttable) - just some numbers appear added

#8 Updated by Luis Florit over 5 years ago

Actually, I think it didn't fix the Olympus and Panasonic lenses problem either?
DT was working perfectly for my lenses, but since the last updates it is not detecting them anymore, showing crazy numbers for lenstype, and Darktable accepting them as lens model (darktable-1.6.1, lensfun-0.3.0-4, exiv2-0.23-5). This is the output of 'exiv2 -pt':

Exif.OlympusEq.LensType Byte 6 0 0 25 16 0 0
Exif.OlympusEq.LensSerialNumber Ascii 32 AC5256634
Exif.OlympusEq.LensModel Ascii 32 OLYMPUS M.12-40mm F2.8
Exif.OlympusEq.LensFirmwareVersion Long 1 4114
Exif.OlympusEq.LensProperties Short 1 49472
Exif.Photo.LensSpecification Rational 4 12/1 40/1 28/10 28/10
Exif.Photo.LensModel Ascii 32 OLYMPUS M.12-40mm F2.8

Exif.OlympusEq.LensType Byte 6 2 0 9 16 0 16
Exif.OlympusEq.LensSerialNumber Ascii 32 13091000840
Exif.OlympusEq.LensModel Ascii 32 LUMIX G VARIO 100-300/F4.0-5.6
Exif.OlympusEq.LensFirmwareVersion Long 1 4608
Exif.OlympusEq.LensProperties Short 1 49728
Exif.Photo.LensSpecification Rational 4 100/1 300/1 40/10 56/10
Exif.Photo.LensModel Ascii 32 LUMIX G VARIO 100-300/F4.0-5.6

#9 Updated by Jan Niklas Fingerle over 5 years ago

Hi,

please see the discussion at http://www.darktable.org/redmine/issues/10284

Actually, I think it didn't fix the Olympus and Panasonic lenses problem either?

It did fix those problems, but with side effects. The old behaviour was to give LensModel, which works for some cases, but can never work for all cases, since there are different lenses that yield the same LensModel String in FT cases. To achieve this, you have to use the LensType, which makes it possible to distinguish those as well. The weird numbers you are seeing are the undecoded LensType. You see this, because your lenses aren't known to the exiv2 database.

The proposed change in the bug report mentioned above therefore is to use the LensType where it is known and use the LensModel as fallback.

Also available in: Atom PDF

Go to top