I'd like to explain mathematically why estimating both translation and
rotation is difficult when the translation is small and the FOV is small:
Assume you have a CP with an x-coordinate 'x' (x-distance on the CCD image
sensor from the middle) , and the focal length is f. The "focal axis" is
going perpendicular through the CCD image plane. Consider the line going
through the CP on the image sensor and through the focal point (the hole in
a simple pinhole camera). This line has an angle
arctan ( x / f ) with the focal axis.
Assume the camera is rotated by a small angle 'alpha' around the y-axis.
Then the CP is mapped onto a new point on the image sensor with an angle
arctan ( x / f ) + alpha
or (depending on whether rotating left or right)
arctan ( x / f ) - alpha
This CP has the new x coordinate
f * tan( arctan ( x / f ) + alpha )
on the image plane.
x/f is 'small' because the FOV is assumed to be small. alpha is also
assumed to be small, take alpha = 0.05 (in radiants) and
E.g. x / f = 0.1, so the original point with x-coordinate x = 0.1*f is
mapped to x = f * tan( arctan ( x / f ) + alpha ) = 0.1507 * f.
Now take another CP with x=0.2*f . It is also rotated by this angle alpha.
The new x-coordinate is: x = f * tan( arctan ( x / f ) + alpha ) = 0.252569
* f.
You see that the new x/f-ratio is roughly just the sum of the original x/f
ratio and the rotation angle (in radiants). This is roughly the same as if
the camera was not rotated, but translated along the x-direction.
Of course this is not exact and the optimizer can use these deviations for
distinguishing between rotation and translation. But the estimate will have
big errors.
If the FOV is even smaller, it will get more difficult to distinguish it.
GnomeNomad schrieb am Montag, 8. August 2022 um 22:14:39 UTC+2:
> 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/56799076-ebfd-43a8-bfd8-5224fb518f70n%40googlegroups.com.
