[ptx] Morphing control points

[Rik Littlefield]

Let me clarify and expand a bit on Jim's note.

Jim Watters wrote:

> I have not used morphing feature of PT that much.  I am looking to the
> community for some help.

In contrast, I use morphing on almost every pano I make.  That is why I 
have not even tried nona yet -- no morphing!.

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