[CREATE] Lens correction database

[Pablo d'Angelo]

Yuval Levy wrote:

> Hi Pablo,
> 
> Pablo d'Angelo wrote:
> 
> For the identification data, I am not sure about the approach below. It
> looks to me as a mix of input to the database and output as used by the
> applications.

No, it is for the output only.

 > In the end what is required is a set of parameters for
> each combination of camera/lens/focal-length/aperture, and a combination
> of information to identify the camera/lens/focal-length/aperture used.
> 
> Identification by EXIF or other automated mean is unlikely to be
> reliable enough in our lifetime. E.g. when an adapter is used in front
> of the lens (wide-angle and tele-adapter for point&shoot digitals);
> between lens and camera (e.g. the Novoflex adapter to connect Nikon
> lenses to Canon bodies); when the image is a scanned negative or slide;
> when the manufacturer changed production process / specs w/o changing
> the EXIF.

This are all very marginal use cases. I assume most images on this planet 
are captured with point and shoot cameras, or usual lenses without adapters.

Therefore it is very important to have a scheme that works well for the 90% 
case. Obviously there will be a manual override for the other 10%.

Most cameras store more or less useful meta data that can be used to 
identify the camera and the used lens. Meta data that is potentially useful 
for determining the type of lens or camera and SHOULD be stored in the 
database. Such hints are the max aperture, focal length range, and different 
lens id's stored by various cameras. There will be ambiguities and missing 
meta data, so the user will always need the choice to override the automatic 
selection.

But I believe that if the user specifies which lenses he has (for example in 
the preferences), most of the ambiguities will can be solved automatically. 
Most people probably don't have two lenses with exactly the same focal 
length range and max aperture, for example.

> I will assume that the XML below is for the OUTPUT of the system, i.e.
> the input that tools like Krita will use when processing (possibly
> automatically) input images. My comments between the lines.

Yes, this is the information required for using the database. However, also 
the input should be available under the same license as the correction 
database itself.

>> Camera description:
>> ===================
>>
>> <!-- name of the camera, crop factor -->
>> <camera make="Canon" name="EOS 300D" cropfactor="1.6">
>>
>>   <!-- exif data required for recognition of the camera -->
>>   <exif make="Canon" model="Canon EOS 300D DIGITAL"/>
>>
>>   <!-- mount of the camera (used to identify matching lenses) -->
>>   <mount>canonSLR</mount>
>>   <mount>canonEfsSLR</mount>
>>   <mount>genericSLR</mount>
>>
>>   <!-- a free from text field for misc annotations -->
>>   <comment>Any annotation</comment>
>> </camera>
> 
> IIRC, the only relevant factor in terms of camera is the sensor size,
> i.e. the cropping factor?

This is the most important one. The mount is also quite important, since I 
guess > 90% of the people do not use adapter with their cameras. An option 
to override that pre-selection will obviously be available.

For some unknown cameras, the crop factor can be read from the EXIF data, 
while for others it can't. The database should include generic cameras with
crop factor 1, 1.5 and 1.6, so that the user can select one of those.

>> Description of a lens:
>> ======================
>>
>> <lens name="Canon EF-S 10-22mm f/3.5-4.5 USM"
>>        minfocallength="10" maxfocallength="22"
>>        maxaperture="3.5"
>>        <!-- type of lens, either rectilinear or fisheye -->
>>        type="rectilinear">
>>
>>   <!-- person calibrating the lens -->
>>   <author>Author</author>
> 
> IMO the author is something to keep internally in the database. If
> somebody downloads the whole database (which should be available), he
> will get the original calibration files and all the relevant process
> information (i.e. who calibrated, who verified/rated, etc.) but for all
> practical purpose, this information would only clutter things.

I disagree. This is an important social factor. By keeping this, people can 
build a reputation, and the quality of the calibrations will likely improve. 
How wants to have his name associated with crappy calibrations?

>>   <!-- serial number range (for lenses with same name but different 
>> properties, not required) -->
>>   <serial number="300" min="1" max="1000">
> 
> if only the world would be perfect, this would work. However we can not
> count on clean data to this level of precision. Hence, for the quite
> common situation of a manufacturer changing the characteristics of a
> lens without changing it's name (e.g. Nikon 8mm et al.) the only viable
> solution is to rely on user judgement.

This field is there because the world is not perfect. I don't understand 
your concern?

Because of your argument, the serial number range needs to be stored in the 
database. Doing it in a machine readable way (as opposed to just the lens 
name) might facilitate be useful for later automatic or manual retrival. Its 
a detail that you wanted to include in the comment, but it is better to 
include it in the data structure directly. An application will display the
serial number range, if this information is available.

> I would solve the whole above in something like this (annotated version
> of that same XML below):

Your description if very similar to the one written by me, except that you 
avoided attributes. It is always a question in XML design. However, I see it 
more from a coder perspective, and attributes are more like well defined 
members of a struct, and elements are for free text and substructures.

I'm currently working on an improved xml document based on the discussion 
here. I hope to post it this evening. Below are some comments on your
suggestions.

> <lens>
>   <entry>1234</entry>
>   <description>Nikkor 8mm</description>
>   <detail>this is applicable to the last batch of these Nikkor lenses
>           from serial number 12345678 up</detail>
>   <camera>Canon EOS 350D</camera>
>   <camera>Canon Digital Rebel XT</camera>
>   <camera>Canon Kiss n Digital</camera>
>   <crop factor>1.6</crop factor>
>   <min_fl>8</min_fl>
>   <max_fl>8</max_fl>
>   <max_f>2.8</max_f>
>   <type>ortographic</type>
>   <status>1</status>
>   <calibration>
>     <focal length="8">
>       ... same things as radial distortion and tCA from below
>       <aperture f="2.8">
>         .. same things as below under calibration
>       </aperture>
>     </focal>
>   </calibration>
> </lens>
> 
> 
> ANNOTATED VERSION
> 
> <lens>
> 
>   <entry>1234</entry>
> 
> /* unique entry ID to identify the specific lens. Can be used to be
> stored in preferences so that user need not disambiguate each time */
> 
>   <description>Nikkor 8mm</description>
> 
> /* this description might be ambiguous, e.g. when there are multiple
> entries. They will appear ambigous also in a drop-down menu and will
> force the user to identify which of the many variations of the same
> lense he has. */

Hmm, I'd like to include some more short information in the user-visible 
name, like which version it is, and the max aperture etc. This will be more 
efficient, because the user can has more information about the lens he is 
about to select without having to check the description of each variation.

>   <detail>this is applicable to the last batch of these Nikkor lenses
>           from serial number 12345678 up</detail>
> 
> /* the detail will be instrumental to disambiguate. Ideally it will
> appear as a pop up when hovering over the lens names in the drop down */

I'm not sure if this is possible with all GUI toolkits.

>   <camera>Canon EOS 350D</camera>
>   <camera>Canon Digital Rebel XT</camera>
>   <camera>Canon Kiss n Digital</camera>
> 
> /* one lens can be associated with many cameras, e.g. like above when
> the same camera is marketed under different names; or when cameras have
> same crop and thus same correction parameters. Ideally the user
> selection process when using the database will be camera first and then
> a list of lenses (descriptions) associated with it. */

Storing the mount is more scalable than storing the camera name here. I 
think we can make the assumption that the lenses behave similar on cameras 
with the same mount. Otherwise we would have to update the whole database as 
soon as the 40D becomes available etc.

>   <crop factor>1.6</crop factor>
> 
> /* most relevant information about the camera. can be helpful if the
> user has a camera not yet listed in the database. */

actually, this information is already stored in the camera entry. For 
unknown cameras, generic camera entries will be available.
What is important is the crop factor for which this lens has been 
calibrated. For example, a calibration done with a full frame camera can be 
used for correcting an image captured with a 1.6 crop camera, but not the 
other way round.

ciao
   Pablo