[ptx] hugin 0.5 beta2

[Mike Runge]

Ok,
now it's getting crowded ;-)

===========================================================================
>> Usecase:
>> My method to create a spherical panorama goes like this:
>> - loading 6 images (4 at pitch==0 (from tripod), one zenith (from
>> tripod), one nadir(from tripod))
>> - arranging the anchor image with verticals
>> - optimising the anchor image
>
>for vertical & horizontal control points only right?
>
Yepp - excuse me for beeing inprecise. Sometimes I adjust yaw here
manually to 'center' the anchor. This can be done later in the viewer,
I know.

>With fisheye images autopano is not effective for me. it finds a lot of
>points near each other (due to spherical distortion or whatever it's
>called) and optimizer doesn't work well with those. In my experience
>it's better to place less than 10 points but away from each other -
>where the spherical distortion is largest, that way optimizer positions
>it correctly. Even after that if you run autopano on those points, and
>it will put 100 points but close to each other, I guess optimizer will
>count the average error and then it will decide that the 100 points
>close to each other have smaller error therefore are closer to reality
>than the ones on the borders where the spherical distortions is larger,
>which is not the case for fisheye imags. So basically I think user
>should let autopano place at most the same number of points that user
>placed manually, but it still may be the best if the user placed all
>points manually not using autopano at all.
>Did you have similar experience?

Yepp,
autopano worked fine on some examples, but you're right, the points are
to much in the middel. I'm getting better results with manually picked
points.
Autopano-sift generates better points - more widespreaded. But in most
cases, it just finds not enough points on fisheye images. Works well for
multirows, but I dont like, that it confuses the order of images :-(

>> - optimising the 'middle ring' (the 3 images for the middle, not the
>> anchor)
>> - re-optimize all 4 images of the 'middle ring'
>
>meaning the anchor image will have roll optimized right?
>

I don't checkmark Yaw for the anchor, but I optimize pitch and roll on
it together with the other 3 images. Ok?

>> - a quick stitch (small jpg) of the 4 images to see if the middle ring
>> has any problems
>
>I think we could definitely use panoglviewer to see the result of quick
>stitch - it would be very nice (or maybe embedding panoglview in
>panorama preview?). Panorama preview doesn't do a good job stitching.

Yes, panoglview is fast and of good quality. I think, it's Pablos and
Doug's plan to integrate it - it's already shipped with hugin ;-)
I would like to have the actual viewer as well. It's like you said
nearly useless for fisheye images, but very helpful for single- or
multirows. I would prefer the actual preview in that cases.

>What do you do when the middle of fisheye circle is not the middle of
>the rectangle of the picture? My "circles" are always moved towards the
>bottom by constant value and are moved sideways depending on the way it
>was developed I guess - this camera was not digital:
>http://www.castlesofpoland.com/5244-12.jpg

Maybe I'm wrong - I thought, that the x-y-shift parameters were
dedicated to correct this?!

>> - a checkmark in front of each image line in the images tab or reading
>> the selected images from preview
>> - While running the optimizer or stitcher, hugin would only use the
>> selected images and it's corresponding controlpoints.
>
>something like "don't use control points from current picture for
>optimizing". This should be in optimzer tab, because control points are
>not used for stitching - stitcher uses opimized variables (or am I wrong?)

Did you know PTBCGui/PTOpenGui (Juha Helminen)?
It has checkmarks in front of each row in the optimizer and as well
checkmarks in front of each row in the stitcher. To control what's
being optimised and what's being stitched. I think this looks very
overloaded and will confuse a beginner.
I would like to do both:
- influence what's being optimised
- influence what's being stitched
But I would like to have it centralized on one tab, like "what's being
used", for optimizer as well as for the Stitcher.
Image tab would be logically fine - but this will have a downside:
- you need to switch to the images tab (and back to optimise) to select
what's the base for optimisation - sounds crowded ;-)
- you need to switch to the images tab (and back to stitcher) to select
what will be stitched - sounds crowded as well ;-)

What about a popup-list "Used Images" or "In Scope", launched from
the panel (like the points-list)? Selecting/deselecting images from the
"In Scope" list should also set selected/deselected for the preview. I
thinks coupling the preview would be a good idea, because having some
images unchecked for optimisation and stitching can easily been
overseen?! The preview would show. "In Scope" would allow to tell
hugin 'globally' what images should be used - independent from what
images are loaded.
Doug, Marek? Did you like the idea?

>It's nice in ptgui that if you select fisheye images it shows the circle
>as opposed to rectangle, but the C option's paramers are still
>parameters of a rectangle, circle just makes it easier to choose the
>size and position for circular pictures.
>It would be even better if hugin could place the circle automatically,
>I'm sure there are formulas to tell where the black field end and where
>the pictures starts and then estimate it to a circle - ptgui doesn't
>have that.

Good idea - very straightforward! But it should be optimised to find
black around a circle - otherwise you would crop a lot of sky on
nightshots ;-)

>Same here. Although we would like to have our best panorama software
>even bester ;) (or even bestest;)

Yeah, Yeah, hugin go on .... :-))))

>Very good and very detailed comments - thanks Mike!

Thank you Marek,
it's fun to exchange some stuff with people riding on the same edge :-)

best, mike