Hi Dale,

others have given you pieces of advice, most of it useful and generally valid.  
I think however that you may have found a bug.  I can consistently reproduce 
it here on my end on Kubuntu 10.4 using the trunk version of Hugin with many 
projects that would otherwise stitch well.


On August 15, 2010 11:53:26 pm Dale Beams wrote:
> As you can tell, after the optimization, things went haywire.

On the Assistant tab, there are two fields: Focal Length and Focal Length 
Multiplier.  Check their values.  Here they return incorrect values after 
loading my images.  I don't have time to look at it, but it may be a bug in 
reading the EXIF data.

This results in a too large V parameter which messes up the whole optimization 
process, on top of all other things that were already mentioned in this 
thread.

*WORKAROUND:*  In the Camera and Lens tab, set a small enough V (hfov).  In 
the Optimizer tab, make sure you optimize only position parameters (y/p/r) in 
the first run.  Another thing that helped me, since I knew that my camera was 
more or less level, was to not optimize R in the first run.


> What is going wrong at the alignment/optimizer stage.

It's a garbage in -> garbage out situation, with potentially multiple types of 
garbage:

1. BUG: the hfov / focal length is not read correctly from EXIF by Hugin.  
This is probably *the* garbage that gets into the process.  Other software may 
circumvent this by blindly assuming a small enough hfov for a start and 
optimizing only position in the first optimization run to obtain an initial, 
rough distribution on the panosphere before further optimization.

We'll have to fix this / make this more robust in the software. 


2. WRONG CPs: symmetry (as Andreas pointed out), or other false positives.  
This can be addressed in at least four ways complementing each other:

*1 cleaning them before optimizing, with the Clean CP and/or Celeste.

*2 adding strategical CPs manually before optimization.  I always add a couple 
of vertical and/or straight lines if possible.  It is usually very good at 
preventing the optimization going astray.  So far this can only be done by the 
user.

*3 starting optimization from a rough distribution of the images rather than 
from all images at (0,0,0).  What comes closest to this in Hugin is in the 
Images Tab the setting "Autopano-SIFT-C (multirow/stacked)".
  
*4 avoiding connections between non-adjacent images.  Siddharth asked a good 
question and indeed there is no need to match images which are not adjacent 
for good quality panoramas.  But how should the software know which images are 
not adjacent?  If they are shot in a regular pattern / time series, Thomas' 
newly introduced "Autopano-SIFT-C (multirow/stacked)" is one strategy to do 
that.  Control of the shooting process helps a lot but can't prevent garbage 
if the software blindly tries to match each image with every other image.


3. BAD OPERATION: Hugin has come a long way, but it is still first and 
foremost a tool for the discerning user who understands the details of the 
process and can intervene if the automatism fail.  This is where the advice 
expressed on this thread comes in.

I can add some of my own:

a. verify that the input images are plausible.  this include verification of 
the estimated projection (rectilinear or fish-eye?) and field of view.  it's 
nice to have EXIF, but don't rely blindly on it.

b. don't blindly trust the CP detector.  If the project is small, like in this 
case, consider running the CP detector manually on pair of images from the 
Images tab to avoid linking non-adjacent images, or use the new mode mentioned 
above.  *manually* set a few strategic CPs, particularly vertical lines.  If 
you know there are symmetries / similarities in the input images, do a manual 
check of the CPs on the concerned images after the automatic detection.


c. control the optimization. There are many different recipes to achieve 
optimal alignment in iterations.  The key here is not to optimize too many 
factors at the same time.  Position, View, Distortion, Viewpoint.  Maybe not 
in this order.  How and when viewpoint optimization is applied depends amongst 
other things on whether you expect all images to have been shot from the same 
no-parallax point, or whether you know that the viewpoint changed 
significantly between shots.

Generally, I first optimize Position only.  y/p/r - although if the camera was 
on a pano-head you can leave r fixed for a start and only optimize it toward 
the end of the process when fine-tuning.  Then view (v) only.  Then 
distortion: optimizing barrel only (b) first, an leaving the other distortion 
and shift parameters for later fine-tuning.  Then I optimize for viewpoint 
(X/Y/Z).  It's an iterative process.

Another thing that help is to calibrate the lens.  Then you will have preset 
values for v/a/b/c and won't need to optimize them other than in very special 
cases of fine tuning a less than optimal shoot.

Yuv

Attachment: signature.asc
Description: This is a digitally signed message part.

Reply via email to