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.
_______________________________________________
Mailing list: https://launchpad.net/~hugin-bug-hunters
Post to : [email protected]
Unsubscribe : https://launchpad.net/~hugin-bug-hunters
More help : https://help.launchpad.net/ListHelp
