PanoTools mailing list archive

Mailinglist:proj-imim
Sender:Doug Brightwell
Date/Time:2000-May-09 18:59:11
Subject:HELP! Back to Basics (Resend)

Thread:


proj-imim: HELP! Back to Basics (Resend) Doug Brightwell 2000-May-09 18:59:11
Hello all...

[Sorry if anyone receives this twice. I posted it to the list yesterday and
it never showed up, so I'm resending it.]

After spending some free time on and off for a couple of months, I still
cannot get acceptable results from Panorama Tools. I really want to get
Panorama Tools to work because it seems to me to allow the most control over
images, and offers the highest quality interpolation. It seems like a
powerful program.

Many thanks to Peter Murphy for replying to my previous emails and lending a
hand with some suggestions and script corrections. But many questions are
still unanswered and I'm still having problems.

As I mentioned in the previous email, I shoot 4x5 color negs to create
panoramas for large prints. Typically a panorama consists of 3-4 individual
images and covers a total HFOV of about 120-220 degrees. I don't do 360
degree panos. The view camera is set on a leveled tripod, with a QTVR pan
head with click stops for different angles. Lenses are high quality
rectilinear view camera lenses, mainly a Schneider 58mm Super-Angulon XL.
I've been shooting in landscape orientation, horizontally, not vertically.
There's _lot's_ of overlap. In fact, probably more than I need.

I need to confirm some basic assumptions about how the program is supposed
to work.  I gather from this list that Pano Tools is working quite well for
many people. I would greatly appreciate it is someone could please take the
time to help me figure out what's going wrong. I appreciate all that Helmut
is doing, but software shouldn't be this hard! I must be missing a simple
but critical piece of information.


First of all, to quickly rule out the most obvious technical possibility...
has PTPicker/Stitcher been tested on Mac G4s running system 9? Any reason
that configuration would yield inaccurate alignments?

-------------------------------------

Secondly, can you please help set my expectations correctly regarding what
the program can and cannot do?

1) How much of the images are supposed to be aligned? In other words, should
I be able to layer two adjacent images in Photoshop, set one to 50% opacity
and see every overlapping feature line up as if the overlapping areas were
duplicates of each other? I believe Helmut said one time that perhaps not
everything will line up, but at least the control points should. But that's
never happened for me. If I have, say, 12 control points, I never ever have
those twelve places align. There does seem to be line that runs irregularly
through the image, unrelated to the control points, bending this way and
that,  where the two images come together by a few pixels, and I can create
a mask in PhotoShop by hand that takes advantage of that wandering
alignment. Is that the way it's supposed to be, or should I be expecting
that entire areas of overlap will line up?

2) Are most people finding that Pano Tools automatically yields very
accurate, seamless alignments among your images with little fiddling around?
Or is it the nature of the beast that a lot of fiddling around, re-iterative
scripting and substantial corrective touch-up in PhotoShop is required? (I'm
not trying to be negative. I truly need a frame of reference for what to
expect.)

-------------------------------------

My understanding is that to initiate a project, I need to define three
things:

- the kind of pano I want = the p line
- details of the constituent images = the i lines
- characteristics I want the Optimizer to optimize = the v lines

I do this manually, since the PTPicker GUI is geared only for 360-degre
panos, and thus generates incorrect data for panos that are not 360-degrees.
Here's the header I recently wrote and am having trouble with:


    p f1 w3000 h2000 v180 n"PSD_nomask"

    i f0 w1000 h801 y0 p0 r0 v95.2 n"GreenHouseA.1000.tif"
    i f0 w1000 h797 y45 p0 r0 v=0 n"GreenhouseB.1000.tif"
    i f0 w1000 h794 y90 p0 r0 v=0 n"GreenhouseC.1000.tif"

    v v0 
    v y1 p1 r1 
    v y2 p2 r2 

As you can see, I have three images that make up a panorama of about 180
degrees (just a guess on my part). Each image was shot in landscape
orientation, and by using the calculator in QTVRAS, I've determined that the
58mm lens on my 4x5 view camera has a HFOV of 95.2 in landscape mode.

Through trial and error, I've determined that a PSD canvas of 3000x2000
pixels will allow plenty of room for all three images to fit without being
cropped by the canvas size.

QUESTION: Does my guess of v180 need to be exact in order for the pano to be
aligned properly? Or can there be a wide range of variance? After all, I'm
just estimating what I think the total HFOV of the pano might be.

QUESTION: Does my h and w values have anything to do with how accurately the
images are aligned?

