Hi All On Jan 3, 5:45 pm, Bruno Postle <[email protected]> wrote: > On Mon 03-Jan-2011 at 10:49 -0800, Daniel M. German wrote: > > >> ...and abandon the a,b,c polynomial while we are at it. There are > >> definitely better lens models, the question is do we need the pain involved > >> with changing from the existing model? > > >We can leave it as is, and provide a better model, but what would the > >alternatives be? > > It has been pointed out that the polynomial should only consist of > even numbered powers, both for speed and for mathematical soundness. > I'm not convinced there is anything wrong with odd powers in a radial correction function; since R is always >= 0 the odd symmetry is never manifested. But skipping powers is probably a good idea, just because it makes the coefficients a bit more independent, which I think is the real issue. Most numerical analysts would recommend using some sort of orthogonal functions, rather than powers of R, which are highly correlated.
> The distortion could be a function of angle and not proportion of > width of image. This would make discussions about whether to use > diagonal, width or height irrelevant. Also a single lens would have > the same parameters regardless of sensor size. > As usual, Bruno speaks sense. The 'normalization' Helmut built into the radial polynomial, to keep one dimension of the image fixed, is not a good idea when dealing with lens correction. It mixes a linear scale factor -- analogous to focal length -- into what should properly be a dimensionless function. The practical effect is that the focal length computed by PanoTools depends on the image dimensions. But it is absurd to think that putting a different sensor behind a lens can change its focal length. In physical optics the focal length of a lens is defined as the first derivative of radius with respect to angle (mm/radian), measured at the optical axis. That is independent of both the size of the image and the shape of the lens's projection function; it is a pure scale factor on the angle <=> radius mapping. Thus the dimensionless 'normalized radius', R = radius / focal length, can be corrected by a polynomial that is also independent of the physical scale of the image. The proper normalization for that polynomial is unit slope at zero radius, that is, first order coefficient == 1. > Tom Sharpless wrote a system that used a spline rather than a > polynomial curve, this is what is implemented in calibrate_lens. In > principle this would be more stable when optimising and faster when > rendering. > It is much faster to evaluate a polynomial than its inverse; tabulating it as a spline makes it quick to evaluate in either direction. But that doesn't change the problem of finding the right polynomial. It is still necessary to optimize the polynomial before converting it to spline tables -- directly optimizing the spline is no good as it has far too many, highly correlated parameters. I have just been wrestling with the issue of radial correction, as I'm implementing a 'universal' lens model for Panini. Well, not really universal, but I think a few steps forward. Its mapping of angle <=> 'ideal' radius can approximate all known lens types -- it is continuously adjustable from rectilinear thru stereographic thru equal- angle spherical to equal-area spherical, by a single parameter. The ideal radius R is in units of 1/focal length. The 'observed radius' is a polynomial in R with 3 coefficients, a,b,c. But the coefficients are interpreted differently, depending on the calibration source -- Panini, PanoTools, or Adobe Lens Profiles. The Panini and PT polynomials are 2nd, 3rd, 4th order; the Panini is normalized to unit slope while the PT is normalized to keep a particular radius constant ( PT and Panini coefficients can be interconverted ). Adobe coefficients are 2nd, 4th and 6th order, with slope normalization. The package will also compute TCA and vignetting corrections as polynomials in R, using PT or Adobe calibrations. And of course it can tabulate the angle<=>radius mapping as a pair of splines. All this is backed by a 'personal' camera and lens database that can store multiple calibration records per lens (keyed by focal length and f- number) and knows what lenses go with what cameras, at what average shift and tilt. No wonder it is taking me so long to finish Panini V1 :p. BTW one of the best treatments of lens calibration and correction I've seen is this article, brought to my attention last year by Michel Thoby: http://trs-new.jpl.nasa.gov/dspace/bitstream/2014/37251/1/03-0869.pdf. It has a clear and thorough treatment of 'entrance pupil shift' and describes a parameterized ideal angle-to-radius function more elegant than mine. Needs serious study, but worth it. Cheers, 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
