Lens correction database

[Pablo d'Angelo]

Hi together

Some people who have attended my talk about hugin at the LGM might remember
that I proposed to build a database of lens correction coefficients, that
can be used by open source software (such as ufraw, gimp, krita, digikam,
f-spot, etc) to automatically correct for lens "defects" such as lens
distortion, vignetting and even transverse chromatic abberation.

The slides for my LGM talk are available at:
http://hugin.sf.net/tech/LGM_2007.pdf

At least the Krita people are interested in such functionality:
http://www.valdyas.org/fading/index.cgi/2007/05/08#hugin

I plan to write a lightweight C library that contain the main pieces of code
required to apply the corrections and use the proposed database.


Current situation:

Several databases and associated programs for correcting lens defects exist.

For example PTLens uses a database with lens distortions coefficients.
Unfortunately, Its author, Thomas Niemann has decided to close and encrypt
the underlaying database a bit more than one year ago, shortly after I wrote
"fulla", a command line tool to correct lens distortion. fulla can use the
old, unencrypted PTLens database and correct distortions in images
automatically. Note that PTLens requires manual user interaction for other
corrections (vignetting, chromatic abberation).
http://epaperpress.com/ptlens/

In a sense the proposed database is a free alternative to the PTLens
database, but additionally can include coefficients for automatic correction
of vignetting and chromatic abberations.

DxO is a commercial software that can correct the mentioned defects and even
more. Obviously their database and correction methods are not available.
http://www.dxo.com


Proposed solution:
==================

Before that can happen, we need to agree on a database format that can
include all required parameters. This specifically includes:

During the panorama stitching process, hugin is required to correct these
distortions, and can thus be used for estimation of the calibration parameters.

The idea is that people who want to correct their lens take some test shots,
and use hugin to estimate the required calibration parameters. These are
then sent (hugin projects and original images) to a lens database
coordinator, where they are checked for plausibility and incorporated into
the database.


Scope of database:

1. Distortion correction:
radial distortion, same as PTLens, 3 parameter radial polynmial, described
in detail at: http://wiki.panotools.org/Lens_correction_model
Varies mainly with focal length. Parameters can be estimated at several
focal lengths and interpolated in between. Each focal length requires a
single image for calibration.

2. Vignetting correction:
radial correction, radial vignetting correction by division:
I = I / (1 + b*r^2 + c*r^4 + d*r^6)
The parameters vary with both focal length and aperture.
Each focal length and aperture setting require 2 or 3 images for
calibration.

3. Chromatic abberations:
Individual distortion correction of red and blue channel, parameters
can be estimated using hugin (more work than the other approaches), or by
trial and error. Most lenses require just a single scaling factor.
Mainly depends on focal length.

Instructions for estimating the respective parameters with hugin are in
the works.

Who would be interested in using and building such a database?

License:

What kind of license should be used (for the code and more important, the
database)? A GPL like license to restrict usage to open source software or a
LGPL like license? Or a non-commercial license? Can code licences be applied
to databases?



Database (XML) layout:

For each camera and lens, a single entry would be required.
Note that my XML skills are seriously lacking, so any comments
with respect to a different xml syntax are appreciated.

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>


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>

  <!-- mount(s) of a lens (ie. the type of cameras it can be mounted on) -->
  <mount>canonEfsSLR</mount>

  <!-- a rating (quality control passed or not) -->
  <rating>1</rating>

  <!-- serial number range (for lenses with same name but different
properties, not required) -->
  <serial number="300" min="1" max="1000">

  <!-- arbitrary user comment -->
  <comment></comment>

  <!-- correction coefficients for each focal length
  <calibration focallength="10">

      <!-- radial distortion correction, as in PTLens -->
      <distortion a="0.02" b="-0.012" c="0">
      <!-- transverse chromatic abberation correction -->
      <tcaRed a="0" b="0" c="0" d="0">
      <tcaBlue a="0" b="0" c="0" d="0">


      <!-- aperture specific calibration values (vignetting) -->
      <calibration aperture="3.5">
        <vignetting b="-0.1" c="-0.2 d="0">
      </calibration>

      <calibration aperture="8">
        <vignetting b="-0.1" c="-0.2 d="-0.3">
      </calibration>

      <calibration aperture="22">
        <vignetting b="-0.1" c="-0.2 d="0">
      </calibration>
  </calibration>

  <calibration focallength="14">
      <distortion a="0.003" b="-0.001" c="0">
      <tcaRed a="0" b="0" c="0" d="0">
      <tcaBlue a="0" b="0" c="0" d="0">

      <calibration aperture="4">
        <vignetting b="-0.1" c="-0.2 d="0">
      </calibration>
      <calibration aperture="8">
        <vignetting b="-0.1" c="-0.2 d="-0.3">
      </calibration>
      <calibration aperture="22">
        <vignetting b="-0.1" c="-0.2 d="0">
      </calibration>
  </calibration>
  <calibration focallength="22">
      <!-- some more data -->
  </calibration>

</lens>


Any feedback appreciated. Please continue discussion on the CREATE mailing list.

ciao
   Pablo

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@...
To unsubscribe from this group, send email to hugin-ptx-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---

[JD SMITH-8]

Very good idea, Pablo.  With some suitable averaging, multiple inputs
could be used to beat down the systematics which no doubt vary based on
setup and shooting technique.

> Scope of database:
>
> 1. Distortion correction:
> radial distortion, same as PTLens, 3 parameter radial polynmial, described
> in detail at: http://wiki.panotools.org/Lens_correction_model
> Varies mainly with focal length. Parameters can be estimated at several
> focal lengths and interpolated in between. Each focal length requires a
> single image for calibration.
>
> 2. Vignetting correction:
> radial correction, radial vignetting correction by division:
> I = I / (1 + b*r^2 + c*r^4 + d*r^6)
> The parameters vary with both focal length and aperture.
> Each focal length and aperture setting require 2 or 3 images for
> calibration.

Aren't there 2 other parameters, center of correction, for each of these
(separately) as well?  Or are these assumed to vary by camera?

JD



--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@...
To unsubscribe from this group, send email to hugin-ptx-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---

[Pablo d'Angelo]

Hi JD,

>> 2. Vignetting correction:
>> radial correction, radial vignetting correction by division:
>> I = I / (1 + b*r^2 + c*r^4 + d*r^6)
>> The parameters vary with both focal length and aperture.
>> Each focal length and aperture setting require 2 or 3 images for
>> calibration.
>
> Aren't there 2 other parameters, center of correction, for each of these
> (separately) as well?  Or are these assumed to vary by camera?

Hmm, we still have to check that. I remember reading some papers where the
principal point (shift of the perspective center) changed with the camera
orientation. More experiments (measurements with multiple similar cameras)
are needed to decide if including these parameters makes sense.

ciao
   Pablo

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@...
To unsubscribe from this group, send email to hugin-ptx-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---

[Alexandre Prokoudine]

2007/5/11, Pablo d'Angelo wrote:

> Hmm, we still have to check that. I remember reading some papers where the
> principal point (shift of the perspective center) changed with the camera
> orientation. More experiments (measurements with multiple similar cameras)
> are needed to decide if including these parameters makes sense.

btw, should we probably get Robert Rottmerhusen [1] involved?

[1] http://rottmerhusen.com/objektives/lensid/nikkor.html

Alexandre

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@...
To unsubscribe from this group, send email to hugin-ptx-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---

[Pablo d'Angelo]

Ted Gould schrieb:

> On Fri, 2007-05-11 at 00:48 +0200, Pablo d'Angelo wrote:
>> The idea is that people who want to correct their lens take some test shots,
>> and use hugin to estimate the required calibration parameters. These are
>> then sent (hugin projects and original images) to a lens database
>> coordinator, where they are checked for plausibility and incorporated into
>> the database.
>
> Is there anyway to use the resolution tests from DP Review site for
> this?  Seems like some good data that might help.

The problem is that the distortion parameters change with the focus. They
are different for short distance (as in the test shots) and the far distance
(where the camera is usually used).

If calibrations at both close and far distance are available, they could be
distinguished either by comments in the lens section, by a separate field in
the header.

Here are some pages about how to calibrate the distortion coefficients:
http://www.erik-krause.de/verzeichnung/distort_en.htm
http://wiki.panotools.org/Lens_correction_model#Determine_lens_correction

ciao
   Pablo

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@...
To unsubscribe from this group, send email to hugin-ptx-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---

On Fri, 11 May 2007, Pablo d'Angelo wrote:

[...]


> The problem is that the distortion parameters change with the focus. They
> are different for short distance (as in the test shots) and the far distance
> (where the camera is usually used).

Unfortunately, not all cameras store the focus distance in their
exif. For example for Canon EOS (20D ,300D, 350D, 5D, Digital Rebel XT,
1D, 1Ds) see,
  http://photo.net/bboard/q-and-a-fetch-msg?msg_id=00F5eG
the Makernote 0x0004: FocusDistanceUpper and FocusDistanceLower
always show 0.

Maybe it is still hidden somewhere in the  makernote ...

Arnd

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@...
To unsubscribe from this group, send email to hugin-ptx-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---

[Pablo d'Angelo]

Hi Arnd,

Arnd Baecker schrieb:

> On Fri, 11 May 2007, Pablo d'Angelo wrote:
>
> [...]
>
>
>> The problem is that the distortion parameters change with the focus. They
>> are different for short distance (as in the test shots) and the far distance
>> (where the camera is usually used).
>
> Unfortunately, not all cameras store the focus distance in their
> exif. For example for Canon EOS (20D ,300D, 350D, 5D, Digital Rebel XT,
> 1D, 1Ds) see,
>   http://photo.net/bboard/q-and-a-fetch-msg?msg_id=00F5eG
> the Makernote 0x0004: FocusDistanceUpper and FocusDistanceLower
> always show 0.
>
> Maybe it is still hidden somewhere in the  makernote ...

Yes, EXIF data is not reliable and I think, an automated lookup doesn't work
in practice (at least for the focus distance).

I guess, we should focus on the far distance parameters, since most images
are in that category.

ciao
   Pablo

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@...
To unsubscribe from this group, send email to hugin-ptx-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---

[D M German]

Hi Pablo,


 Pablo> License:
 Pablo> What kind of license should be used (for the code and more important, the
 Pablo> database)? A GPL like license to restrict usage to open source software or a
 Pablo> LGPL like license? Or a non-commercial license? Can code licences be applied
 Pablo> to databases?

I think the idea is great.

Databases are problematic from an open source point of view. I suggest
you ask this question directly to the FSF. They have a lot of
experience and will probably give us a good answer.

In many countries databases are now protected, but the underlying
facts are not (they are usually facts, that are not copyrightable). I
suspect camera correction parameters fall into this category.

This could be another reason why Tomas choose to encrypt his
database. In the US, if one tries to decipher a document (outside the
scope of the original license) then this person is breaking the
DMCA. So,

The DMCA does not protect the database, but it protects against
decryption of it.


--
dmg


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@...
To unsubscribe from this group, send email to hugin-ptx-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---

[D M German]

 >> Hmm, we still have to check that. I remember reading some papers where the
 >> principal point (shift of the perspective center) changed with the camera
 >> orientation. More experiments (measurements with multiple similar cameras)
 >> are needed to decide if including these parameters makes sense.

 Alexandre> btw, should we probably get Robert Rottmerhusen [1] involved?

 Alexandre> [1] http://rottmerhusen.com/objektives/lensid/nikkor.ht


Mmmm, it sounds like Nikon people will have plenty of problems using
non electronic lenses.

This highlights the fact that many of us use lenses that are not
recorded in the exif data. Hence it is necessary to have a way to
manually specify it.

With respect to shift from center (d,e), I don't think it is
critical. Most people will be happy with an approximation. Remember,
this is to correct one photo only.

Also, it would be nice to be able to specify the output projection
too. For instance, I frequently remap fisheye (equidistant) to
stereographic.


--
dmg

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@...
To unsubscribe from this group, send email to hugin-ptx-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---

[alexandre jenny]

 
Hi Pablo,

This is of course a great idea and we have a plan to release to the
community some
internal tools that helps to measure for example distortion ( to release
means put
them open source ).

My comments about the database :

Distortions :

> radial distortion, same as PTLens, 3 parameter radial
> polynmial, described in detail at:
http://wiki.panotools.org/Lens_correction_model
> Varies mainly with focal length. Parameters can be estimated
> at several focal lengths and interpolated in between. Each focal length
> requires a single image for calibration.

I'm against this model of distortion. It has been proven in many paper that
we can find
better and more accurate lens radial distortion parameter.
For example, for standard lens (not fisheyes), a and c can be set to null
with the same
quality of undistortion. The only effective parameter is b ( radius * radius
parameter).
Panotools needs to have a radius^4 parameter which it doesn't have yet.
If the scope of this database is to go beyond just the panotools community,
we need to
choose carrefully the model that this database will use.
The two good points of the current model is that it's the same for standard
lens and
fisheye ( thus preventing to change model between the two kind of lens ) and
we already
have some database to use to populate this one.

For vignetting, it easy to get the radial parameter, but I'm more sceptical
about the
focal / aperture dependency.

For Ca ... It's all about workflow.

BTW : Why didn't you include the photometric parameter for the camera in
this database ?

Another point that is not in this discussion : To be able to build an
efficient database,
we need to have strong measure method.
It's not really hard to get figures to put in the database, but if anyone is
doing measure
with it's own method, it will definitively leads to contradiction in result.

What would be great, is to have a tool that measures distortion / ca /
vignetting with
standard protocoles. This tool has to be simple and accurate. Everyone
should use the same
tool to make measure, and this tool should be the only data provider for the
database.

Alexandre

Kolor

> -----Message d'origine-----
> De : hugin-ptx@...
> [mailto:hugin-ptx@...] De la part de Pablo d'Angelo
> Envoyé : vendredi 11 mai 2007 00:49
> À : create@...; hugin and other free
> panoramic software
> Cc : michel thoby; sandersn@...
> Objet : [hugin-ptx] Lens correction database
>
>
> Hi together
>
> Some people who have attended my talk about hugin at the LGM
> might remember that I proposed to build a database of lens
> correction coefficients, that can be used by open source
> software (such as ufraw, gimp, krita, digikam, f-spot, etc)
> to automatically correct for lens "defects" such as lens
> distortion, vignetting and even transverse chromatic abberation.
>
> The slides for my LGM talk are available at:
> http://hugin.sf.net/tech/LGM_2007.pdf
>
> At least the Krita people are interested in such functionality:
> http://www.valdyas.org/fading/index.cgi/2007/05/08#hugin
>
> I plan to write a lightweight C library that contain the main
> pieces of code required to apply the corrections and use the
> proposed database.
>
>
> Current situation:
>
> Several databases and associated programs for correcting lens
> defects exist.
>
> For example PTLens uses a database with lens distortions
> coefficients.
> Unfortunately, Its author, Thomas Niemann has decided to
> close and encrypt
> the underlaying database a bit more than one year ago,
> shortly after I wrote
> "fulla", a command line tool to correct lens distortion.
> fulla can use the
> old, unencrypted PTLens database and correct distortions in images
> automatically. Note that PTLens requires manual user
> interaction for other
> corrections (vignetting, chromatic abberation).
> http://epaperpress.com/ptlens/
>
> In a sense the proposed database is a free alternative to the PTLens
> database, but additionally can include coefficients for
> automatic correction
> of vignetting and chromatic abberations.
>
> DxO is a commercial software that can correct the mentioned
> defects and even
> more. Obviously their database and correction methods are not
> available.
> http://www.dxo.com
>
>
> Proposed solution:
> ==================
>
> Before that can happen, we need to agree on a database format
> that can
> include all required parameters. This specifically includes:
>
> During the panorama stitching process, hugin is required to
> correct these
> distortions, and can thus be used for estimation of the
> calibration parameters.
>
> The idea is that people who want to correct their lens take
> some test shots,
> and use hugin to estimate the required calibration
> parameters. These are
> then sent (hugin projects and original images) to a lens database
> coordinator, where they are checked for plausibility and
> incorporated into
> the database.
>
>
> Scope of database:
>
> 1. Distortion correction:
> radial distortion, same as PTLens, 3 parameter radial
> polynmial, described
> in detail at: http://wiki.panotools.org/Lens_correction_model
> Varies mainly with focal length. Parameters can be estimated
> at several
> focal lengths and interpolated in between. Each focal length
> requires a
> single image for calibration.
>
> 2. Vignetting correction:
> radial correction, radial vignetting correction by division:
> I = I / (1 + b*r^2 + c*r^4 + d*r^6)
> The parameters vary with both focal length and aperture.
> Each focal length and aperture setting require 2 or 3 images for
> calibration.
>
> 3. Chromatic abberations:
> Individual distortion correction of red and blue channel, parameters
> can be estimated using hugin (more work than the other
> approaches), or by
> trial and error. Most lenses require just a single scaling factor.
> Mainly depends on focal length.
>
> Instructions for estimating the respective parameters with
> hugin are in
> the works.
>
> Who would be interested in using and building such a database?
>
> License:
>
> What kind of license should be used (for the code and more
> important, the
> database)? A GPL like license to restrict usage to open
> source software or a
> LGPL like license? Or a non-commercial license? Can code
> licences be applied
> to databases?
>
>
>
> Database (XML) layout:
>
> For each camera and lens, a single entry would be required.
> Note that my XML skills are seriously lacking, so any comments
> with respect to a different xml syntax are appreciated.
>
> 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>
>
>
> 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>
>
>   <!-- mount(s) of a lens (ie. the type of cameras it can be
> mounted on) -->
>   <mount>canonEfsSLR</mount>
>
>   <!-- a rating (quality control passed or not) -->
>   <rating>1</rating>
>
>   <!-- serial number range (for lenses with same name but different
> properties, not required) -->
>   <serial number="300" min="1" max="1000">
>
>   <!-- arbitrary user comment -->
>   <comment></comment>
>
>   <!-- correction coefficients for each focal length
>   <calibration focallength="10">
>
>       <!-- radial distortion correction, as in PTLens -->
>       <distortion a="0.02" b="-0.012" c="0">
>       <!-- transverse chromatic abberation correction -->
>       <tcaRed a="0" b="0" c="0" d="0">
>       <tcaBlue a="0" b="0" c="0" d="0">
>
>
>       <!-- aperture specific calibration values (vignetting) -->
>       <calibration aperture="3.5">
>         <vignetting b="-0.1" c="-0.2 d="0">
>       </calibration>
>
>       <calibration aperture="8">
>         <vignetting b="-0.1" c="-0.2 d="-0.3">
>       </calibration>
>
>       <calibration aperture="22">
>         <vignetting b="-0.1" c="-0.2 d="0">
>       </calibration>
>   </calibration>
>
>   <calibration focallength="14">
>       <distortion a="0.003" b="-0.001" c="0">
>       <tcaRed a="0" b="0" c="0" d="0">
>       <tcaBlue a="0" b="0" c="0" d="0">
>
>       <calibration aperture="4">
>         <vignetting b="-0.1" c="-0.2 d="0">
>       </calibration>
>       <calibration aperture="8">
>         <vignetting b="-0.1" c="-0.2 d="-0.3">
>       </calibration>
>       <calibration aperture="22">
>         <vignetting b="-0.1" c="-0.2 d="0">
>       </calibration>
>   </calibration>
>   <calibration focallength="22">
>       <!-- some more data -->
>   </calibration>
>
> </lens>
>
>
> Any feedback appreciated. Please continue discussion on the
> CREATE mailing list.
>
> ciao
>    Pablo
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@...
To unsubscribe from this group, send email to hugin-ptx-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---

[Pablo d'Angelo]

Hi Alexandre,

I have copied this to the create mailing list.

For the ones who do not know, Alexandre Jenny is the developer of Autopano
Pro, a commercial stitching software.

alexandre jenny wrote:

> Hi Pablo,
>
> This is of course a great idea and we have a plan to release to the
> community some
> internal tools that helps to measure for example distortion ( to release
> means put
> them open source ).

Sounds interesting.

> My comments about the database :
>
> Distortions :
>
>> radial distortion, same as PTLens, 3 parameter radial
>> polynmial, described in detail at:
> http://wiki.panotools.org/Lens_correction_model
>> Varies mainly with focal length. Parameters can be estimated
>> at several focal lengths and interpolated in between. Each focal length
>> requires a single image for calibration.
>
> I'm against this model of distortion. It has been proven in many paper that
> we can find
> better and more accurate lens radial distortion parameter.

Can you provide some references?

I know that the people in photogrammetry use a different model, which can
handle also tangential distortions, and they use higher orders (and only
even) ones for the radial distortion. However, for the current database the
idea was to stick to the panotools model, since then the calibration can be
done in the existing tools.

> For example, for standard lens (not fisheyes), a and c can be set to null
> with the same
> quality of undistortion.
 > The only effective parameter is b ( radius * radius
> parameter).
 > Panotools needs to have a radius^4 parameter which it doesn't have yet.

I can't really follow that argument.
a*r^3 + b*r^2 + c*r can clearly model non-monotonous "moustache" type
distortions, while a single r^2 can't.

> If the scope of this database is to go beyond just the panotools community,
> we need to
> choose carrefully the model that this database will use.

The original scope was to have a reasonably accurate database that is good
enough to correct the distortions quite well.
If we use a complex highly accurate modelling, we can hope to correct the
distortions of the lens used for calibration perfectly. For other lenses of
the same type this might look different. The main goal is to get people to
90 to 95% of correction without any hassle.

> The two good points of the current model is that it's the same for standard
> lens and
> fisheye ( thus preventing to change model between the two kind of lens ) and
> we already
> have some database to use to populate this one.

Exactly.

> For vignetting, it easy to get the radial parameter, but I'm more sceptical
> about the
> focal / aperture dependency.

You mean, the behaviour doesn't interpolate well between the different
steps? Some more experiments are needed.

> For Ca ... It's all about workflow.

Yes, CA is usually just the icing on the cake (except for fisheye lenses).

> BTW : Why didn't you include the photometric parameter for the camera in
> this database ?

Which parameters do you mean? Sensitivity? Camera response curve? I think
there are too many variables influencing these. For faithful vignetting
correction on jpg images, one obviously needs the response curve, but I hope
it is sufficient to use an average response curve.

> Another point that is not in this discussion : To be able to build an
> efficient database,
> we need to have strong measure method.
> It's not really hard to get figures to put in the database, but if anyone is
> doing measure
> with it's own method, it will definitively leads to contradiction in result.

The intention was to have a nice and easy tutorial, and do some quality
control on the input delivered by the people.

> What would be great, is to have a tool that measures distortion / ca /
> vignetting with
> standard protocoles. This tool has to be simple and accurate. Everyone
> should use the same
> tool to make measure, and this tool should be the only data provider for the
> database.

Indeed I would love to see such a tool.

However, this is quite hard to do for the general case. For good results one
probably needs to use a calibration target, which can then be printed on a
piece of A4 paper (Or whatever the person has available, the bigger the
better). This means the camera needs to be quite close and might not model
the distortion for focal settings that are further away. Vignetting
estimation based on charts is not accurate at all, since it is hard to get a
good flatfield image. The new method implemented in hugin is much better for
this, and can automatically correct for possibly non-linear response curves
as well.

But maybe I'm missed something. Can you sketch how your envisioned
calibration tool should work, and on which input it would be based?

Actually I'm working on a similar calibration software (just a bunch of
octave scripts) but with a focus on evaluating fisheye lenses together with
Michel Thoby, but it is not in a really usable state yet, and it needs a
special target.

ciao
   Pablo

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@...
To unsubscribe from this group, send email to hugin-ptx-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---

[Bernard Lang-2]

A much simpler database to create :

a database of EXIF data for all models of cameras
so that we find out easily what we get when we buy one.

Maybe it already exist, but I never saw it.  And technical
documentation of vendors does not usually say anything about that.

One advantage of such a database is that it would put pressure on
camera makers to give accurate EXIF data.

---

regarding the proposed database format :

would it allow to describe the optics of a camera with an optic
converter (tele or wide).  I know it is not the best optical solution,
but it does exist, and is used.

---

I have read in places that the distorsion is variable within a given
model of cameras ... so how good is a database.


Also, I have seen articles about automatic determination of distorsion
parameters from pictures with lots of lines.  Would not that be
preferable.


I am only trying to understand ... sorry if naive.


bernard



* Pablo d'Angelo <pablo.dangelo@...>, le 11-05-07, a �crit:

>
> Hi Arnd,
>
> Arnd Baecker schrieb:
> > On Fri, 11 May 2007, Pablo d'Angelo wrote:
> >
> > [...]
> >
> >
> >> The problem is that the distortion parameters change with the focus. They
> >> are different for short distance (as in the test shots) and the far distance
> >> (where the camera is usually used).
> >
> > Unfortunately, not all cameras store the focus distance in their
> > exif. For example for Canon EOS (20D ,300D, 350D, 5D, Digital Rebel XT,
> > 1D, 1Ds) see,
> >   http://photo.net/bboard/q-and-a-fetch-msg?msg_id=00F5eG
> > the Makernote 0x0004: FocusDistanceUpper and FocusDistanceLower
> > always show 0.
> >
> > Maybe it is still hidden somewhere in the  makernote ...
>
> Yes, EXIF data is not reliable and I think, an automated lookup doesn't work
> in practice (at least for the focus distance).
>
> I guess, we should focus on the far distance parameters, since most images
> are in that category.
>
> ciao
>    Pablo
>
>

--
             Le brevet logiciel menace votre entreprise
               Software patents threaten your company
    Soutenez la Majorit� �conomique - Support the Economic Majority
                  http://www.economic-majority.com/

Bernard.Lang@...             ,_  /\o    \o/    Tel  [phone]
http://pauillac.inria.fr/~lang/  ^^^^^^^^^^^^^^^^^  Fax  [phone]
            INRIA / B.P. 105 / 78153 Le Chesnay CEDEX / France
         Je n'exprime que mon opinion - I express only my opinion


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@...
To unsubscribe from this group, send email to hugin-ptx-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---

[Klaus Foehl]

Hello Alexandre,

>For example, for standard lens (not fisheyes), a and c can be set to null
> with the same quality of undistortion.

You are probably right. My problem with these parameters is that their
use
breaks the mapping function invariance f(-r)=-f(r), leaving b the sole
good parameter.

> The only effective parameter is b ( radius * radius parameter).
> Panotools needs to have a radius^4 parameter which it doesn't have yet.

I second you on that.
I did raise this issue in the past but it was pointed out that in
the Dersch parameter system it was difficult to introduce this extra
parameter.
I was advocating odd terms r^(2n+1) or r*(r^2n), b being coefficient
to r^3,
I'd like to have at least two parameters with the right symmetry.

Cheers

Klaus


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@...
To unsubscribe from this group, send email to hugin-ptx-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---

[Jim Watters]

Should look at what Norman Koren has done with Imatest
http://www.imatest.com/

Jim


Pablo d'Angelo wrote:

>> Another point that is not in this discussion : To be able to build an
>> efficient database,
>> we need to have strong measure method.
>> It's not really hard to get figures to put in the database, but if anyone is
>> doing measure
>> with it's own method, it will definitively leads to contradiction in result.
>>    
>
> The intention was to have a nice and easy tutorial, and do some quality
> control on the input delivered by the people.
>
>  
>> What would be great, is to have a tool that measures distortion / ca /
>> vignetting with
>> standard protocoles. This tool has to be simple and accurate. Everyone
>> should use the same
>> tool to make measure, and this tool should be the only data provider for the
>> database.
>>    
>
> Indeed I would love to see such a tool.
>
> However, this is quite hard to do for the general case. For good results one
> probably needs to use a calibration target, which can then be printed on a
> piece of A4 paper (Or whatever the person has available, the bigger the
> better). This means the camera needs to be quite close and might not model
> the distortion for focal settings that are further away. Vignetting
> estimation based on charts is not accurate at all, since it is hard to get a
> good flatfield image. The new method implemented in hugin is much better for
> this, and can automatically correct for possibly non-linear response curves
> as well.
>
> But maybe I'm missed something. Can you sketch how your envisioned
> calibration tool should work, and on which input it would be based?
>
> Actually I'm working on a similar calibration software (just a bunch of
> octave scripts) but with a focus on evaluating fisheye lenses together with
> Michel Thoby, but it is not in a really usable state yet, and it needs a
> special target.
>
> ciao
>    Pablo
>  

--
Jim Watters

jwatters @ photocreations . ca
http://photocreations.ca


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@...
To unsubscribe from this group, send email to hugin-ptx-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---

[JD SMITH-8]

On May 11, 2007, at 7:12 AM, Klaus wrote:

>
> Hello Alexandre,
>
>> For example, for standard lens (not fisheyes), a and c can be set  
>> to null
>> with the same quality of undistortion.
>
> You are probably right. My problem with these parameters is that their
> use
> breaks the mapping function invariance f(-r)=-f(r), leaving b the sole
> good parameter.

Why is that an important invariant, given that r is always positive?
 

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
To post to this group, send email to hugin-ptx@...
To unsubscribe from this group, send email to hugin-ptx-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/hugin-ptx?hl=en
-~----------~----~----~----~------~----~------~--~---

[Bruno Postle]

On Fri 11-May-2007 at 00:48 +0200, Pablo d'Angelo wrote:
>
> The idea is that people who want to correct their lens take some
> test shots, and use hugin to estimate the required calibration
> parameters. These are then sent (hugin projects and original
> images) to a lens database coordinator, where they are checked for
> plausibility and incorporated into the database.

This is a lot of ongoing work for whoever does this checking, it's
also a repetitive task without much reward and requires considerable
user input too.  Another way of going about this might be do it all
with code:

hugin is the ideal tool for calibrating lenses, but there are lots
of ways of doing this within hugin, most of them are incidental to
the main task of stitching panoramas.

It ought to be possible to be able to upload lens/camera parameters
directly from hugin, perhaps via a simple http POST to a preset but
configurable URI.

During the stitching process, hugin evaluates the quality of the
optimisation by calculating error distances, why not improve this
with some extra checks and give the user an option to upload the
results from _all_ good optimisation passes.

eg. a field of view calculation is only credible if field of view
was actually optimised and there are a large number of well-spread
control points involved with a low error distance.

Then the task of compiling the distributable database is statistical
analysis of this collected raw data, removing outliers, averaging
and interpolating.

> License:

The freedb.org database is GPL licensed.

--
Bruno

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@...
To unsubscribe from this group, send email to hugin-ptx-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---

[JD SMITH-8]

On May 11, 2007, at 4:07 PM, Bruno Postle wrote:

>
> On Fri 11-May-2007 at 00:48 +0200, Pablo d'Angelo wrote:
>>
>> The idea is that people who want to correct their lens take some
>> test shots, and use hugin to estimate the required calibration
>> parameters. These are then sent (hugin projects and original
>> images) to a lens database coordinator, where they are checked for
>> plausibility and incorporated into the database.
>
> This is a lot of ongoing work for whoever does this checking, it's
> also a repetitive task without much reward and requires considerable
> user input too.  Another way of going about this might be do it all
> with code:
>
> hugin is the ideal tool for calibrating lenses, but there are lots
> of ways of doing this within hugin, most of them are incidental to
> the main task of stitching panoramas.
>
> It ought to be possible to be able to upload lens/camera parameters
> directly from hugin, perhaps via a simple http POST to a preset but
> configurable URI.
>
> During the stitching process, hugin evaluates the quality of the
> optimisation by calculating error distances, why not improve this
> with some extra checks and give the user an option to upload the
> results from _all_ good optimisation passes.
>
> eg. a field of view calculation is only credible if field of view
> was actually optimised and there are a large number of well-spread
> control points involved with a low error distance.
>
> Then the task of compiling the distributable database is statistical
> analysis of this collected raw data, removing outliers, averaging
> and interpolating.

That's a great approach, though the Achilles heel is the need to  
identify lens/camera/focal length in some repeatable way.  Perhaps  
having a coordinator maintain a list of possible lens/camera/focal  
length settings, and mapping those to a unique ID for the database  
back-end would be useful.  This vetted, growable list would be  
exposed directly in the "upload" interface, with a guess made from  
the EXIF data, but otherwise an easy option for the user to select  
the exact combo.  To increase the incentive for users to actually do  
this, we should also offer the same interface and guess for selecting  
a lens combo itself, automatically pulling in the best starting  
values from the database.  And of course make the interface  
accessible and painless, and the upload fast.  As well, it might be  
nice to offer the option for the user to identify themselves, for  
credit in the database ("data provided by LensFreak on Aug 1,  
2007").  In principle, robust averaging 100 different low-quality  
measures of distortion will converge very rapidly on a very high  
quality distortion set.

JD

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@...
To unsubscribe from this group, send email to hugin-ptx-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---

[Yuval Levy-10]

JD, Bruno -

you are exposing very interesting ideas. the place to discuss them is
<http://lists.freedesktop.org/mailman/listinfo/create> as this will go
into (and will have implications for) other tools as well, not just
hugin.

Yuv


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@...
To unsubscribe from this group, send email to hugin-ptx-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---

[Bruno Postle]

On Sat 12-May-2007 at 05:45 -0700, Yuval Levy wrote:
>
>you are exposing very interesting ideas. the place to discuss them is
><http://lists.freedesktop.org/mailman/listinfo/create>

It won't let me subscribe (we did both Cc the CREATE list, but it is
set to reject unsubscribed posts).

--
Bruno

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@...
To unsubscribe from this group, send email to hugin-ptx-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---

[Yuval Levy-10]

On May 12, 12:36 pm, Bruno Postle <b...@...> wrote:
> On Sat 12-May-2007 at 05:45 -0700, Yuval Levy wrote:
>
> >you are exposing very interesting ideas. the place to discuss them is
> ><http://lists.freedesktop.org/mailman/listinfo/create>
>
> It won't let me subscribe (we did both Cc the CREATE list, but it is
> set to reject unsubscribed posts).

weird. what error message do you get?

wait a few days and try again - it was mentioned at LGM that the
freedesktop.org site had some issues and even after LGM some
functionalities were not always accessible.

Yuv


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@...
To unsubscribe from this group, send email to hugin-ptx-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---