Stiching fisheye images to a 360 degree image
Lars Tore Gustavsen
Sorry if this is a double post, but I think I used wrong address in
the first one.
I'm consider buying a sigma 8mm F 3,5 to use with my canon 10D (1,6
crop) for panoramic work.. Luckily enough I found some pictures from
almost the same combination online. Only differences are this lens is
the F4 version.
I have used hugin for years for printed panorama, and I have even
tested 360 degree with my 17-40. But this time I have a hard time
figuring out what's wrong.
I have downloaded some test images from bottom of this page:
http://www.chem.ox.ac.uk/oxfordtour/tutorial/index.asp?ID=37
The are locate here
http://www.chem.ox.ac.uk/oxfordtour/stitchingtest/sigma8mmsamples.zip
if the above url does' not work.
The author, Dr. Karl Harrison also has a tutorial about stitching this
images with ptgui.
http://www.chem.ox.ac.uk/oxfordtour/tutorial/index.asp?ID=42
My problem is that there is no ways I can easily create a so good
looking result with hugin. Actually the results I end up with are not
usable at all.
I'm using linux and have hugin 0.7 installed. I have tried to enable
"roation search" in the preference. I'm also use settings for a
circular fisheye 8mm lens. I crop them in the crop dialog. Whatever I
do, I can not find a good match with auto generated control points. I
typical end with an average error from 80 and up to above 800. :-(
Well I'm quite frustrated now, can this error be because this is
compressed jpg? Any other hint?
Or is the solution to always find the control point manually with
fisheye lenses?
Regards
Lars Tore Gustavsen
Bruno Postle
>
>I'm consider buying a sigma 8mm F 3,5 to use with my canon 10D (1,6
>crop) for panoramic work.. Luckily enough I found some pictures from
>almost the same combination online. Only differences are this lens is
>the F4 version.
I hear there is a big quality difference between the F3.5 and F4.
>I have downloaded some test images from bottom of this page:
>http://www.chem.ox.ac.uk/oxfordtour/tutorial/index.asp?ID=37
>I'm using linux and have hugin 0.7 installed. I have tried to enable
>"roation search" in the preference. I'm also use settings for a
>circular fisheye 8mm lens. I crop them in the crop dialog. Whatever I
>do, I can not find a good match with auto generated control points. I
>typical end with an average error from 80 and up to above 800. :-(
Me too, the automatic points were confused by the symmetrical
building. You need to look at all pairs of images and delete lots
of bogus control points. I'll attach a fixed-up .pto project for
this set of images that shows a good alignment.
--
Bruno
RizThon
I'm also often having issues stitching fisheye pictures...and here
with the sample pictures you give, indeed it's quite a mess, and some
pictures get upside down...I just opened the pics, and specified to
use a full frame fisheye, the 8mm and 1.59x are already there. Appart
from that I've got all the default settings (I got hugin 0.7).
Enabling rotation search (Preferences/Control Points Editor/Rotation
search) allows me to get a "less worse" result, ie I don't got upside
down images anymore, and the ceiling is where it should be...
On 23 jan, 17:10, Lars Tore Gustavsen <ltgustav...@gmail.com> wrote:
> Hello
> Sorry if this is a double post, but I think I used wrong address in
> the first one.
>
> I'm consider buying a sigma 8mm F 3,5 to use with my canon 10D (1,6
> crop) for panoramic work.. Luckily enough I found some pictures from
> almost the same combination online. Only differences are this lens is
> the F4 version.
>
> I have used hugin for years for printed panorama, and I have even
> tested 360 degree with my 17-40. But this time I have a hard time
> figuring out what's wrong.
>
> I have downloaded some test images from bottom of this page:http://www.chem.ox.ac.uk/oxfordtour/tutorial/index.asp?ID=37
>
> The author, Dr. Karl Harrison also has a tutorial about stitching this
Bruno Postle
>
>>I have downloaded some test images from bottom of this page:
>>http://www.chem.ox.ac.uk/oxfordtour/tutorial/index.asp?ID=37
>Me too, the automatic points were confused by the symmetrical
>building. You need to look at all pairs of images and delete lots
>of bogus control points. I'll attach a fixed-up .pto project for
>this set of images that shows a good alignment.
...I forgot to add that I rotated the source images 90° so they were
the right way up before I started with hugin.
--
Bruno
Lars Tore Gustavsen
> Me too, the automatic points were confused by the symmetrical
> building. You need to look at all pairs of images and delete lots
> of bogus control points. I'll attach a fixed-up .pto project for
> this set of images that shows a good alignment.
>
> --
> Bruno
>
Thank you very much for yor answer and the pto file.
I wonder are there another way to delete lots of bogus contol point
than try to find them in the contol point editor? I guess I ask this
since one of the screenshoot in the tutorial above was a "control
point table", sorted from largest error. I just found it a little time
consuming to find every image combinations, and look for errors.
In your last e-mail you mentioned that you rotate the images. I guess
this means that hugin don't read the exif roatation tag.
Thank you.
Lars Tore Gustavsen
Yuval Levy
> I wonder are there another way to delete lots of bogus contol point
> than try to find them in the contol point editor?
I use a Sigma 8mm and over time encountered many "symmetry errors". I
even provided a test-case set to Joost (PTgui) and it kept failing it -
but that was before I switched to Hugin. Autopano Pro failed the same
test as well last time I tried it, and Hugin too.
My current solution is to load the images without generating CP, and
then to trigger CP generation just for those image pairs that I know are
adjacent. In the Images tab shift-click two adjacent images and click
the "Create control point" button.
With the Sigma 8 the number of pictures is small enough to make this
manual intervention manageable and much less intensive than clearing out
errors, but of course it would be even better if the CP generation would
work with no human intervention.
I've tried to pre-position the pictures at approximate yaw/pitch/roll
positions, but it did not make a difference.
> since one of the screenshoot in the tutorial above was a "control
> point table", sorted from largest error. I just found it a little time
> consuming to find every image combinations, and look for errors.
Statistically excluding the largest error does not guarantee results in
the case of perfect symmetry. There is a 50% chance that the largest
error CPs are those on the wrong side of the symmetry, and 50% chance
that they are on the right side of the symmetry, resulting in either a
complete mess or a perfect match (i.e. stitching 1-4-3-2 vs. 1-2-3-4).
And if there is a four way symmetry (as in the middle of an inner court
of a building that has four sides looking all alike) things get even
more convoluted.
My finding is that the solution needs to make assumption about the order
of the pictures. The reasonable assumption I found is that picture are
shot in a time sequence, either clockwise or counter-clockwise, so
automating the pairwise detection of CP between time-contiguous
pictures, plus between the first and last image pair, should yield a
useful result in the majority of cases.
But it is still a special case, applicable only when the images are shot
in a predictable order. I often have frames out of time sequence (e.g.
when there are people moving and I make more than one round while
shooting and select the best frames).
Yuv
Bruno Postle
>I wonder are there another way to delete lots of bogus contol point
>than try to find them in the contol point editor? I guess I ask this
>since one of the screenshoot in the tutorial above was a "control
>point table", sorted from largest error. I just found it a little time
>consuming to find every image combinations, and look for errors.
There is ptoclean which is good for removing bad points (and it is
run by the match-n-shift -a option), but it doesn't work when you
have these symmetry problems, as Yuval says.
You could write a script that removes points from pairs of images
that shouldn't have them, but there are so many ways of arranging a
panorama, how would it know which are which?
>In your last e-mail you mentioned that you rotate the images. I guess
>this means that hugin don't read the exif roatation tag.
This isn't the problem. I use an unpatched libpano13 which refuses
to use photos with a horizontal angle of view greater than 160°.
The purpose of this restriction is to prevent the use of full circle
fisheye images, but it is so crudely implemented it refuses to use
these partial fisheye images unless we flip them to portrait
orientation first.
--
Bruno
Bruno Postle
>
> This isn't the problem. I use an unpatched libpano13 which refuses to
> use photos with a horizontal angle of view greater than 160°.
..actually libpano13 SVN has had this set to 720° for the last year
and I hadn't noticed.
--
Bruno