Hugin misinterprets points and rotates the image chaotically...
VeVe
I'm using hugin Version 2009.2.0.4461 ( http://hugin.sourceforge.net )
by Pablo d'Angelo and... i can't seem to get things right. I'm getting
all kind of results... from images bended in weird ways to "panoramas"
that stick the last image with the first.
Doing things manually doesn't help very much. I'm setting up all the
points between to sequent images and when i hit "optimize" all my work
seems to be useless. The photos rotate up to 180 degrees :|
Hm... i have these photos. http://picasaweb.google.com/Akaveve/TestPanorama?feat=directlink
Try to create a panorama out of them :| and please explain how you
managed to create the panorama (in the positive case)
Thank you...
VeVe
doing something right... Check it out, please :)
Video here:
http://www.filedropper.com/buz
or
http://freestorage.ro/df0gkfydu1rl
or
http://dl.transfer.ro/buz-Transfer_RO-07Jan-a7cbd6.avi
or
http://www.mediafire.com/file/zozinnmijfj/buz.avi
Stefan Peter
I have downloaded your images and fed them to hugin 2009.4.0.4742. It
seems that putting the images to picasa has removed most of the exiv
data: therefore, I was prompted with the "camera and lens data" dialog
[1]. Because there were no additional information at this time, I
entered a HFOV of 60 degrees and a focal length multiplier of 1.0 which
resulted in a focal length og 29.98 mm. I had to enter this data 3 times
until hugin was satisfied.
Still in the "Assistant" tab, I pressed the "Align..." button next. My
preferences define the Autopano-sift-C as the default control point
detector. I still use V 2.5.1 because later versions do not work with my
fish-eye. However, I was rewarded with a mean error of 2.5 pixels and a
maximal error of 12.4 pixels. Hugin rewarded me with the "Good fit"
message as a result [2], so I decided to use the third button, "3.
Create panorama ..." in response, without bothering with any additional
optimizations.
The resulting panorama [3] is not really breath taking quality, I have
to confess, but far better than the one you showed in your desktop
movie. If you want to try out the pto yourself, see [4].
How comes?
Well, I think one of the key reasons is the fact that I have resigned
from trying to outsmart hugin. Of course, the control points could have
been optimized (as could have been the images themselves). but this is
for a second step. Going the easy "press three buttons" way has given me
a starting point that looks basically OK and can be optimized later.
Another issue may be the version of autopano-sift-c I used: I know that
the actual repository version does not play with fish eyes, but there
may be additional issues that affect rectilinear images, too. So , I
stay away from more modern versions until an official release has been
announced.
And, last but not least, the issue with the exiv data. You have noticed
that I had to make up the values for the camera and lens data because
they are missing on the images downloaded from picasa. This may have an
influence as well, because wrong orientation or lens data has been
blanked out in my case.
After having had a short look at your movie, I noticed that your video
(at about 1:00) not only shows 7 control points between image 0 and 1,
but 3 points as well between image 0 and 3. The latter are wrong points,
obviously, and may be the reason for your problems. So, my entirely
unprofessional verdict is that your control point detection has failed.
Reasons for this may be
- wrong exiv data
- wrong SW version of autopano-sift-c
- you did not remove the points with large errors
With kind regards
Stefan Peter
1: http://stepet.dnsalias.com/VeVe/prntscr1.jpg
2: http://stepet.dnsalias.com/VeVe/prntscr2.jpg
3: http://stepet.dnsalias.com/VeVe/V1a.tif
4: http://stepet.dnsalias.com/VeVe/V1a.pto
Stefan Peter
...
> Thank you for your time. I appreciate your response. You mentioned
> that i have 7 control points between 0 and 1 and.... 3 control points
> between 0 and 3. I admit that i don't know what the green bar means
> (probably this is what you noticed)... i will investigate further.
This is easy: If you pull down the image selector on let's say the right
image in the "Control Points" tab, you will get a list of all other
images in the pano. And you will see the number of links that connect
the left image with the other images.
OK, this sounds a little complicated. Let's have a look at the example
mentioned above.
Go to the "Control Points' tab and select image 0 in the left half of
the window. After this, if you use the selector for the right image, you
will be presented with a list containing all images in your project. But
on the right hand of the combo box, there will be numbers and bars for
some images, or nothing for other images. If there is nothing, this
means that there are no control points from the left image to the one in
the combo box. A number in the right part of the combo box shows you the
number of points that are shared between the left image and the one in
the combo box. And the color of the bar indicates the quality of this
control point connection. However, until you did not optimize the pano,
they all will be green indication an error distance of 0.0, the default.
In the case that I have mentioned, however, the color of the bar or the
number of "connections" between the two images does not really matter.
The problem is, that from the way your images have been shoot, there is
no way that something visible in image 0 is visible in image 1 AND in
image 3, BUT NOT in image 2. If your hugin projects shows shared points
between image 0 and image 3, the optimizer will fail to place the images
correctly and you end up with a pano that does not make sense.
So, from what I can see, these control points between image 0 and image
3 are bogus. The only question is, how and why did hugin get those points?
>
> About the EXIF data... it's ALL there. Nothing is lost. You need to
> download the full version of the photo (DO NOT click "save image
> as..." or something like that) using the Download button. Look here --
>> http://img96.imageshack.us/my.php?image=01072010221913.jpg .
This does not really matter. and, as I have written before, it may be
the reason that my project succeeded. I have encountered weird behavior
before when the image orientation tag in the exiv data was wrong.
> Hm... in my video you can see the focal length and the multiplier a
> few times... so you must have missed this info also :)
Well, I have started my investigation before I gout your second email.
But I think that this doesn't matter much,
>
> BUT it doesn't matter. As I said... i appreciate your response :) and
> your effort. I'm downloading your resulted image (30 KB/s) and i can't
> wait to see what you've done :)
Sorry for the lame internet connection. There is nothing I can do
against this at the moment, though.
VeVe
It was the points connecting the wrong images (like image 0 with image
2, etc...). After i deleted them the result was much better ->
http://imigi.ro/files/5813/ss_fused.jpg
> Stefan Peter wrote:
>> "OK, this sounds a little complicated. Let's have a look at the example
>> mentioned above."
It was very simple ;)), don't worry. Now that i understood that,
everything seems perfect. So... it wasn't the programs fault. But for
noobs the Subject of the topic is still pretty good. They will find it
with ease on google.
Bogdan.