I shoot lots of handheld panoramas. I'm relatively steady at holding my
camera and things come out fine rotating about the vertical center of my
stance. I have never had to use translation of any sort for these shots,
and optimization works pretty quickly.
I've found I get better results by stepping up through the different
levels of optimization and cleaning control points after each step.
Maybe removing bad control points helps the optimization process?
The only time I used translation was when I had the camera on a tripod
and shot a series of frames down the length of a graffiti in a tunnel. I
moved the tripod down a certain distance (I forget how far) for each
shot, keeping the same distance from the wall.
I also don't remember how long optimization might have taken. That was
long enough ago it was probably on the original AMD Sempron processor on
the old server.
I guess I don't think ultrafast optimization is important, much
preferring accuracy. The present laptop's i9 with 64GB RAM optimizes a
lot faster, anyway. :)
On 8/8/22 09:29, Florian Königstein wrote:
Before I answer to your post more detailed, could you please send me the
images per Mail so that I can load the pano without the need for dummy
images. Maybe the optimization was faster for me since some CPs were
deleted due to my dummy image. Having your images I can see the speed in
exactly your configuration.
I just tried out a pano with only two images. The camera was rotated by
an angle of about 22 degrees between the images. I also held the camera
by hand, but translation is anyway small compared to rotation. When I
optimize only yaw, pitch and roll, the optimizer finds the yaw of about
22 degrees. When I optimize yaw, pitch, roll, TrX, TrY, TrZ, the
optimizer finds a yaw of 6 degrees and some rather big translation. That
is nonsense. This example confirms that estimating both rotation and
translation when the translation is zero or small is very difficult.
[email protected] schrieb am Montag, 8. August 2022 um 20:42:58 UTC+2:
On Monday, August 8, 2022 at 11:32:07 AM UTC-4 Florian Königstein wrote:
Hi John,
Optimization ran fast for me,
What is "fast" and which hugin did you use?
It runs "fast" (17 to 36 seconds) using any build of pano13 with
sparse lev-mar. But I still want it to be faster and I want much
bigger examples (even though I don't currently have any) to also be
fast.
With one exception, it runs "slow" (85 to 212 seconds) in any build
without sparse lev-mar. That is exactly as I'd expect and I'm not
much interested in those.
The exception I asked about was:
2021.0.0.52df0f76c700 built by Thomas
I'm pretty sure that does not have sparse lev-mar. It optimizes in
21 seconds producing garbage results (large average, 158 worst
case). The worst CP is not a poorly chosen CP. All the other
versions have worst CP 30 to 38.
My question was why that build is so fast and bad.
The fact that the average can be below 3 and the worst 30 means I
want to be able to do that well regularly. So I have the second
issue of why fastPTO does slightly worse. It should simply be
faster, not a tradeoff of much faster for slightly worse. But that
is too complicated and detailed for me to want to ask here. I'll
need to figure it out myself. But why the official hugin build is
so much faster and worse than it should be seemed like somethings
others might weigh in on.
First I assume:
** You took the images in a "standard way", i.e. by rotating the
camera around a tripod or panoramic head.
No. I did not set up my tripod for that one. I hand held as
carefully as I could and came pretty close. So I certainly needed
to optimize the six basic parameters of camera position as well as
one lens parameter.
** You just want so see how the optimizer works when you select
nearly all variables to be optimized.
I avoided opening the FOV can of worms. The correct FOV is known
and using incorrect FOV as a coverup for other issues is one of my
frequent tools, but not a valid tool either for this panorama or for
this performance test.
Some other parameters are in there mainly for "maybe they help" in
addition to performance testing purposes.
The problem is that you select both rotation and translation to
be optimized. Normally, you should only optimize for yaw, pitch
and roll, but not for trannslations - if you rotated the cammera
but didn't perform bigger translations.
Instead if you kept the orientation of the camera the same and
translated it for the different photos, then you should optimize
for translations, but not for yaw, pitch and roll.
I certainly needed all six of those. Otherwise, the panorama is
garbage. I did my best to hand hold the camera varying only Yaw and
Pitch, not Roll, TrX, TrY, and TrZ. But I didn't do that well
enough. Tr value are tiny compared to the physical distance to
nearest CP but they still matter.
I haven't yet taken any mural shots, so varying translation without
also Yaw is not in any of my examples.
The reason is the following:
Suppose you have a FOV that is not big (like you have). Imagine
first you rotate the camera a bit horizontally. Then you rotate
it back to the original position and trannslate it a bit
horizontally. If the amout of rotation and translation have an
appropriate ratio, then the control points will move in a
similar way (not much difference) in the image both by rotation
and by translation. So the optimizer cannot decide whether you
rotated or translated the camera.
There is enough difference. If the real world location of the CPs
in an image are relatively co planar (with each other) then
optimization should be able to distinguish rotation from translation.
I have refined my ideas (but not yet written code) for handling the
case that the real world CPs are not actually co planar. I think I
will then do vastly better than 3 average and 30 worst case in this
example. But before coding that, I want a somewhat better
understanding, and maybe do a cleaner re-coding, of what is already
there.
In some cases you can determine both rotation and translation of
the camera, but these cases are usually not relevant for
panorama photography: Assume for simplicity you have an ideal
(pinhole) camera (no lens distortion). Assume you have 5 (or
better 8) points in 3D space that will get control points in the
photos. You take two photos of these points by both rotating and
translating the camera between these photos. Then there are
mathematical algorithms with that you can determine both the
relative rotation and the relative translation of the camera.
But there are at least two cases in that the algorithms fail or
yield bad results (big errors):
1. There is no or little translation in the camera position
between the two photos
That is the area in which my current ideas are least solid: Hugin
is already good for where all the cameras have little of no
translation. The tricky case (but I won't know untill I code an
test this) is a CP that is only seen by cameras that have little
translation relative to each other, but significant translation
relative to the chosen origin for the panorama.
2. All the points in 3D space are on a plane (e.g. on the wall
of a house or on the flat ground plane)
I'm not understanding your point. First, that case doesn't need to
be fixed. Hugin does it well enough already. I'm trying to create
only an alternative for when that isn't true. But, unlike the case
of all cameras being in the same place, the new method would also
work fine for planar CPs. I can't see any reason that ought to be a
problem.
Maybe you are thinking about the case that the chosen origin for the
panorama is not among the camera locations (neither matches a
single camera as one normally would) nor has cameras generally
"around" it. That is a very hard (and pointless) panorama anyway,
and maybe the planar CPs make it harder.
But since you are commenting, I'll ask your opinion on a related
part of where I'm going with all this (since you seem to understand
the case of very many images):
I think I can get a big performance boost by using the tendency to
have multiple images per lens. So my question is whether, in the
useful cases of very many images, there are several images per lens.
I mean a "lens" in the sense of a set of parameters, so at the
optimization level, a group of images within which every lens
parameter is either linked to be equal or constant and happens to be
equal.
My code idea would speed things up significantly when one set of
lens parameters (whether fixed or subject to optimization) applies
to multiple images. It would only very slightly slow down
optimization if every image has its own lens parameters.
Since I bought by 105mm non-zoom lens. It has been used for almost
all my panoramas. If I were an actually competent hugin user, I
would separately determine its parameters and use them for all such
panoramas. So far I just let each panorama solve whatever lens
parameter(s) seem to help, but subject to one lens for all images.
--
David W. Jones
[email protected]
wandering the landscape of god
http://dancingtreefrog.com
My password is the last 8 digits of π.
--
A list of frequently asked questions is available at:
http://wiki.panotools.org/Hugin_FAQ
---
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/hugin-ptx/2c93b71f-abf6-d33f-6548-93e052ffe369%40gmail.com.
