Viewpoint correction (aka translation)

[Torsten Bronger]

Hall�chen!

For the nadir image, my plan was to move the tripod 1 metre to the
side and take another picture downwards. The ground is a flat
surface.

In Hugin, I added control points (on the plane only) and included X,
Y, and Z of this last photograph into the optimisation.

It works, but I have to set many control points (> 6) for this.
This surprises me, as only three additional parameters need to be
fitted. It still works rather badly, with errors in the fitted
coordinates which are 10 times larger than for the stitching without
nadir.

Moreover, if I move the panorama in the move tab of the OpenGL
previewer, I misalign the nadir very quickly. In fact, I have to
re-optimise after every repositioning of the panorama in the
previewer.

So my question are, why are so many control points needed to have
still a large error estimate, and why is the position of the nadir
image relatively to the other depending on the viewing direction of
the panorama centre?

Tsch�,
Torsten.

--
Torsten Bronger Jabber ID: torsten...@jabber.rwth-aachen.de
or http://bronger-jmp.appspot.com

[Torsten Bronger]

Hall�chen!

Torsten Bronger writes:

> For the nadir image, my plan was to move the tripod 1 metre to the
> side and take another picture downwards. The ground is a flat
> surfac<e.
>
> In Hugin, I added control points (on the plane only) and included
> X, Y, and Z of this last photograph into the optimisation.
>

> [...]

>
> Moreover, if I move the panorama in the move tab of the OpenGL
> previewer, I misalign the nadir very quickly. In fact, I have to
> re-optimise after every repositioning of the panorama in the
> previewer.

I made a screencast demonstrating that two images, one of them with
non-zero X, Y, Z parameters, slide relatively to each other just by
changing the viewing direction:
http://www.youtube.com/watch?v=qASS-_lC7UE

I don't want to say that this is wrong but I also don't understand the
cause of this. I would have expected that the translated image is
re-mapped on the sphere of the panorama, thus fixing it relatively
to the others.

Now, I have to optimize again and again after each change in the
preview.

[Carl von Einem]

I don't get the point why you are trying to optimize the nadir shot by
- using translation
- dragging both images in the Fast Preview window at the same time

Did you make sure you set the nadir shot in Hugin to use a "different lens"?

Did you try a tutorial like e.g. these two:
http://wiki.panotools.org/Stitching_Nadir_Shots
http://wiki.panotools.org/Fixing_nadir_parallax_errors

Translation is needed for something like this:
http://www.flickr.com/photos/36383814@N00/5830006193

Torsten Bronger schrieb am 19.04.13 13:50:

[Torsten Bronger]

Hall�chen!

Carl von Einem writes:

> I don't get the point why you are trying to optimize the nadir shot by
> - using translation

Because I thought it is a very easy and reliable solution to the
nadir problem, given that I have a perfectly planar ground and a
very well calibrated lens.

> - dragging both images in the Fast Preview window at the same time
>
> Did you make sure you set the nadir shot in Hugin to use a
> "different lens"?

Yes, and the result was not better. But actually, I don't really
see why a different lens is necessary. After all, I prepared a
highly controlled situation:

1. Hugin knows which point of the image refers to which viewing
direction.
2. The sensor plane is parallel to the floor in both shots.
3. The distance between entrance pupil and floor is the same in both
shots.
4. I have set control points only in the floor plane.

So all that is unknown is the X, Y translation between both shots.
And, I only need a correct stitching for the floor area.

> Did you try a tutorial like e.g. these two:
> http://wiki.panotools.org/Stitching_Nadir_Shots
> http://wiki.panotools.org/Fixing_nadir_parallax_errors
>
> Translation is needed for something like this:
> http://www.flickr.com/photos/36383814@N00/5830006193

I don't see any difference to my nadir method. The front of Bruno's
buildings is my room floor.

[T. Modes]

Hi Torsten

> > Moreover, if I move the panorama in the move tab of the OpenGL
> > previewer, I misalign the nadir very quickly.  In fact, I have to
> > re-optimise after every repositioning of the panorama in the
> > previewer.
>

> I don't want to say that this is wrong but I also don't understand the
> cause of this.  I would have expected that the translated image is
> re-mapped on the sphere of the panorama, thus fixing it relatively
> to the others.
>

The image is remapped via a (fixed) plane to the panosphere.
See http://wiki.panotools.org/Stitching_a_photo-mosaic

If you rotate the pano (that's what happen when you drag in the fast
preview window) you change the orientation of the image to this
remapping plane and so you need to re-optimize again. But in this case
the remapping plane is not parallel to the plane in the image and this
will result in not-optimal remapping and you will get bigger errors.
So the translation parameters works only for nadir images are
correctly aligned to this remapping plane (if the plane is parallel
then it works only for yaw/pitch=0).

For this use case the default branch contains an option to also
optimize this remapping plane. It works in principle. But the
optimization can be fragile. I need some more test projects to try to
improve this optimization. Could you provide the pto file for testing?

Thomas

[Torsten Bronger]

Hall�chen!

T. Modes writes:

> [...]

>
>> I don't want to say that this is wrong but I also don't
>> understand the cause of this. I would have expected that the
>> translated image is re-mapped on the sphere of the panorama, thus
>> fixing it relatively to the others.
>
> The image is remapped via a (fixed) plane to the panosphere. See
> http://wiki.panotools.org/Stitching_a_photo-mosaic
>

> If you rotate the pano [...] you change the orientation of the

> image to this remapping plane and so you need to re-optimize

> again. [...]

Thank you for the explanations.

> For this use case the default branch contains an option to also
> optimize this remapping plane. It works in principle. But the
> optimization can be fragile. I need some more test projects to try
> to improve this optimization.

I installed the hg version of Hugin and I am excited about it -- the
remapping not only makes the stitching *much* more accurate, the
"moving around" works now, too. I think this is a powerful tool for
the general nadir problem. Thank you!

> Could you provide the pto file for testing?

I'll do so in a private mail as I don't have non-private pictures
available right now.