01. I am restarting, hopefully for the benefit of all concerned. The
first thread has lots of problems, most of which are attributable to
my poor understanding of the basic terminology, methodologies and
fundamental algorithms that are both at the heart of PTGui [and its
sister products] and quite obviously at the heart of those of you who
have devoted so much professional time and energy to getting the suite
of capabilities that are 'out there'.
I have also -- certainly from the standpoint of this specific forum --
somewhat compounded the problem by mixing observations as between
different product implementations. While I apologize for that, as it
was clearly done to provide perspective, it can inflame passions. On
the other hand, since I have been pursuing the same challenge on the
Hugin forum, mostly because of the high degree of cross-pollination
that obviously [and quite helpfully, by the way] exists between the
two products, I know that coming at the problem from two points of
view has helped me sort through some of the issues which are generic.
02. So, let me relaunch the already helpful dialog with a new summary
that will be clearer because quite a few of you have actually looked
at the source images and now have a first-hand feel for the extent to
which they pose a similar and the extent to which they pose a rather
different challenge than what appears to be the sort of canonical set
of issues for those dealing with DSLR cameras and manual, semi-
automated, or almost-completely-automated tripod rigs designed
primarily for the creation of panoramas.
The first thing that everyone notices is that despite a remarkable
achievement of hand-drawing, these images, in many respects are not as
"nicely behaved" as those you would get from the aforesaid, multi-
snapshot, automated tripod rig. That said, as I previously alluded, I
have been able to get a working set [of a 4x4 case] using Photoshop
and purely manual placement that is very, very good. Now, I had not
previously known how to show you that, but there have been two helpful
suggestions. First, while I have continued to work with uncompressed
inputs and outputs, it would be possible for me to rework the
Photoshop workflow with compressed images. That would, of course,
cause some loss of precision, but I would be willing to do that if it
would be the least difficult way to provide all interested parties
with a result set that would be a little larger than usually chokes
most mail servers, but less than the maximum I can send via my
YouSendIt account. Alternatively Jeff has taught me about the
WeTransfer site, and from trying that I know that I can successfully
upload the 320MB Photoshop tif composite [in about 3.5 hours of slow
uplink speed from my ISP.] That, then is my first action item: those
of you who would be interested in having an example of a successful
merge of this content, please give me an email address that I can use
to have WeTransfer notify you when the file is available for your
downloadl.
02. Let me move from there to a revised statement of what I think my
challenge is with either PTGui or Hugin. And to explain why I am
introducing Hugin, it's because half of the original responders to my
request here took umbrage with my short-shrifting of their product.
Moreover, for the last 24 hours persons who actively post to both
sites have been very helpful in trying to find a methodology for
configuring the parameters of that product to correctly perform the
transformation. And I believe I am correct in stating that the
parameters of their engine are almost identical to yours, so while the
specifics of how to 'fool the engine into doing the right thing'
probably differ, upon review of the various opinions from various,
conscientious, helpful, knowledgeable persons, I think they are
probably identical at the conceptual model level.
So, let me first dare to disagree with the opinion that the set of
images are "not shots of one drawing". I believe that, in contrast to
what happens when a single camera takes multiple of shots of a scene
without changing its XYZ coordinates on the planet, the result of this
super-human drawing effort results in precisely one image, not the
patchwork of images that would result from a camera. What is
different about those 104 plates is that if they were placed on the
floor of a basketball court, but instead of letting the small [about
1/4 inch] of overlap exist, you took out your box cutter and precisely
trimmed them to eliminate overlap, to people sitting in the bleachers,
the scene total would be displayed almost perfectly.
There are not slightly different rotational angles and slightly
different azimuthal elevations -- they did not have a camera, they had
an arbitrary point and, in effect, drew the proper perspective to each
building that they carefully sketched at the proper location on what
could have been a single sheet of paper. Now, since there was no such
huge sheet of paper, rather there was the need to prepare material
that could be published in book format, they carefully, created each
independent patch, always doing whatever was humanly possible to
adhere to the proper projection from that single, unmoving point of
origin.
Now, to the statements that the images are of different sizes, yes
they are. And I suspect that the differences were compounded by the
photo-lithographic process of producing the plates. There were, very
probably some differences in the height to the camera used for
photographing the plates, and there were probably some differences in
the exact dimensions of the bounding rectangle into which each plate
drawing had been made by the artist. All that notwithstanding, I
think that in your terminology the result is in the range of 'parallax
error' that your software deals with in the case of cameras that are
hand held or otherwise imprecisely rotated during the photographic
process. What I can say, but more importantly, what I can demonstrate
with the sample that I want to send you, is that the manual,
interactive stitching of "control points" deduced by Photoshop as a
result of my placement of overlaps via onion skinning, in more than
90% of the cases results in an almost perfect match when I release the
mouse button to allow "Jump to Image". In about 5% of the cases, the
disproportionate overlay has no 'best fit', so I turn off "Jump to
Image" to make a human judgment of how to deal with the ambiguity
between the two layers that need to be blended along that common
edge. In the final result, this source of 'noise' or error is far
less noticeable than the problem I have with some images that I
cropped too closely, such that there are one or more pixel rows
completely missing along some edge. I am ever hopeful of getting
PTGui's workflow to the point where I can see and attempt to deal with
that problem of "holes". The Photoshop batch process goes into some
sort of "erasing hole" mode and fills in the missing pixels with some
very acceptable mirage!
03. As I am the neophyte, I have to leave to your better judgment as
to what to do. I very much appreciate the recommendation to crop the
images and just make them sit close to one another, but I am not ready
to give up. Again, I need to send you my intermediate results. The
sources from the LoC were cropped only insofar as eliminating the
borders to get a solid inside rectangle. As mentioned, in most cases,
that still leaves about a quarter inch that the engineer/architect/
artists wisely duplicated as between adjacent plates. it is entirely
possible to recreate a single image so that my viewers [who, by the
way will be sitting at an AIR application taking advantage of
Zoomify's ability to deal with tiled content of this sort] will be
able to 'walk down broadway from one end to the other seemlessly'.
So, back to my learning lessons of the last couple of days. The key
issues seem to be:
A. Whatever facilities exist for "photometric rationalizaton",
they need to be turned off. There is no need, nor desire to try to
reconcile the obvious difference in the brightness or darkness of the
sepia images. If there is a nice way to do that later, I will come
back to it later, but every attempt I have seen so far, produces
almost useless changes of that sort. My users will simply have to
deal with the fact that while they are 'walking down broadway'
sometimes the sun goes behind a cloud, sometimes a tall building shuts
out the sunlight -- no problem in 1874.
B. There seem to be two different ideas as to how to set the
parameters dealing with horizontal view or whatever the equivalent is
to the optical differences between a telephoto lens, and wide-angle
lens, or perhaps a micro lens. [Sorry, I am still happy with my Nikon
Photomic F, and till in debt for lenses that cost $300 in the sixties,
so I am not ready to even look at B&H to learn what a great job I
could do with an equivalent digital lens that costs as much as my car
did in the sixties.] An original suggestion here was to create the
smallest possible field of view. I think that idea stems from the
behavior that might be expected from placing the plates under a bed
scanner. The problem, I think, with that idea is that when I go to
the library and attempt to use a Size A4 bed for some topographic map
that probably is at least a yard square is that what I am imaging has
no perspective. Each image is really discrete and the result can be
stitched by aligning the correct pieces, sans overlap. That is not
how these 104 patches came into being. As I said, there never was one
basketball court sized sheet of paper that you might just break up
into A4 sheets of paper. Here, each A4 sheet represents a different
angular displacement in space from that single point of view two miles
across the river on a mythical 300 foot tower. At the end of the day,
I don't know -- do we fool the trigonometric engine by acting as if we
had an almost infinitely small, 2000 mm telephoto scan looking down on
each plate, or do we imagine that if there were such a lens, the
subtending angles between the Southwestern-most city line and the
Northeastern-most city line would have been something that would have
worked out nicely with about a 35mm-equivalent wide-angle lens of the
day? Next to turning off any attempt to level exposure lighting, I
think that getting the right lens specification is key to getting a
perfectly flat result with no 'warping', skewing, etc.
C. And that brings me to my final, never-ending spewing out of
uninformed ideas. Several people have suggested that the clue to
getting it right is to cause the 'optimizing engine' to deal only with
yaw, pitch and roll, nothing to do with [a, b, c. d, or e]. I have
tried to do that, but I have failed and I believe it is wrong. From
my simplistic point of view, I only want the software to attempt to
come up with the correct X and Y offsets based only on the Control
Points that I will have patiently provided. Effectively, I believe
the correct output -- given, of course, same-sized and same-
proportioned rectangular patches, which we know are slightly not true,
but close enough for the point I am trying to make -- is really just a
rasterization process mostly with simple orthogonal concatenation, but
that step followed by a blend of the overlap which is an entirely
different step having entirely different parameters of control. If
the software is invoking sin and cos functions something is wrong.
There is no need to rotate, roll, pitch anything. Most of the cells
in the matrix algebra transform ought to be one, and the major
operation ought just to be multiplication to deal with the level of
'zoom' as between the input bit density and the output bit density
desired/required.
I can only justify these crazy ideas by saying that so far, in my
experience, with any of the 'pano' products, if the intermediate
profile view shows anything other than a pretty regular composite
rectangle with no obvious curvature, trapezoidlal flaring, or
undulations, there is no reason to continue the workflow -- the result
will be wrong. When the result is correct, you can tell with only a
very small profile of the expected output -- it must be a flat
rectangle with no distortions of the perspective angles that are
already 'frozen' in the correct orientation.
04. Let me wrap this up by thanking everyone for their inputs. I
will gladly shut up and take this offline with any who have the
bandwidth to try to help find a solution. I am happy to see that the
problem has intrigued some of you who have worlds of experience, but
find this problem just enough different to be worth some time. That's
my only excuse for taking up so much space with what ultimately is
just one guy's problem. What I can say is that when the correct
rendering is done, there is other important historical material in the
public domain that ought to be processed in this manner in order to
increase the value to the public.
Thanks.
--
You received this message because you are subscribed to the Google Groups
"Hugin and other free panoramic software" group.
A list of frequently asked questions is available at:
http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at http://groups.google.com/group/hugin-ptx