Also, I don't want Pano Tools to create masks for me or to crop the images.
I want each warped image to appear on its own separate layer in PSD. I
prefer to create the masks manually in PhotoShop in order to have greater
control, and because I've never seen an case where the software did it
accurately and seamlessly. Therefore, I enter: n"PSD_nomask"

By assigning y, p & r values of zero to image 0, I defined it as the "anchor
image against which the other two will be placed. I'm asking that only the
lens fov and the y, p, & r of images 1 & 2 be optimized to match image 0.

QUESTION: Can image 0 be the anchor image, or does a middle image have to be
the anchor image?

QUESTION: I don't optimize for a, b & c. Given the lens I'm using, is there
a need to do so? When I did try it once, the optimized results were all
zero.

QUESTION: Does what I'm doing seem right so far. Is my understanding of the
principles and particulars correct up to this point? Or, have I made a
mistake early on that is going to yield mis-aligned images later?

------------------------------------------

My next step is to open PTPicker with the above script, to load the three
images, and to place the control points. (Helmut, the placing of control
points works much better in your latest release. It's much easier.  Thanks!)

In my various experiments, I've placed anywhere from 10-20 control points
between the three images.

In my latest attempt, I placed these 10 control points:

c n0 N1 x740.25 y125.75 X330 Y135
c n0 N1 x679.75 y207.75 X270.75 Y200.25
c n0 N1 x515.25 y199.25 X38.75 Y140.5
c n0 N1 x657.5 y585.25 X246 Y598
c n0 N1 x972.5 y90.5 X489.25 Y163.25
c n1 N2 x502 y168.75 X6 Y90.75
c n1 N2 x518.75 y307 X41.25 Y289.5
c n1 N2 x533 y463.25 X67 Y497.5
c n1 N2 x884.75 y442.75 X436.5 Y423.5
c n1 N2 x870.25 y266.25 X427.5 Y280.5


QUESTION: Is there any optimum number of control points that should be
placed? How many is too many? How many is not enough? Is there any other
trick regarding where they are placed within the images?

---------------------------------------

My next step is to clean up the optimized script (see sample below). This
typically only involves deleting any +buf and -buf commands, and any u10
commands that the Optimizer put into the script.

In the resulting optimized script below, the HFov for the lens has been
re-calculated to be 87.7407. Oddly, in other scripts from other attempts,
the HFOV was calculated to be 90.0059 or 90.2241.

QUESTION: Why would the HFOV be calculated to be less than 95.2 degrees?
95.2 degrees is the HFOV determined using the QTVRAS lens calculation and
was also confirmed by Helmut to me in a previous email as being the correct
HFOV for a 58mm lens on a 4x5.

QUESTION: Given that the optimizer does calculate a different HFOV than
95.2, why would the HFOV be 87.x one time and 90.x another?

QUESTION: What does this message mean: "the relative error between x and the
solution is at most tol"? What is "tol"? Is this good news or bad news? If
bad news, how do I avoid it?

QUESTION: Why are the control points never really close together? In this
script, they're 5-11 pixels off. In other scripts I've created for the same
images enlarged to 6500x5200 pixels each, the discrepancy has been as great
as 40-50 pixels. Or, is this a typical and acceptable discrepancy?

QUESTION: Is one pass through the optimizer supposed to yield sufficient
results, or is it the nature of the process that one needs to further fiddle
and twiddle with the control points, the y, p, r and v numbers? If so, what
exactly is that reiterative process? What would I do next to the script
below to refine it and make the images align better?


FYI, here's the optimized portion of the script:

================================================
# Output  generated by Panorama Tools

# 83 function evalutations
# the relative error between x and the solution is at most tol

# Panorama description
p f1 w3000 h2000 v180 n"PSD_nomask"

# Parameters for Each Input Image:
# (*) - optimized         (p) - preset

# Image No 0:
# Yaw:    0 deg (p)    Pitch:    0 deg (p)
# Roll:    0 deg (p)    HFov:    87.7407 deg (*)
# Polynomial Coefficients: a   0.000000 (p); b   0.000000 (p); c   0.000000
(p)
# Horizontal Shift: 0.000000 (p)   Vertical Shift:  0.000000 (p)
# Command for Panorama Creation:
o f0 r0 p0 y0 v87.7407

# Image No 1:
# Yaw:    42.822 deg (*)    Pitch:    -0.27042 deg (*)
# Roll:    0.928224 deg (*)    HFov:    87.7407 deg (*)
# Polynomial Coefficients: a   0.000000 (p); b   0.000000 (p); c   0.000000
(p)
# Horizontal Shift: 0.000000 (p)   Vertical Shift:  0.000000 (p)
# Command for Panorama Creation:
o f0 r0.928224 p-0.27042 y42.822 v87.7407

# Image No 2:
# Yaw:    86.1058 deg (*)    Pitch:    -1.63496 deg (*)
# Roll:    2.70948 deg (*)    HFov:    87.7407 deg (*)
# Polynomial Coefficients: a   0.000000 (p); b   0.000000 (p); c   0.000000
(p)
# Horizontal Shift: 0.000000 (p)   Vertical Shift:  0.000000 (p)
# Command for Panorama Creation:
o f0 r2.70948 p-1.63496 y86.1058 v87.7407


# ====================================================
# Control Points: Distance between desired and fitted Position (in Pixels)

# Control Point No 0:  7.20077
# Control Point No 1:  5.20459
# Control Point No 2:  7.00645
# Control Point No 3:  6.60768
# Control Point No 4:  6.10542
# Control Point No 5:  9.28981
# Control Point No 6:  5.56739
# Control Point No 7:  11.8212
# Control Point No 8:  9.08094
# Control Point No 9:  9.03403
C i0  x1913.47 y542.555 X1916.81 Y541.204
C i1  x1920.15 y539.852 X1916.81 Y541.204
C i0  x1818.07 y665.989 X1820.61 Y665.419
C i1  x1823.15 y664.848 X1820.61 Y665.419
C i0  x1528.41 y631.092 X1527.42 Y634.453
C i1  x1526.43 y637.813 X1527.42 Y634.453
C i0  x1781.13 y1324.93 X1777.92 Y1325.71
C i1  x1774.7 y1326.48 X1777.92 Y1325.71
C i0  x2204.23 y579.103 X2202.81 Y576.401
C i1  x2201.39 y573.699 X2202.81 Y576.401
C i1  x2224.58 y584.128 X2228.63 Y581.851
C i2  x2232.68 y579.574 X2228.63 Y581.851
C i1  x2251.19 y837.787 X2252.51 Y840.242
C i2  x2253.82 y842.697 X2252.51 Y840.242
C i1  x2272.72 y1124.62 X2268.99 Y1129.21
C i2  x2265.27 y1133.8 X2268.99 Y1129.21
C i1  x2821.29 y1078.42 X2819.2 Y1074.39
C i2  x2817.11 y1070.36 X2819.2 Y1074.39
C i1  x2806.59 y815.692 X2810.3 Y813.113
C i2  x2814.01 y810.534 X2810.3 Y813.113


----------------------------------------

Next, I run all three images through PTStitcher separately. I place the
script file in the same folder as the PTStitcher helper app, and then drag
and drop the image files onto the PTStitcher icon one at a time, letting
PTStitcher finish it's work on one file before processing the next.

(I got started with this proceedure in an attempt to minimize memory
problems with 95Mb source files, and have stuck with it.)

Since I have defined the file names in the "i" lines at the top of the
script, I assume that PTStitcher knows which "o" line applies to which
image. In some experiments I "comment-out" the other "o" lines by placing a
"#" in front of them to insure that PTStitcher uses the correct "o" line for
the image being processed. As far as I can tell, this makes no difference.

The result of this process gives me three separate photoshop files, with no
masks, and with the each image entirely visible and uncropped. I combine all
three PSD files into one three-layer file.

Oddly, PTStitcher places each image in the center of the PSD canvas, not to
the left, center or right where they belong in the ponorama. I simply move
the image over to it's proper position within the canvas.

QUESTION: Is there anything about this process that is flawed, that would
introduce inaccuracies or misalignments?

Once the three PSD files are combined into one layered PSD file, and I can
make the different layers slightly transparent, I can see that the places
where I positioned control points are not really aligned. I can jiggle the
images around to achieve the best possible compromise, but it's always off
at some point in the image. For example, if I align the top of the building,
the the bottom is out of alignment. If I align the bottom, the the top is
out of alignment. If I have five control points per image, I would have
expected that there would be five points that align in the images, but they
never do.

While there are never _areas_ of alignment, there is always an irregular
line along which the two overlapping images align. I can create a hand drawn
mask that follows that as it winds it's way through the overlapping images,
and get a fairly seamless result.

QUESTION: Is that the way it's supposed to work? Is all that Panorama Tools
was ever designed to do is create alignment along that irregular and
wandering line? In other words, am I getting results that are typical for
the program, or should I be seeing alignment of broad areas of the
overlapping images?

I realize this is a lot of detail to wade through. Thanks in advance for
your kind assistance.

Doug

--
Doug Brightwell
#removed#
Home: (408) 720-1359
Cell: (415) 608-7618
FAX:  (415) 449-3559



Next thread:

Previous thread:

back to search page