[ptx] Optimization error report

[Terje Mathisen]

ptx-bounces at email-lists.org 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 

This is obviously the wrong thing to do, particularly for lines.

> 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.

Good!

BTW, I would love an option to specify straight lines (with multiple 
control points) as being either horizontal or vertical, since this would 
make it easier to determine exact lens distortion parameters.
> 
> 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.

I like this idea a _lot_!

> 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.

This has been an obvious problem for quite a while, and in particular 
when doing lines instead of t0 points.

Terje

-- 
- <Terje.Mathisen at hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"