On Thu, Aug 13, 2009 at 4:01 AM, D M German <dmg@uvic.ca> 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 that, however.

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 it replaces.

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.

Regards, Tom