Yes, we need better lens calibration, based on better camera models. But (having looked into the matter lately) I strongly agree that revising libpano is not the way to get that. Libpano was designed to support panorama stitching, not lens calibration. Its way of representing and optimizing lens parameters is not what an optical theoretician would prescribe, but it does get the job of aligning images done very well, thank you. The fact that the resulting parameters don't apply to images having different dimensions is an inconvenience only if you make it one, by trying to use them for that.
What I would suggest is to add 'portable' lens calibration at the level of Hugin, which can be done with at most minor changes to libpano. The first step would be very easy: converting saved lens parameters to suit the image at hand. The key to this is storing the original image dimensions, along with (hfov,a,b,c,d,e). Hugin now does store at least the width, but uses it only to put up a warning when you try to apply the lens to an image of a different width. Instead (or rather, in addition) it should rescale hfov to suit the new width, which is straightforward using the calibration parameters and existing libpano functions. That may or may not be a valid operation, for several possible reasons, however it is valid in all the common use cases: the image was rotated 90 degrees, or was taken at a different camera resolution, or with the lens on a different camera. So this would be a big help to the average Hugin user at little cost. PTGui is already doing something like this (but without the warning message). The next step would be to make it possible to import calibrations from other sources. I'm thinking of Adobe Lens Profiles in particular; but it should be easy to accommodate correction polynomials from any source, if the user is able to pick the source from a list and willing to enter the coefficients by hand. To apply these foreign calibrations, libpano would need a new radius correction mode (and stack routine) for each polynomial style. There is already a var that selects a radial mode, and the coefficients could go in existing slots. It would need some thought whether 'lens' optimizations could be allowed when using an imported calibration. Certainly, it would not be feasible to get 'exportable' lens calibrations without heavily revising libpano; but I have a feeling the libpano model could be used in tandem with a foreign one, just to better align the current pano. Anyhow, one required basis for such improvements is a unified database, that can store any calibration Hugin can use. This should not be so hard to set up. I'm well along with something of the kind for Panini, that uses the ini file-based app settings facility of Qt. It is just a personal-scale db, but that is what I think is wanted here. Cheers, Tom On Jan 11, 6:44 pm, Bruno Postle <[email protected]> wrote: > On Tue 11-Jan-2011 at 13:08 -0800, Klaus wrote: > > > > > I have to second Bruno in noting the shortcomings of the current > > camera model. > > Yes it has obvious technical shortcomings, but I'm not certain they > are actually a problem in practice. Switching Hugin to a different > system for would be very disruptive. > > -- > Bruno -- 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
