[CREATE] Lens correction database

Andrew Zabolotny zap at homelink.ru
Wed Aug 22 15:43:28 PDT 2007


Hello again!

In the continuation of the theme.

The current draft of the database is based on the panotools lens
aberration model which is described here:

http://wiki.panotools.org/Lens_correction_model

This model involves a 4-order polynome for modelling both TCA and
distortion: rd = a * ru^4 + b * ru^3 + c * ru^2 + d * ru, where rd is
the distance from the image center to the distorted pixel, ru - to the
undistorted pixel.

However, there is at least one another lens distortion model that is
used by the Imatest software which is used by some sites (e.g.
photozone.de) when testing lenses. The model is described here:

http://www.imatest.com/docs/distortion.html

Also the Paul van Walree's page on lens distortion:

http://www.vanwalree.com/optics/distortion.html

seems to like this lens model. It uses a 5-th order polynomial but uses
only odd terms, e.g. rd = k1 * ru^3 + k2 * ru^5. In simple cases the
5th order term may be omitted, e.g. rd = k1 * ru^3, like in this
paper:

http://etoile.berkeley.edu/~jrg/Aberrations/node10.html

This model is very suitable for real-time computations, since it does
not require computing a square root per pixel, which is a very
expensive operation:

rd/ru = k2 * ru^4 + k1 * ru^2,
ru = sqrt (dx^2 + dy^2) =>
rd/ru = k2 * (dx^2 + dy^2)^2 + k1 * (dx^2 + dy^2)

and then you just have to multiply dx and dy by rd/ru to get the
distorted x and y.

I would like to see the lens correction formulas suitable for realtime
applications, since a) If the lens database will contain e.g. VCR
lenses and such, some software may want to process video in realtime;
b) In software such as UFRaw the user would like to see the effect of
changing distortion and TCA sliders in realtime, with a minimal delay.

Also a side effect could be that we could use calibration data from
Imatest in the lens database.

One problem is that the current database has a lot of data for lenses
in Panotools format, and switching lens model would mean we can lose
all of it.

I see several solutions here:

a) Just extend the current model of a, b, c and d with yet another
coefficient for ru^5:

rd = c5 * ru^5 + c4 * ru^4 + c3 * ru^3 + c2 * ru^2 + c1 * ru
(where c4 == a, c3 == b, c2 == c, c1 == d)

and select the appropriate algorithm depending on which coefficients are
non-zero. However, this would mean that some lenses would be described
with the "fast" polynom and some with the "slow" one, which will lead to
inconsistent program behavior.

b) Approximate the a,b,c polynom with a k1,k2 polynom. I wrote a
Octave script which tries to do that, and the results are questionable.
I have to see yet how this looks on a real-world image.

Right now the same approach is used in Hugin to describe both distortion
and TCA, although Paul van Walree here
(http://www.vanwalree.com/optics.html) suggests that lateral color
depends only of the distance, e.g:

rd = ru * c

I'm not sure if that's always true, have to check it on some real-world
images again.

So to generalize:
 - Lens distortion is tied to the focal distance of the lens (for
zooms). A programmatically optimal model for it is k1 * r^5 + k2 *
r^3. An additional parameter like 'd' can be added to provide
image scaling.
 - Transverse chromatic aberrations are tied to the focal distance of
the lens. It is possible that it can be modelled with the simple
equation k * r (to be checked). Would be nice to have them in database
too.
 - Vignetting depends of the focal distance, and according to Paul van
Walree also depends on the distance to subject. That's quite
unfortunate since distance to subject is not a standard EXIF item, and
besides there are still alot of manual-focus lenses in use. So perhaps
the parameters for vignetting could be measured at several distances
and then present the user a slider with which he can select the
approximated distance to the subject, interpolating between existing
parameters. I just hope that in practice vignetting does not change too
much with the focused distance (to be checked).

Comments anyone?

-- 
Andrew


More information about the CREATE mailing list