[ptx] morphing (was: new reference for stitching algorithms)

[Rik Littlefield]

Pablo,

I am glad to hear that people are thinking about morphing again.  For my 
own photos, I have been pushing in the other direction, learning how to 
use things like plumb-bob or trekking-pole-with-level to avoid parallax 
in the first place.  But there are limits to that approach, and I would 
definitely like to see morphing in nona.

I am not sure what you mean by "image based".  Auto stuff is always 
good, but I would need to retain the ability to define morph control 
points manually.  For example, some work with John Hollenberg last fall 
convinced me that visually it is usually better to have a little too 
much overlap (thus losing a little info) than to have not quite enough 
overlap (thus gaining obviously duplicated detail along the seam).

Regarding more than 2 images overlap, I think what's needed is only to 
think in terms of "same world feature visible in all images" and compute 
a single morph coordinate as a compromise of all the images in which it 
occurs.  This contrasts with the current PTOptimizer approach, which 
will happily compute 3 different compromise coordinates if you give it 
the same control points between images A/B, B/C, and A/C.  At one point 
I convinced myself that this change could be shoehorned into the 
existing pano12 and PTOptimizer interfaces by looking for exactly 
duplicated control point coordinates.  But I had no way to generate such 
control points with the existing gui's or autopano's, so I never 
implemented it.

The polar stuff, I never got a perfect handle on.  It seemed clear to me 
(after much thought) that the compromise coordinates should be computed 
in spherical coordinates to minimize average spherical distances, 
instead of averaging rectangular coordinates in the projection plane.  
That provides a uniform approach that has no problems computing 
compromises near the poles.  I played around some with manually editing 
scripts to morph control points over the poles, looking at the effect on 
equirectangular projections from PTStitcher.  I eventually convinced 
myself that all the behavior I was seeing was probably correct.  (I did 
not know how to view spherical panos at the time, so I was trying to 
interpret the equirectangulars directly -- how confusing!)  But how the 
coordinate transform code was doing its tricks, I never did figure out.

Hope this is helpful.  Write to me offline if you'd like, or keep in 
on-list if you think there's sufficient interest.

--Rik

Pablo d'Angelo wrote:

> Btw. I was thinking about the morph to fit feature that you seem to be 
> using quite often. Especially for problems like stitching cracks in 
> the pavement etc, where parallax error often occurs, should a image 
> based morphing be a good alternative? This morphing would then be done 
> based on the multilayer output of panotools. I still have to think 
> about the details a bit more, like how the poles of a spherical 
> projection should be handled and how it works for areas where more 
> than 2 images overlap etc.