[ptx] Re: Optimization error report

[Rik Littlefield]

To summarize, I understand the proposal like this:

1. Always report the same distances that are optimized.
2. For equirectangular projection, always optimize angular distance (no 
change from current behavior)
3. For cylindrical and rectilinear projection, always optimize distance 
in pixel coordinates in the rendered image.

We believe this will greatly reduce user confusion while retaining or 
improving image quality. 

Sounds good to me (but then I helped develop it, so what else would I 
think? ;-)

--Rik

PS. (Technical detail) We also will make no change to the "C" lines, so 
the morpher will work as always.

Jim Watters wrote:

> Hi everyone,
>
> I have been working with Rik Littlefields, testing some bugs fixes for 
> the optimizer.  We have discussed the possibility of modifying how the 
> values for control point distance errors are generated.
>
> Internally the optimizer calculates the distances differently based on 
> the control point type.  Normal points are calculated as spherical 
> distance.  Vertical and Horizontal points (T1 and T2) are only 
> calculated using only one axis.  And Strait Lines T+ points are 
> calculated as the distance the points are from the line.
>
> But what is reported, is the actual distance the points are from each 
> other after transformation, regardless of control point type.  This 
> means that T1, T2, and T+ points will report their physical distance 
> from each other. T0 points near the nadir and zenith may report Hugh 
> errors when their spherical distance is very close together.  This 
> report may be useful when creating rectilinear and cylindrical 
> panoramas, but not for spherical.
>
> We want the way the optimizer calculates errors to be the same as how 
> it reports its errors.  This means that T1, T2, and T+ are reported 
> the same way they are calculated.  No longer with huge meaningless 
> values.
>
> Currently dist is no longer used by the optimizer for T0 control 
> points.  It is a possibility that for very large fov rectilinear and 
> cylindrical panoramas calculating dist instead of distSphere would be 
> more usefully.  Small errors in position of images far from the center 
> will have larger error when displayed.  This is not proven yet.  It 
> sounds good in my head.
>
> What is the best thing to do for T0 (normal) control points?
> 1  - Use distSphere globally for optimizing and reporting for all 
> formats.
> 2  - Use distSphere for optimizing and reporting for spherical and 
> dist for rectangular and cylindrical.
> 3  - Have it overridable but default to 1
> 4  - Have it overridable but default to 2
>
> It might be possible, but still unsure with no source to PTStitcher or 
> the plugins and having several GUI's out there, whether an user option 
> can be set to override any default.
>
> I think the best thing to do is 2.  Then the user has the option of 
> switching to distSphere for rectangular and cylindrical just by 
> temporary setting the output format to spherical.
> Also internally the optimizer uses Root Mean Squared (RMS) of all the 
> distances to check to see if it is any closer.  Currently an average* 
> value is displayed in the message dialog and output script.  The 
> changes will use RMS as an error indications for reported for the 
> message dialog and the output script.  This will also eliminate the 
> times when the message dialog would show the optimizer starting to 
> climb instead of shrinking.  It is possible for rms to get smaller and 
> have the average error increase.
>
> * In the case of message dialog it actually displayed the sqrt of the 
> average error, which is rather meaningless and misleading because the 
> actual error is larger.
>
> Before implementing these changes we are hoping to get as much 
> feedback as possible.  We do not want to break anything.
>