[ptx] hugin 0.5 beta2

[spec at webtech.pl]

Mike Runge wrote:

>>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 :-(

I've never tried Autopano-sift, installing all the junk to test a small 
problem scares me a little

> 
> 
>>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?!

correct - the d and e parameters, but you didn't describe optimizing it 
in your process

also sometimes stitcher calculates and stiches it so some parts of black 
are is visible, so basically it's good to trim the pictures anyway.

> 
> 
>>>- 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?
> 

I'm really bad gui designer. For beginners things will be too crowded, 
advanced user will complain about no options, so I guess it would be 
nice to have two radio buttons that will show/(hide and make default) 
certain options to satisfy both cases.

> 
>>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 ;-)
> 

I never did fisheye nightshots so I never had this problem, but good 
catch ;)

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

I try to find some time to play around with this, but with my amount of 
spare time, I guess my thousands of fisheye pictures are not going to be 
stitched until hugin will be able to do it with 2-3 clicks of mouse all 
automatic :D

--
best regards,
Marek