[ptx] Morphing control points

[Jim Watters]

I misunderstood the code change.  I now see the error of my 
interpretation.  I also notice that PTGui does not allow setting non T0 
points to use morphing when Morph-to-fit is set to Selected control 
points.  I do not know how these list of points are determined.  This 
bug needs to be fixed but carefully and with the gui cooperation so 
nothing breaks. 

And as Terje Mathisen has pointed out.

    The proper way to handle a straight line is to calculate a best fit
    (RMS error) line past all the points, and then calculate the error
    for each point as the perpendicular offset.

Which is not quite what is being done.

Calculating RMS for  strait lines should be revised with reporting for 
error and morphing, but lets do that separate.  Restoring to the 
original right now its the correct thing to do.

Jim Watters

>> Rik Littlefield has identified a bug in WriteResults (parser.c), that
>> was causing it to output "C" lines for line controls for horizontal &
>> verticals.  The calculated position of these points are completely
>> wrong.  He has proposed to not write out these lines.  I am wondering if
>> this is the correct thing to do.  It is definitely better than writing
>> out completely incorrect values. 
>
>
> Actually I disagree, and I withdraw my proposal because I believe it 
> messes up the interface between the optimizer and PTGui, PTAssembler, 
> etc.
>
> To explain...
>
> The old code in WriteResults said this:
>            if(g->cpt[i].num[0] != g->cpt[i].num[1])
>            {  /* write "C" line */  }
>
> This is a little strange because it writes "C" lines for all and only 
> those control point pairs whose points are in different images.  I 
> cannot think of any logical reason to treat horizontal, vertical, and 
> line controls differently depending on the images in which their 
> points are defined, so I believe that this code is buggy and does not 
> reflect the author's original intent.
>
> In my version RLbeta1 pano12.dll, I changed the code to say this:
>            if (g->cpt[i].type == 0)
>            { /* write "C" line */ }
>
> This consistently does not write "C" lines for anything except normal 
> controls.
>
> In response to Jim's question, I have considered the issue further.  
> As Jim says, these inappropriate "C" lines contains garbage 
> coordinates, and it seems like they should mess up morphing.  Yet I 
> realize that I have regularly used these controls in conjunction with 
> morphing, and everything works fine.  Why?  I have just now tested 
> with PTGui and found that PTGui puts out "C" lines only for normal 
> control points, when invoking the stitcher.  The inappropriate "C" 
> lines, it removes.  If I force the inappropriate "C" lines to be 
> presented to the stitcher, by explicitly copy/pasting them from the 
> optimizer output script to the stitcher input script, then indeed the 
> image does get messed up.  So from the standpoint of the stitcher, 
> getting rid of the inappropriate "C" lines seems right.
>
> HOWEVER...  I notice now that the "C" lines do not indicate what 
> control point they represent.  So it seems that PTGui, PTAssembler, 
> etc have no way to match up "C" lines with control points except by 
> knowing the exact rules that the optimizer uses to write "C" lines, no 
> matter how strange they might be.  So I suspect that by fixing the 
> little strangeness in WriteResults, I have subtly messed up the 
> interface between the optimizer and the GUI's.  I cannot confirm that 
> I have introduced a bug, but getting rid of a little strangeness is 
> not worth the risk.  So, I will restore the original rules and update 
> my pano12.dll accordingly.
> Please look for announcement of a new version being posted.
>
> Thanks, Jim, for prompting me to investigate this further.
>
> --Rik
>