## panotools-devel

 [PanoTools-devel] Portable lens parameters From: Thomas Sharpless - 2011-01-16 23:45:56 Attachments: Message as HTML Hi all Many of you are no doubt aware that the lens parameters computed during pano optimization depend on the dimensions of the source image, and so cannot properly be applied to images made with the same lens but in different formats. This is unfortunate, in part because it hampers efforts to make sharable lens databases. I have been looking into the mathematical basis for this, and shall publish a full analysis on the PT Wiki soon. The executive summary is this: There are two reasons why libpano's lens parameters are not portable. One is the use of source hfov and width in pixels, rather than physical parameters such as the lens focal length and camera's pixel size in mm, to characterize the magnification. This is not a fundamental problem and can easily be dealt with in front-ends. The other is fundamental. The correction polynomial (which computes the factor by which the ideal radius must be multiplied to get the observed radius) is normalized to give unit output for unit input (that isn't the problem). The argument to that polynomial is the ideal radius divided by half the width or height of the source, whichever is less. That makes the fitted values of a, b, c depend on the source dimensions, which is the problem. If instead the argument were radius / (ideal focal length in pixels), then the coefficients would depend only on lens properties. Then they would be applicable to any image made with the same lens, even on a different camera or in a very different format (for example 16:9 HD video versus 3:2 traditional photo). It is possible to convert the present a,b,c to the portable form, but this requires knowing the hfovs and widths of both source and panorama (at the time of optimization). I would like to add a function to libpano to do that, to support extracting portable lens coefficients from optimized PT scripts. However, as a simpler and possibly preferable alternative, I would like to propose an option to use the portable normalizing factor during pano processing (optimization and warping) instead of the traditional one. This would be ridiculously easy to implement; the needed factor already exists as the pano's "distance parameter", it's just a matter of passing it to radial(). The main purpose of this message is to ask you all to think about how best to control such an option. I first thought that perhaps one of the 4 'correction modes' presently defined might be taken over for this purpose -- if there is one that is never used -- since that mode value is what is presently used to select the radial normalization factor. Those are: > enum > { > correction_mode_radial = 0, > correction_mode_vertical = 1, > correction_mode_deregister = 2, > correction_mode_morph = 4 > }; > This is tested bitwise in several places, so it would be unsafe to use the value 3, 5, or 6. Or, it might be better to control this option with a new flag, associated only with panorama processing setups, as the correction modes may find uses in PT modules that do general image processing. In any case, use of the portable coefficients option during optimization would have to be recorded in the script, and force its use also during stitching. Comments, please. Best, Tom
 Re: [PanoTools-devel] Portable lens parameters From: dmg - 2011-01-17 04:30:51 I vote to define a new flag. it would minimize potential bugs. The default (zero) would be use current model. --dmg 2011/1/17 Thomas Sharpless : > > The main purpose of this message is to ask you all to think about how best > to control such an option.  I first thought that perhaps one of the 4 > 'correction modes' presently defined might be taken over for this purpose -- > if there is one that is never used -- since that mode value is what is > presently used to select the radial normalization factor.  Those are: >> >> enum >> { >>     correction_mode_radial = 0, >>     correction_mode_vertical = 1, >>     correction_mode_deregister = 2, >>     correction_mode_morph = 4 >> }; > > This is tested bitwise in several places, so it would be unsafe to use the > value 3, 5, or 6. > > Or, it might be better to control this option with a new flag, associated > only with panorama processing setups, as the correction modes may find uses > in PT modules that do general image processing.  In any case, use of the > portable coefficients option during optimization would have to be recorded > in the script, and force its use also during stitching. > > Comments, please. > > Best,  Tom > -- --dmg --- Daniel M. German http://turingmachine.org
 Re: [PanoTools-devel] Portable lens parameters From: Thomas Sharpless - 2011-01-17 19:43:07 Attachments: Message as HTML Hi Dan On Sun, Jan 16, 2011 at 11:30 PM, dmg wrote: > I vote to define a new flag. > > it would minimize potential bugs. The default (zero) would be use current > model. > 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. 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... 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. Regards, Tom
 Re: [PanoTools-devel] Portable lens parameters From: dmg - 2011-01-18 15:32:11 2011/1/18 Thomas Sharpless : > Hi Dan > > On Sun, Jan 16, 2011 at 11:30 PM, dmg wrote: >> >> I vote to define a new flag. >> >> it would minimize potential bugs. The default (zero) would be use current >> model. > > 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. But it is not an optimization only variable. It is an input image one (it is in the input image --or output) where the lens is indicated. v-variables are not parsed for remapping. > 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... > > 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. I don't really understand what you mean by either one of the two sentences. > > Regards, Tom > > > > > ------------------------------------------------------------------------------ > Protect Your Site and Customers from Malware Attacks > Learn about various malware tactics and how to avoid them. Understand > malware threats, the impact they can have on your business, and how you > can protect your company and customers by using code signing. > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > PanoTools-devel mailing list > PanoTools-devel@... > https://lists.sourceforge.net/lists/listinfo/panotools-devel > > -- --dmg --- Daniel M. German http://turingmachine.org
 Re: [PanoTools-devel] Portable lens parameters From: Jim Watters - 2011-01-18 16:44:53 Attachments: Message as HTML On 2011-01-17 3:43 PM, Thomas Sharpless wrote: > Hi Dan > > On Sun, Jan 16, 2011 at 11:30 PM, dmg > wrote: > > I vote to define a new flag. > > it would minimize potential bugs. The default (zero) would be use current > model. > > > 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. 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. 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) New = projection format, Focal length, sensor size, abc? distortion 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. > 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... 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. > 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. 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. > > Regards, Tom > -- Jim Watters http://photocreations.ca
 Re: [PanoTools-devel] Portable lens parameters From: Thomas Sharpless - 2011-01-18 20:02:08 Attachments: Message as HTML Hi 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 > On 2011-01-17 3:43 PM, Thomas Sharpless wrote: > > Hi Dan > > On Sun, Jan 16, 2011 at 11:30 PM, dmg wrote: > >> I vote to define a new flag. >> >> it would minimize potential bugs. The default (zero) would be use current >> model. >> > > 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. > > 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. > 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. > > 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... > > 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. > > Agreed. The most important thing is to break as little current functionality as possible. > > 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. > > 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. > > 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). Best, Tom _______________________________________________ > PanoTools-devel mailing list > PanoTools-devel@... > https://lists.sourceforge.net/lists/listinfo/panotools-devel > >