On Thu, Aug 13, 2009 at 4:01 AM, D M German <dmg@...> wrote:
> Hi Tom,
> Tom> So I think this new radius function is a winner, and I'm quite pumped
> about it!
> this is great news.
> Tom> To go with it, the current line finder can extract hundreds of
> Tom> good line segments from a "liney" image in just a little more time
> Tom> than it takes to run the Canny edge detector (roughly 7 sec for a
> Tom> typical DSLR snap). So we are very close to being able to start
> Tom> some serious research using hundreds of photos.
> Tom> Of course the world will want to see polynomial coefficients for
> Tom> these lenses. It should be routine to fit a polynomial to the
> Tom> spline curve (just by sampling its values, I mean, nothing
> Tom> analytic). Does anyone know of readymade code for that?
> Why don't we just skip the polynomial coefficient and allow the
> specification of lenses in 2 models: polynomial and spline-based? Of
> course this imply more modifications to libpano than if we used their
> polynomial approximation.
The basic mode of use for lensFunc is that a client C++ program, such as
Hugin, will create a lensFunc object, loaded with the appropriate
calibration data, and pass a handle to that into libpano, along with a
source image type that means "use lensFunc". The C interface seen by
libpano is quite thin and integrating it won't be hard at all.
It is neither appropriate nor necessary to make libpano deal with persistent
calibration data. However to support the use of lensFunc by command line
tools, it may eventually be good to define one or two new PT script line
types to hold lensFunc calibration data. Even then the current command line
clients would not be able to use lensFunc, unless someone edited the scripts
for them. I think that's OK because they aren't set up to handle persistent
calibration data. It would not be too hard to enhance some of them to do
It would also be possible to give lensFunc traditional polynomial
coefficients and lens types via the libpano interface, which it could use to
set up its internal parameters, but I would prefer to do that sort of thing
at the level of the client program, where there is a better chance to get
the data right. However this may be a good interim measure, as (did I
mention?) lensFunc is quite a bit faster than the traditional remapping fns
I would be glad to see the radial polynomial off to Hell. However there is
a tremendous tradition and literature around the use of polynomial
coefficients to characterize lens distortions, and I fear lens geeks might
be unhappy if they could not have them. Of course the Dersch coefficients
are not what the l. g.s want, either, as they go backward (from "correct" to
"incorrect" radius) and contain that mysterious cubic term (something purist
lens calibrators shun). I imagine the average l. g. would want a simple
utility to fit his favorite polynomial to the lensFunc spline.
Going the other way, it is easy to set the spline from a polynomial --
provided, and this is actually a big proviso, that the polynomial is
monotonic all the way to the edge of the image. You might be surprised how
many of them aren't; and when that is so, I wonder how PanoTools can compute
the inverse function? I have to solve the problem of monotonizing the
overall mapping anyhow, to enable my dream of a single universal lens model,
so eventually it should be possible to "copy" any PT calibration that works.