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