Reviewing & correcting my formulas for converting PT coefficients to portable ones, I realize that the first order coefficient for the portable form can no longer be set to 1 - a - b - c, as the present libpano code does in several places.
The portable a, b, c can be adjusted to make the first order coefficient 1, so that no new coefficient value need be stored in the project script. But if we are going to add a keyword, its value could be the first order coefficient. If that is 1, we have a portable (or null) correction, if 1 - a - b - c, a traditional one. If something else, something else.
Alternatively we could give the new keyword an integer value that encodes the correction type: 0 = traditional, 1 = portable converted from traditional, 2 = portable optimized directly, ... I can't think of many meaningful variations at present, but more might be discovered later.
I've put up that Wiki page: http://wiki.panotools.org/Lens_Correction_in_PanoTools. Please have a look & let me know if you disagree with any of it, or think it misses something.
2011/1/18 Jim Watters <email@example.com>On 2011-01-17 3:43 PM, Thomas Sharpless wrote:Yes it needs to allow optimization. But an error if both old(current) and new method is used together. A variable is used if it is either defined as non zero or set to be optimized.Hi Dan
On Sun, Jan 16, 2011 at 11:30 PM, dmg <firstname.lastname@example.org> wrote:
I vote to define a new flag.
it would minimize potential bugs. The default (zero) would be use current
Do you think it should be a new optimizer ('v' line) flag? That would seem logical, since this is really an optimization option. However there is no new optimizable variable to go along with it.
Currently only variables in i lines can be optimized.
Parameters defining a lens:
Old = projection format, Field of View, abc distortion (f, v, a, b, & c)The source image dimensions are also involved. (f,w,h,v,a,b,c). See Wiki page.New = projection format, Focal length, sensor size, abc? distortion
No need to change how libpano specifies focal length. It can still use image width and fov. And there would be the same number of correction coefficients, handled just as now, by the same radial() function. The only change would be a mode flag that tells the setup fns in adjust.c which scale parameter to pass to radius(), either "distanceparam" for portable coefficients, or half the smaller image dimension for traditional ones.
What about we add a new line/class to define a lens, an l line.
and the i line/class that define an image can use a l=0 (lens = lens #0)
This should help to get the lens data into a database.
Although, adding a new type of line would likely cause most optimizers and stitchers to through an error and quit.
I consider lens/camera databases a necessary and inevitable step in the evolution of stitching software. However I would favor doing that sort of thing in front-end apps rather than in libpano. There are too many issues around lens calibration that have multiple feasible solutions -- in other words, any way we decided to do it would disappoint some developers. Whereas just making the PT lens correction magically work better, without any obvious change in the external parameters (aside from a new "work better" flag) should please everyone. And is of course a precondition for any useful database.
It is also perfectly possible to derive portable correction parameters from the current kind, and the inverse of that, without changing how libpano works at all. The only caveat is that you need the values of some other parameters, as they existed at optimization, to do it. I believe the scripts output by PToptimizer, and Hugin, contain all the necessary information, so this could be done after the fact -- but not after loading a 'saved lens' into a new project. I intend to add functions for those conversions to libpano13 soon. Not only for use by apps that want to make a lens database, but to support the possibility of automatically converting correction styles in existing scripts, when we have both styles.
Input image information does not belong in the p line. I don't think we need to change the way we define the Field of View of the result. I would also like an easy way of using the output results and putting them back in as input.
Adding another var to the 'p' line might be nice, just because that line is not already overloaded with vars. That would disallow mixing polynomial modes in projects using multiple lenses, but I wonder if anyone would care? Indeed, I think that might be the best policy...
Agreed. The most important thing is to break as little current functionality as possible.An image could be defined using the old(current) method or the new lens based method. If the image was generated to a specific FoV then the old method would be used. If the input image is from a camera then the new lens based method would be used.
I'd really like to enable this option only for projects involving lens-based images. But I don't know if libpano has a sufficiently high-level view to determine that.
Well, it does seem that the most appropriate place for this new flag is on the 'i/o' lines. It needs to be handled the way "lens numbers" are now, because it should be the same for all images made with the same lens. It would then actually be possible to have projects with multiple lenses, even some with portable and some with traditional coefficients (there are some minor nightmare scenarios, but I don't think they are worth worrying about).
PanoTools-devel mailing list