Am 17.03.2013 13:28, schrieb Sebastian Kraft:
> Am 17.03.2013 12:22, schrieb Ulrich Pegelow:
>>>
>>> The score field in the lens search result struct is documented in the
>>> manual. So I think it is supposed to be used. The only missing thing is
>>> a specification of the value range.
>>>
>>> Why not giving it a try? Maybe with a conservative threshold first... It
>>> can only improve the automagic matching in Darktable.
>>>
>>
>> First feedback: doesn't work very well, unfortunately. The biggest
>> problems are the gaps in lensfun's database when it comes to recent lenses.
>>
>> Example: my Canon EF 70-200 2.8L II is not in. The loose search will
>> return the correction parameters of the Mark I version of that lens with
>> a score of 96. Both lenses are quite different!
>>
>> I could increase the score threshold to 100, but then what does it mean
>> concerning the original issue of the Tamron 17-50 and its different names?
>>
> 
> I see... that won't work with the Canon lenses only differing by II or 
> III :(
> 
> Ok, what we have so far:
> 
> Strict search won't work as lens names are not standardized and differ 
> in some parts of the name. See Tamron 17-50.
> 
> Fuzzy search won't work as lens names sometimes only differ by one last 
> letter. See Canon 70-200 I...III
> 
> So none of the search algorithms works reliably and even modifying the 
> algorithms would not help. It's just a conflict of requirements. Or do 
> you see any possible improvements in the algorithms?

Maybe such "blockers" could be identified?

Example:
Tamron SP AF 17-50mm F2.8 XR Di II
Tamron AF 17-50mm F2.8 XR Di-II LD (Model A16)

Matches: Tamron, AF, 17-50mm, F2.8, XR, DI
Matches Not: SP, LD, Model, A16
Potential Blockers: II (matched)

Rating: Same focal length and aperture, same vendor, one potential
blocker value matched and 3 of 7 additonal text fields match. Looks like
if this is the same lens ;)

For the canon example there would be a blocking missmatch because the
found revision number did not match (I vs II or III)

This approach would require some testing/digging in the databases to
identify robust heuristics/blocking rules.

Regards,
Markus

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
_______________________________________________
darktable-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/darktable-devel

Reply via email to