[ptx] hugin 0.5 beta2

[spec at webtech.pl]

Hi,

  I'm going to add my two cents here:

Mike Runge wrote:
> First of all, I try to describe my current method to stitch a sphercal
> image based on 7 images taken with a fisheye lens to make it more
> understandable, what I'm looking for.
> 
> ===========================================================================
> 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?

> 
> - placing all points for the 4 images at the middle (e.g autopano)

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?

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

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

>   This means, I remove the last 2 images, do the stitch and then do UNDO
> to get the 3 images back.
> 
> - adding controlpoints for zenith
> - optimising zenith only
> 
> - adding controlpoints for tripod-nadir
> - optimizing tripod nadir only
> - optimizing all 6 images together
> - stitching all 6 images as high quality multiple tiffs
> 
> - removing all images except the nadir
> - adding an additional nadir image taken freehand (new lens)
> - adding controllpoints between the 2 images
> - optimizing the freehand nadir only
> - stitching the freehand-nadir only as multiple tiff
>   this means removing tripod-nadir, stitch, UNDO to get the tripod-nadir
> back in.

I do 7 images but both bottom ones are freehand rotated 180 degrees from 
each other. So basically both of them have my feet visible. This is 
where script's C option comes handly - I just mark the field that can be 
used for placing points and later stitching. With hugin I have to first 
cut out the feet part from the image before adding it to hugin project.

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

> ============================================================================
> 
> So, here are my wishes to optimise this workflow :-)
> #1
> It would be helpful for some methods to tell hugin what images in the
> project should be included/excluded while running the optimiser or the
> stitcher. Here is an idea to archive 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?)

> - If only a single image would be selected, hugin would only optimize
> this image by using it's horizontal/vertical controlpints disregarding
> all other points.
> - If 2 or more images are selected, hugin would disregard all
> non-selected images and controlpoints, that correspond with this images.
> Hugin also would use the selected images for stitching.
> 
> This would allow me to load all 7 images at the beginning of the project,
> run autopano once and follow my method without any removing of images
> and without any predefined sequence of controlpoint creation. It would
> much more helpful on large multirows, where I reach best results
> optimising one row after an other instead of all together.
> 
> #2
> I need to crop the black areas in fisheye images manually. This can be
> done at a very first step or at the end based on the distorted
> multirows. PTGUI has a method implemented to crop the black areas within
> the tool. PTStitcher and nona can crop images - no idea how to tell them
> how they should crop. 

that's the C option - I'm not sure if nona has support for it?

 > As a first approach, I would think defining a
> radius or diameter (maybe moving with x-y-shift) would be good enough.
> Maybe the preview can show the crop?! As far as I understood Pablo, this
> is one of the features he want's to implement next (he already bought a
> Peleng fisheye ;-))

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.

[...]

> 
> So the only method to do sphericals in hugin today is:
> - loading circular images (taken in portrait mode) in landscape mode
> - using PTStitcher
> This works, but it's quite uncomfortable to pick controlpoints by hand
> (you need to hold you head sideways).Maybe the controlpoints tab could
> show the images rotated, according the roll-parameter?!

something like that would be useful. Or even after optimizing for the 
first time and user is happy with v,b, y,p,r and d,e parameters, hugin 
could show the remapped images for point selection and then when point 
is selected remap it back to the point on original picture. Or even 
better after acceptable initial optimization - especially for v 
parameter, hugin could send the remapped images to autopano, and then 
remap the output of autopano back to original images. Anyway that's may 
be much too much work for 0.5 stable

> Beneath all this:
> It's fun to work with hugin and meanwhile, It's able to do all I really
> need  and I'm getting famous results :-)

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

Very good and very detailed comments - thanks Mike!

--
best regards,
Marek