[ptx] suggestions for stitching aerial photos

[Pablo d'Angelo]

Rik Littlefield schrieb:
> Rob Park wrote to me offline:
> 
>>When I was stitching the photos, it
>>
>>seemed like it was not even really necessary to correct the images at
>>all, only to position them for stitching (eg, they need to be moved
>>around relative to each other on a flat plane, but don't really need
>>much in the way of lens correction). Setting the lens to 2 degrees
>>seemed to have the best effect, but is there a way to tell hugin to
>>operate in a flat plane instead of the 360 degree universe that it
>>expects?
>>  
> I am replying on-list because I think the question is of general 
> interest.  It also exposes some difficulties with the hugin gui.
> 
> One way to do the stitching that Rob wants is to set a=b=c=0, do NOT 
> optimize pitch/yaw, but DO optimize roll/d/e individually for every 
> image except the anchor.

True, hugin uses a different mode for positition and "distortion" 
variables. Usually (for normal pano work), the distortion variables
are optimized together and not for a single image. Therefore the 
optimisation checkboxes for the distortion parameters (and HFOV) are 
grouped by different "lenses". These groups can be switched off and one 
as a whole. Additionally, these groups are used to link the parameters 
as well, if specified in the Lens tab.

I wanted to avoid the millions of checkmarks syndrome of PTOpenGui, the 
other free PT frontend, so I introduced that approach, while keeping the 
flexibility to work with multiple lens parameter groups.

Unfortunately that scheme doesn't offer the flexibility of needed for 
some other, more non standart, tasks. This is why I added the edit 
script function.

But maybe I should add an option to select the v,a-e parameters in the 
same way as the r,p,y parameters in the optimisation screen.

> This may seem bizarre, but if I have done the math right, it exactly 
> models what you want.  Varying roll/d/e corresponds to 2-dimensional 
> rotation and shifting when the input and output images are rectilinear 
> and there is no a/b/c correction.

Yes, I'm quite sure that this works.

> After optimization, the hugin preview still looks awful -- apparently 
> huge stitching errors despite good results reported by the optimizer.  

This is a bug that has been fixed in the newest snapshot, I think.
d,e are given in pixels, that means they depend on the image size. Hugin 
uses smaller images to build the preview (faster+saves memory). I didn't 
adjust the d,e values to the smaller image size, leading to larger 
shifts in the preview.

Actually it would be nicer if the center shift where specified relative 
to the image size instead, but its not a big deal.

ciao
   Pablo