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.
On Thu, Jan 20, 2011 at 10:02 AM, D M German <firstname.lastname@example.org> 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> 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
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.