proj-imim:
Re: HELP! Back to Basics (Resend)
Helmut Dersch 2000-May-10 00:31:08
Doug Brightwell wrote:
>
> Typically a panorama consists of 3-4 individual
> images and covers a total HFOV of about 120-220 degrees.
Doug,
This may be the cause of some of your problems since the optimizer
works better with 360¡. Generally: the optimizer performs a _self_-
calibration of the images, which is not guarantied to result in the
true alignment positions. There may be more mathematical correct,
but nonsense solutions, and the number of such nonsense solutions
increases if field of view is smaller than 360¡.
>
> 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?
>
I can't see any reason why this would cause problems. You can try the
examples and see if they yield the same alignments.
>
> 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?
>
It really depends, and I am getting different results myself.
Using 8mm or 15mm fisheye images with 1300dpi scans, I usually get
average control point differences of 1-4 pixels. If I obtain 1.5 pixel
or less difference (usually using a monopod), the images line up with
barely visible mismatch, except close features which are always problematic.
With 4 pixels (for handheld images), some clever seam placement and/or
editing is required. I guess the main cause for this remaining error is
due to slight parallax errors.
> 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.)
>
Depends again. If I am working with my own equipment, 1 or 2 optimizations suffice.
When I am stitching images sent to me by users of my program with setups
I haven't tried before, I need several iterations, and try different
parameters for optimization, eg first just field of view and yaw angles.
> 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.
>
This guess is irrelevant for the optimization.
> QUESTION: Does my h and w values have anything to do with how accurately the
> images are aligned?
>
No, but the error scales with the size of the final image.
>
> QUESTION: Can image 0 be the anchor image, or does a middle image have to be
> the anchor image?
>
Any image can be anchor.
> 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.
>
The optimizer has the bad habit to choose the step width depending on the
initial value. Therefor, sometimes it doesn't optimize variables which
are initialized to 0. In your case you will get very small corrections
if you start with some non-zero value, but you are right that no
significant correction is required.
> 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?
>
I have taken your script and played with it. Indeed a,b,and c need not
be set. However, your optical center seems to be ill aligned, or your
scans are not centered exactly. This shift can be optimized via d and e
parameters. While your original script yields 7-8 pixel avarage errors,
I am getting ~1 pixels with proper d and e correction. The script
then becomes:
p f1 w3000 h2000 v180 n"PSD_nomask"
i f0 w1000 h801 y0 p0 r0 v95.2 n"GreenHouseA.1000.tif" d0 e0
i f0 w1000 h797 y45 p0 r0 v=0 n"GreenhouseB.1000.tif" d0 e0
i f0 w1000 h794 y90 p0 r0 v=0 n"GreenhouseC.1000.tif" d0 e0
v v0 d0 e0
v y1 p1 r1 d1 e1
v y2 p2 r2 d2 e2
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
And the results are:
Image No 0:
# Yaw: 0 deg (p) Pitch: 0 deg (p)
# Roll: 0 deg (p) HFov: 90.4783 deg (*)
# Polynomial Coefficients: a 0.000000 (p); b 0.000000 (p); c 0.000000 (p)
# Horizontal Shift: -5.222144 (*) Vertical Shift: -46.710616 (*)
# Command for Panorama Creation:
o f0 r0 p0 y0 v90.4783 d-5.222144 e-46.710616 u10 -buf
# Image No 1:
# Yaw: 45.415 deg (*) Pitch: -0.164831 deg (*)
# Roll: -0.200926 deg (*) HFov: 90.4783 deg (*)
# Polynomial Coefficients: a 0.000000 (p); b 0.000000 (p); c 0.000000 (p)
# Horizontal Shift: 1.393440 (*) Vertical Shift: -44.520685 (*)
# Command for Panorama Creation:
o f0 r-0.200926 p-0.164831 y45.415 v90.4783 d1.393440 e-44.520685 u10 +buf
-buf
# Image No 2:
# Yaw: 90.1163 deg (*) Pitch: -0.480334 deg (*)
# Roll: -0.232964 deg (*) HFov: 90.4783 deg (*)
# Polynomial Coefficients: a 0.000000 (p); b 0.000000 (p); c 0.000000 (p)
# Horizontal Shift: -2.203110 (*) Vertical Shift: -40.225423 (*)
# Command for Panorama Creation:
o f0 r-0.232964 p-0.480334 y90.1163 v90.4783 d-2.203110 e-40.225423 u10 +buf
As you can see, the vertical shift is quite consistant ~-40 pixels which
suggests that the optical center is indeed shifted.
The pixel errors are then
Control Point No 0: 1.15915
# Control Point No 1: 1.02013
# Control Point No 2: 1.05498
# Control Point No 3: 0.949311
# Control Point No 4: 1.36313
# Control Point No 5: 1.07731
# Control Point No 6: 1.32811
# Control Point No 7: 0.98615
# Control Point No 8: 1.29248
# Control Point No 9: 1.37391
which is quite good. Of course I couldn't stitch the images but
am quite sure that they fit reasonably.
> 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?
>
Depends on the number of variables to optimize. If you only adjust
position (yaw/pitch) then 3 points per pair are enough.
>
> 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.
>
I am getting now 90.4783¡. Don't overestimate the accuracy since this is not a
360¡ panorama!
> 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?
>
See above, many values may result in good fits, and the optimizer
chooses the first it finds.
> 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?
>
The optimizer stops calculating if one of several conditions is met.
This condition is reported in the message. x is the vector consisting
of the variables you are optimizing.
> 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?
>
You can get better matches, see my solution.
>
> Next, I run all three images through PTStitcher separately. ..
>
> QUESTION: Is there anything about this process that is flawed, that would
> introduce inaccuracies or misalignments?
>
You should run them together through PTSTitcher: grab all 3 images
+ script, drop it onto PTStitcher, and you get one PSD-file with
3 layers.
> 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?
>
If you create no mask, and have no stitching commands (+buf -buf), then
you have to place the seams yourself. Otherwise, PTStitcher finds
suitable seampositions for you.
Regards
Helmut Dersch