From: Thomas S. <tks...@gm...> - 2011-01-16 23:45:56
|
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 |
From: dmg <dm...@uv...> - 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 <tks...@gm...>: > > 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 |
From: Thomas S. <tks...@gm...> - 2011-01-17 19:43:07
|
Hi Dan On Sun, Jan 16, 2011 at 11:30 PM, dmg <dm...@uv...> 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 |
From: dmg <dm...@uv...> - 2011-01-18 15:32:11
|
2011/1/18 Thomas Sharpless <tks...@gm...>: > Hi Dan > > On Sun, Jan 16, 2011 at 11:30 PM, dmg <dm...@uv...> 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 > Pan...@li... > https://lists.sourceforge.net/lists/listinfo/panotools-devel > > -- --dmg --- Daniel M. German http://turingmachine.org |
From: Jim W. <jwa...@ph...> - 2011-01-18 16:44:53
|
On 2011-01-17 3:43 PM, Thomas Sharpless wrote: > Hi Dan > > On Sun, Jan 16, 2011 at 11:30 PM, dmg <dm...@uv... <mailto:dm...@uv...>> 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 |
From: Thomas S. <tks...@gm...> - 2011-01-18 20:02:08
|
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 <jwa...@ph...> > On 2011-01-17 3:43 PM, Thomas Sharpless wrote: > > Hi Dan > > On Sun, Jan 16, 2011 at 11:30 PM, dmg <dm...@uv...> 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 > Pan...@li... > https://lists.sourceforge.net/lists/listinfo/panotools-devel > > |
From: Thomas S. <tks...@gm...> - 2011-01-19 13:37:04
|
Hi 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. -- Tom On Tue, Jan 18, 2011 at 3:01 PM, Thomas Sharpless <tks...@gm...>wrote: > 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 <jwa...@ph...> > > On 2011-01-17 3:43 PM, Thomas Sharpless wrote: >> >> Hi Dan >> >> On Sun, Jan 16, 2011 at 11:30 PM, dmg <dm...@uv...> 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 >> Pan...@li... >> https://lists.sourceforge.net/lists/listinfo/panotools-devel >> >> > |
From: D M G. <dm...@uv...> - 2011-01-20 15:03:04
|
Tom> Reviewing & correcting my formulas for converting PT coefficients to portable Tom> ones, I realize that the first order coefficient for the portable form can no Tom> longer be set to 1 - a - b - c, as the present libpano code does in several Tom> places. Tom> The portable a, b, c can be adjusted to make the first order coefficient 1, so Tom> that no new coefficient value need be stored in the project script. But if we Tom> are going to add a keyword, its value could be the first order coefficient. If Tom> that is 1, we have a portable (or null) correction, if 1 - a - b - c, a Tom> traditional one. If something else, something else. Tom> Alternatively we could give the new keyword an integer value that encodes the Tom> correction type: 0 = traditional, 1 = portable converted from traditional, 2 = Tom> portable optimized directly, ... I can't think of many meaningful variations Tom> at present, but more might be discovered later. I have been thinking about adding a variable to specify if the correction parms should preserve the horizontal (default) or vertical depth of field, or shortest-width, or largest width. We could use this parameter for your purposes too. So let me use the first 4 values (from zero for default, and 1, 2, 3) and use any number after for your purpose. Does that suit you? Tom> -- Tom -- -- Daniel M. German http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . |
From: Jim W. <jwa...@ph...> - 2011-01-20 18:16:52
|
On 2011-01-20 11:02 AM, D M German wrote: > > Tom> Reviewing& correcting my formulas for converting PT coefficients to portable > Tom> ones, I realize that the first order coefficient for the portable form can no > Tom> longer be set to 1 - a - b - c, as the present libpano code does in several > Tom> places. > > Tom> The portable a, b, c can be adjusted to make the first order coefficient 1, so > Tom> that no new coefficient value need be stored in the project script. But if we > Tom> are going to add a keyword, its value could be the first order coefficient. If > Tom> that is 1, we have a portable (or null) correction, if 1 - a - b - c, a > Tom> traditional one. If something else, something else. > > Tom> Alternatively we could give the new keyword an integer value that encodes the > Tom> correction type: 0 = traditional, 1 = portable converted from traditional, 2 = > Tom> portable optimized directly, ... I can't think of many meaningful variations > Tom> at present, but more might be discovered later. Shouldn't the parser always translate traditional coefficients to portable ones, if the portable are not available? Shouldn't any saved script contain the new portable coefficients? In the portable version the vabc would be different so for backwards compatibility would we write the traditional values too? If panotools is updated to use the portable coefficients does it mater where they came from(converted, optimized)? > I have been thinking about adding a variable to specify if the > correction parms should preserve the horizontal (default) or vertical > depth of field, or shortest-width, or largest width. We could use this > parameter for your purposes too. So let me use the first 4 values (from > zero for default, and 1, 2, 3) and use any number after for your > purpose. > > Does that suit you? We should also be able to define the input lens FoV. Field of View options: 0 horizontal (default) 1 vertical 2 shortest dimension 3 largest dimension 4 diagonal to the i/o line we can add a parameter 'p' for portability. p0 p1 p2 ... This could also define how the correction parameters preserve the image. parameter 'q' (just because it is next) to indicate abc are portable. q0 traditional ( default), but save the new script with portable q1 portable If no q parameter then the script will continue to save using traditional. -- Jim Watters http://photocreations.ca |
From: Jim W. <jwa...@ph...> - 2011-01-20 18:16:30
|
On 2011-01-16 7:45 PM, Thomas Sharpless wrote: > 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. Internally I think we could expand this enumeration. radial, vertical, and deregister are mutually exclusive. morph and portable would be additional flags. correction_mode_portable = 8 Both vertical and deregister are normalized on the height of the image. Think of a equirectangular image created by rotating a camera fisheye lens and only capturing a single line of pixels at each interval. Could vertical and deregister mode also take advantage of a portable mode? -- Jim Watters http://photocreations.ca |
From: Thomas S. <tks...@gm...> - 2011-01-20 21:05:46
|
On Thu, Jan 20, 2011 at 10:02 AM, D M German <dm...@uv...> wrote: > > > Tom> Reviewing & correcting my formulas for converting PT coefficients to > portable > Tom> ones, I realize that the first order coefficient for the portable > form can no > Tom> longer be set to 1 - a - b - c, as the present libpano code does in > several > Tom> places. > > Tom> The portable a, b, c can be adjusted to make the first order > coefficient 1, so > Tom> that no new coefficient value need be stored in the project script. > But if we > Tom> are going to add a keyword, its value could be the first order > coefficient. If > Tom> that is 1, we have a portable (or null) correction, if 1 - a - b - c, > a > Tom> traditional one. If something else, something else. > > Tom> Alternatively we could give the new keyword an integer value that > encodes the > Tom> correction type: 0 = traditional, 1 = portable converted from > traditional, 2 = > Tom> portable optimized directly, ... I can't think of many meaningful > variations > Tom> at present, but more might be discovered later. > > I have been thinking about adding a variable to specify if the > correction parms should preserve the horizontal (default) or vertical > depth of field, or shortest-width, or largest width. We could use this > parameter for your purposes too. So let me use the first 4 values (from > zero for default, and 1, 2, 3) and use any number after for your > purpose. > > Does that suit you? > > Would that be a per-image variable? The more I think about it, the more I think the "portable lens parameters" flag should be per-project. I see little to be gained by supporting a mixture of portable and traditional parameters in the same project, and a good deal to be gained by automatically converting old scripts to portable ones. A lot of this has to do with implementation issues. To create or use portable coefficients is amazingly simple at the level of the MakeParams: just set the constant coefficient to 1 and the radius divisor equal to MakeParams member distance. That doesn't change the coefficient values or fitted fov a lot, and if were done unconditionally, few users would be likely to notice any change except that the problem with rotated images was gone -- and that lens parameters saved before the change didn't work any more. But it is also very easy to convert traditional coefficients to portable ones, in the MakeParams context. So if we could identify old ones reliably, they could just be converted silently before use. That would be duck soup, if the constant coefficient were saved along with the others, and got back into the MakeParams intact. But it appears that project files do not record a value for the constant coefficient. Instead, there is code in several places that unconditionally sets it to 1 - a - b - c in Image.cP.radial_params. That is wrong if the coefficients are portable. It would apparently take multiple changes to make sure the constant coefficient was saved and restored properly. It would also be simple to do automatic conversion if all 'portable' projects contained a new flag, and no 'tradional' ones did -- but for two more problems. One is that there are PT applications that really do depend on the traditional normalization of the radial polynomial -- namely the ones that use it "open loop" for general image processing; Helmut cites the "Correct" Photoshop plugin as an example. This is never the case for lens correction, so the unconditional approach would probably never cause any trouble for panorama processing apps. That suggests the following control strategy: the app sets a flag, independent of anything in the PT script, that says whether it requires traditional radial parameters (default yes). The script has a flag that says whether it contains portable parameters (default no). The setup and script output codes behave as follows: app flag yes, input script flag no -- just as now: process as traditional, save as trad app yes, input yes -- convert input params to trad, process as trad, save as trad app no, input no -- convert input params to portable, process as portable, save as portable app no, input yes -- process as portable, save as portable One thing I like about this scheme is that it relieves the apps of any responsibility for maintaining the script flags. All a stitcher has to do is assert "app wants portable"; traditional apps do nothing. I doubt if the automatic back-conversion (2nd case above) would ever be used, but it can't hurt. On the other hand, offering the option of converting portable coefficients back to image specific form, before writing the output script, would complicate some of the above issues, for no gain in utility that I can see. So I think the "app wants portable" flag should always lead to a "portable" output script. There remains the problem of lens parameters saved outside PT scripts, which all 3 PT family stitchers do. I suppose that to "load a lens" they generate a new PT script. If "portable lens aware" they would have to somehow set its "portable" flag according to the kind of parameters they had saved (and they would need a new flag for that in their saved lens format). This is really an app issue, but deserves thought. Best, Tom |
From: Thomas S. <tks...@gm...> - 2011-01-20 21:14:11
|
One more issue. After the revolution, people will no doubt start reading portable scripts with pre-revolutionary programs. So we should be sure that will always cause a parse error. -- Tom On Thu, Jan 20, 2011 at 4:05 PM, Thomas Sharpless <tks...@gm...>wrote: > > > On Thu, Jan 20, 2011 at 10:02 AM, D M German <dm...@uv...> wrote: > >> >> >> Tom> Reviewing & correcting my formulas for converting PT coefficients to >> portable >> Tom> ones, I realize that the first order coefficient for the portable >> form can no >> Tom> longer be set to 1 - a - b - c, as the present libpano code does in >> several >> Tom> places. >> >> Tom> The portable a, b, c can be adjusted to make the first order >> coefficient 1, so >> Tom> that no new coefficient value need be stored in the project script. >> But if we >> Tom> are going to add a keyword, its value could be the first order >> coefficient. If >> Tom> that is 1, we have a portable (or null) correction, if 1 - a - b - >> c, a >> Tom> traditional one. If something else, something else. >> >> Tom> Alternatively we could give the new keyword an integer value that >> encodes the >> Tom> correction type: 0 = traditional, 1 = portable converted from >> traditional, 2 = >> Tom> portable optimized directly, ... I can't think of many meaningful >> variations >> Tom> at present, but more might be discovered later. >> >> I have been thinking about adding a variable to specify if the >> correction parms should preserve the horizontal (default) or vertical >> depth of field, or shortest-width, or largest width. We could use this >> parameter for your purposes too. So let me use the first 4 values (from >> zero for default, and 1, 2, 3) and use any number after for your >> purpose. >> >> Does that suit you? >> >> Would that be a per-image variable? > > The more I think about it, the more I think the "portable lens parameters" > flag should be per-project. I see little to be gained by supporting a > mixture of portable and traditional parameters in the same project, and a > good deal to be gained by automatically converting old scripts to portable > ones. > > A lot of this has to do with implementation issues. To create or use > portable coefficients is amazingly simple at the level of the MakeParams: > just set the constant coefficient to 1 and the radius divisor equal to > MakeParams member distance. That doesn't change the coefficient values or > fitted fov a lot, and if were done unconditionally, few users would be > likely to notice any change except that the problem with rotated images was > gone -- and that lens parameters saved before the change didn't work any > more. > > But it is also very easy to convert traditional coefficients to portable > ones, in the MakeParams context. So if we could identify old ones reliably, > they could just be converted silently before use. That would be duck soup, > if the constant coefficient were saved along with the others, and got back > into the MakeParams intact. But it appears that project files do not record > a value for the constant coefficient. Instead, there is code in several > places that unconditionally sets it to 1 - a - b - c in > Image.cP.radial_params. That is wrong if the coefficients are portable. It > would apparently take multiple changes to make sure the constant coefficient > was saved and restored properly. > > It would also be simple to do automatic conversion if all 'portable' > projects contained a new flag, and no 'tradional' ones did -- but for two > more problems. One is that there are PT applications that really do depend > on the traditional normalization of the radial polynomial -- namely the > ones that use it "open loop" for general image processing; Helmut cites the > "Correct" Photoshop plugin as an example. This is never the case for lens > correction, so the unconditional approach would probably never cause any > trouble for panorama processing apps. > > That suggests the following control strategy: the app sets a flag, > independent of anything in the PT script, that says whether it requires > traditional radial parameters (default yes). The script has a flag that > says whether it contains portable parameters (default no). The setup and > script output codes behave as follows: > app flag yes, input script flag no -- just as now: process as > traditional, save as trad > app yes, input yes -- convert input params to trad, process as trad, save > as trad > app no, input no -- convert input params to portable, process as > portable, save as portable > app no, input yes -- process as portable, save as portable > > One thing I like about this scheme is that it relieves the apps of any > responsibility for maintaining the script flags. All a stitcher has to do > is assert "app wants portable"; traditional apps do nothing. > > I doubt if the automatic back-conversion (2nd case above) would ever be > used, but it can't hurt. On the other hand, offering the option of > converting portable coefficients back to image specific form, before writing > the output script, would complicate some of the above issues, for no gain in > utility that I can see. So I think the "app wants portable" flag should > always lead to a "portable" output script. > > There remains the problem of lens parameters saved outside PT scripts, > which all 3 PT family stitchers do. I suppose that to "load a lens" they > generate a new PT script. If "portable lens aware" they would have to > somehow set its "portable" flag according to the kind of parameters they had > saved (and they would need a new flag for that in their saved lens > format). This is really an app issue, but deserves thought. > > > Best, Tom > > |
From: Pablo d'A. <pab...@we...> - 2011-01-22 09:16:54
|
Hi Tom, Am 17.01.2011 00:45, schrieb Thomas Sharpless: > Hi all > > It is possible to convert the present a,b,c to the portable form, What about d,e? I find that these are quite important when stitching wide angle images. ciao Pablo |
From: Thomas S. <tks...@gm...> - 2011-01-22 19:14:11
|
Hi Pablo On Sat, Jan 22, 2011 at 4:16 AM, Pablo d'Angelo <pab...@we...>wrote: > Hi Tom, > > Am 17.01.2011 00:45, schrieb Thomas Sharpless: > > Hi all > > > > It is possible to convert the present a,b,c to the portable form, > > What about d,e? I find that these are quite important when stitching > wide angle images. > Porting distances (focal length, d, e) is a different problem from porting the polynomial coefficients. It is possible to eliminate pixel size from d, e, simply by dividing them by the focal length in pixels. That would make them portable, in the sense that having determined the FL in pixels for the new format, you can get d,e in new pixels. There remains the problem of relating PT's FL in pixels to physical quantities. By far the best basis for that, IMO, is the pixel size, which is very accurately specified for digital cameras. It is unfortunate that PanoTools does not use or record any physical parameters of lens and camera, so you can't replace pixels with millimeters from inside libpano. However Hugin or other front-end apps having that information, could record (fitted) FL in mm, and use that to compute FL in pixels for new formats from sensor specs. FL in pixels is computed by libpano thus: flpix = 0.5 * wid / A2N(0.5 * hfov), where A2N(a) = tan(a) for normal lens and = a for fisheye. After a good deal of study I am convinced that though this is a biased estimate of the FL, as defined in physical optics, when used together with the polynomial it will actually give correct angles, because the polynomial is biased in a complementary way. (All of this assuming full optimization of a 360 degree calibration set with plenty of overlap and plenty of CPs). Does it matter what you say FL is, if you make the right picture? By the same argument, I now think it would not hurt portability to leave the constant term at 1-a-b-c; I think that just rescales the bias. What really matters is substituting 'distance' (which is flpix in pano coordinates) for (half the minor source dimension) as the 5th parameter to radius(). Hoping we can make portable lens correction a reality soon, Best regards, Tom > ciao > Pablo > > > ------------------------------------------------------------------------------ > Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! > Finally, a world-class log management solution at an even better > price-free! > Download using promo code Free_Logger_4_Dev2Dev. Offer expires > February 28th, so secure your free ArcSight Logger TODAY! > http://p.sf.net/sfu/arcsight-sfd2d > _______________________________________________ > PanoTools-devel mailing list > Pan...@li... > https://lists.sourceforge.net/lists/listinfo/panotools-devel > |
From: D M G. <dm...@uv...> - 2011-01-25 02:30:04
|
Tom> Would that be a per-image variable? Tom> The more I think about it, the more I think the "portable lens Tom> parameters" flag should be per-project. I see little to be Tom> gained by supporting a mixture of portable and traditional Tom> parameters in the same project, and a good deal to be gained by Tom> automatically converting old scripts to portable ones. Keep in mind that libpano does one photo at a time, so the "per-project" issue is not really a major one. We would benefit by having a lens line, because it would be easier to move around between files. In the current model, any lens line is specified in one image, and then referenced later in other images. The problem of this model is that the lens line cannot be easily extracted and copied to another image. Another thing, The current correction happens in spherical coordinates as a way to simplify the model, but you are correct, a new correction model can be moved before the image is mapped to the sphere (in the actual coordinates of the photo). I personally don't think it matters much, except that it in the spherical coordinates it is easier to correct while maintaining field-of-view. Recapitulating... my vote is to institute a lens line and let images refer to it. --dmg Tom> Best, Tom -- -- Daniel M. German http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . |
From: Thomas S. <tks...@gm...> - 2011-01-25 14:54:35
|
Hi Dan On Mon, Jan 24, 2011 at 9:29 PM, D M German <dm...@uv...> wrote: > > Tom> Would that be a per-image variable? > > Tom> The more I think about it, the more I think the "portable lens > Tom> parameters" flag should be per-project. I see little to be > Tom> gained by supporting a mixture of portable and traditional > Tom> parameters in the same project, and a good deal to be gained by > Tom> automatically converting old scripts to portable ones. > > Keep in mind that libpano does one photo at a time, so the "per-project" > issue is not really a major one. > > We would benefit by having a lens line, because it would be easier to > move around between files. In the current model, any lens line is > specified in one image, and then referenced later in other images. The > problem of this model is that the lens line cannot be easily extracted > and copied to another image. > > Another thing, > > The current correction happens in spherical coordinates as a way to > simplify the model, but you are correct, a new correction model can be > moved before the image is mapped to the sphere (in the actual > coordinates of the photo). I personally don't think it matters much, > except that it in the spherical coordinates it is easier to correct > while maintaining field-of-view. > > Recapitulating... my vote is to institute a lens line and let images > refer to it. > I think a lens line is a great idea; perfect, from the point of view of script management. Implementing it would take a bit more new code in libpano, than just slipping in 2 new image parameters, but I'm sure it would be worth the trouble in the end. w.r.t your other e-mail, I fully agree that libpano is not the place to implement a lens database. But it should support fully portable calibrations. And packaging those on separate lines would definitely make things easier for apps that do use a lens db. Any thoughts about how to ID and reference lens lines? I'd be tempted to use string names, a further step toward a db, I guess. Regards, Tom > > --dmg > > > > > Tom> Best, Tom > > -- > -- > Daniel M. German > http://turingmachine.org/ > http://silvernegative.com/ > dmg (at) uvic (dot) ca > replace (at) with @ and (dot) with . > |