On Thu, Jan 20, 2011 at 10: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.

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