← Back to team overview

hugin-bug-hunters team mailing list archive

[Bug 679849] Re: correct processing of lens position movements between images

 

I believe this is now operation with "mosaic mode" correct?

** Changed in: hugin
       Status: New => Fix Released

-- 
correct processing of lens position movements between images
https://bugs.launchpad.net/bugs/679849
You received this bug notification because you are a member of Hugin Bug
Hunters, which is subscribed to Hugin.

Status in Hugin - Panorama Tools GUI: Fix Released

Bug description:
hugin is apparently missing an appropriate way of stiching images that are taken with an offset in the camera position and with non-zero roll/pitch/yaw (r/p/y) values between the images. I know there are description on the web proposing to use the lens d and e parameters to account for the camera position change, but this is not appropriate when at the same time the rpy values are non-zero, as I will describe hereafter.

The problem occurs for example when taking photos of a map and stich them together in order to get the complete map into a single image file. Usually, to give sufficient resolution across the entire photo, the camera needs to be moved across the map between the photo shots (rather than rotated). Furthermore, when the map needs to be photoed during poor ambient lighting conditions, the flash needs to be used. Then, in order to avoid flash glare, the map needs to be photoed with non-zero pitch or yaw. 

To get the final stiched map, the easiest work process would ideally be the following:

1) Let autopano define control points to align the images

2) Define one horizontal and vertical reference line in the corner photos in order to enable the optimizer to straighten the image (ideally would have to do this only in a single corner photo, but then we need to specify 3 lines and reference points for a 3. line are usually not easy to identify in a single map photo, furthermore small control point differences can accumulate and result in a curved image deformation of  the final stich, so it is better do define one horizontal and vertical reference line in each of the 4 corner photos.)

3) Let the optimizer optimize all except for a,b,c,g,t parameters (this because I assume the lense has negligible distortions).

And here is where the problem occurs: The optimiser will never find a satisfying result. Always hughe control point differences will be reported if the rpy values a significantly different from zero. And this is the reason:

The optimizer assumes that first the image is shifted by the values given by the d/e parameters it calculates and then rotated by the rpy parameter values. This is the wrong order of processing for the present task. In fact the optimizer must assume that first the image is rotated by the rpy parameters and then it is shifted. 

I assume the optimiser assumption is that all the lens specific parameters are applied first and only thereafter  the image specific parameters rpy are applied. In general this approach can be regarded to makes sense, but then we need an image specific x and y offset (not part of the 'lense' section) in addition to the rpy parameters. 

If the problem didn't come clear I can upload some image files on request.

I don't know if the tools that are called by hugin are able to do what I described would be needed to correctly stich this kind of setup. Anyhow I regard it a major shortcoming that this is currently not possible. The only workaround today that I devised is to straighten each image individually with hugin by optimising the rpy values using 3 reference lines per image, and then stich them together leaving the already found rpy values untouched in the optimiser. But of course this is an enormous amount of extra handwork and often it is impossible to find the necessary amount of reference lines in all images to get them straight.