[ptx] Quick question: morphing from hugin?

Rik Littlefield rj.littlefield at computer.org
Tue May 18 08:15:59 BST 2004


Sebastian,

Yes, that is what it means.  Morphing is a non-parametric warp that is 
(logically) applied after the normal parametric warp.  It allows to get 
perfectly aligned stitching boundaries even from somewhat imperfect 
source images.  See my post at 
http://www.email-lists.org/pipermail/ptx/2004-May/001597.html for more 
discussion.  You can see one of my morphed panoramas at 
http://www.janrik.net/panos/pano0ed06b.jpg (7048x3405 pixels, 7 MB).  
This image is 2 rows by 7 frames,  handheld, and incorporates some close 
foreground.  The worst control point error after parametric optimization 
is 60 pixels in the extreme foreground (out of an uncropped panorama 
size of 8000 pixels).  There are even significant errors along the 
horizon after optimizing -- probably as a result of including too much 
foreground in the optimization.  But I think you will have trouble 
finding _any_ visible stitching errors in the assembled panorama, 
because I carefully morphed along the seams as described in my 
001597.html post.

To make PTStitcher use morphing, it is just necessary to add "o" at the 
end of each "o" line, which describe output mappings, and to include the 
"C" lines coming from the optimizer for normal control points.  Each "C" 
line describes a morphed control point in terms of its output image 
coordinates after parametric warping, and the desired image coordinates 
after morph-to-fit.  Those latter coordinates are computed as a simple 
average of the coordinates of each control point pair.  This is _not_ 
the right thing to do for multi-row panoramas -- see again my 
001597.html post -- but that's the way it is right now.

Sample scripts look like this...

Non-morphed:
# script file for ptStitcher created by ptGui

p w2000 h1126 f1 v180 u20 n"PSD_mask"
m g1 i0
i n"CRW_0566.jpg"
o f0 y-2.154 r4.2271 p18.4741 v62.6348 a0 b0 c0 d0 e0 g0 t0
i n"CRW_0567.jpg"
o f0 y-7.5698 r0.229904 p-16.1753 v62.6348 a0 b0 c0 d0 e0 g0 t0

Morphed:
# script file for ptStitcher created by ptGui

p w2000 h1126 f1 v180 u20 n"PSD_mask"
m g1 i0
i n"CRW_0566.jpg"
o f0 y-2.154 r4.2271 p18.4741 v62.6348 a0 b0 c0 d0 e0 g0 t0 o
i n"CRW_0567.jpg"
o f0 y-7.5698 r0.229904 p-16.1753 v62.6348 a0 b0 c0 d0 e0 g0 t0 o
# Morph-to-fit data:
C i1  x809.889 y576.588 X811.325 Y577.251
C i0  x812.761 y577.914 X811.325 Y577.251
C i1  x1165.83 y571.156 X1165.18 Y570.904
C i0  x1164.53 y570.651 X1165.18 Y570.904
C i0  x1243.82 y572.573 X1244.65 Y572.997
C i1  x1245.47 y573.421 X1244.65 Y572.997

Notice that the "C" lines come in pairs.  Each line of the pair gives 
the parametric and morphed coordinates of a single control point.

It is worth noting also that I generated the pano0ed06b.jpg panorama 
using autopano (not yours, sorry) and then edited the control point 
lists to make them work nicely with morphing.  It is possible (likely) 
to get some bad morphing behavior from auto-generated control points, 
because there is a tendency to get nearby points in one image mapped to 
far-apart compromise positions as described by the "C" lines.  Depending 
on how the triangulation works out, this can cause obvious shearing in 
the morphed image.  It took me a long time to understand the effect -- I 
thought it was a bug in PTStitcher for literally months before I finally 
figured it out.

--Rik

Sebastian Nowozin wrote:

>Hi,
>
>as others are discussing morphing of control points on this list, I am stumbled
>as I did not even knew such feature existed. Does it do what it sounds like
>("distort the image until there is no difference between control points") ?
>
>As hugin GUI user I am not familar with the PT* commandline usage. How would
>one go from having hugin write a simple-optimized .pto file to stitching an
>image with morphing using PT* tools?
>
>
>Thanks for helping,
>Sebastian
>
>  
>




More information about the ptX mailing list