Hi Klaus I hope you don't mind that I have forwarded this reply also to hugin-ptx.
On Wed, Jul 29, 2009 at 4:53 AM, Klaus Foehl <[email protected]> wrote: > Hello Tom, > > You may have read my writings about the (a,b,c) panotools > parametrisation, and my concern that camera lenses may not be > parametrised adequately. In particular I want to repeat my finding > that differeny CP locations actually give you different parameter > sets. > > With Tim's project now where it is, I suggest that he takes provisions > in his code so that additional parameters present in other camera > models (quintic correction for instance) could be added into his > algorithm rather easily. > I fully agree that at present the lens model in panotools is inadequate. That is why I am mentoring this lens calibration project -- and writing a proper lens model for libpano. You know, there is actually not even a notion of "lens" in libpano, at the bottom level, images projected with a lens are handled with exactly the same functions as ideal images. The instability of the a,b,c polynomial under optimization is one of the main consequences of this inadequacy. You are doubt aware that these are the quadratic, cubic, and quartic coefficients of a polynomial whose job is to convert the "ideal" radius -- i.e. the one that best fits the assumed "ideal" projection, either rectilinear or spherical -- into the "real" radius as measured on the image. It runs that way because that is the way the coordinates need to be mapped during stitching. So it is conceptually a way to remove "radial distortion"; but if the true (i.e. designed) function of the lens differs at all from the assumed ideal, then the polynomial has to make up the difference -- and it is not very well suited to that task. That is the big problem with fisheye lenses. But even with a rectilinear lens, the control point positions in a typical panorama alignment simply do not provide enough information about the radial error to fit a 3-term polynomial to it. So the optimizer is guaranteed to find a different set of a,b,c values given different sets of CPs. They characterise the particular arrangement of control points as much as they do the lens. Which is why I think the way to improve lens correction in panorama stitching is first of all to use adequate calibration procedures to deterimine the actual characteristics of our lenses, and use calibrated lens correction parameters for all stitching. Secondly, reduce the number of parameters that are optimized during alignment, and to treat them strictly as additional "fudge factors" that happen to improve a given alignment. They could even control "fudge functions" that are better than the radial polynomial for fixing the real misalignment problems. The ideal of calibrating all my lenses would remain just that, if I had to set up and operate an optical laboratory to do it. So if we are to deliver better lens correction to real users, we need easy calibration procedures, that anyone can do using pictures anyone can take. That is the motivation for the gsoc project "calibrate_lens". We hope to develop an automated calibration based on analyzing the curvature of lines in the image that are in reality straight. The straight line method of calibration is (so far as I know) the only one used in photogrammetry that does not require special test fixtures and procedures. Just take a few pictures of straight things, the software does the rest. For panography we don't need a very high degree of accuracy; nor do we expect to achieve it with this relatively simple calibration program. Certainly it will not be able to determine the quintic correction you mention, or shear corrections, or transverse chromatic aberration. But if it delivers a reliable correction of radial error to +/- 0.5 pixel, I will consider it a success, and would expect it to help real photographers make better panos. I expect calibrate_lens to finally deliver a lens model having 3 or 4 fitted parameters, most likely depending on a nominal lens type selected by the user. Probably only two of those parameters will be coefficients of a radius polynomial. We will try a lot of models, though, and use whatever seems to give the most consistent results. The lens model for libpano can be a little more comprehensive, to accomodate situations where one has more complete calibration data for a lens. But in 99% of the cases it will have to work with the calibrate_lens model, or something even more primitive. Regards, Tom --~--~---------~--~----~------------~-------~--~----~ 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/hugin-ptx -~----------~----~----~----~------~----~------~--~---
