[ptx] Looking for expertise on optimizer internals

[Littlefields - Rik, Janis, Kyle & Peter]

Juaquin,

For ordinary control points, the optimizer works with angular distances 
on the unit sphere.  For horizontal, vertical, and line control points, 
it works with panorama coordinates.  This is a bit schizophrenic, but 
it's conceptually simple and works well enough.

My modifications do not change this basic approach.  The difference is 
that Panorama Tools only tells the optimizer about the distance between 
two ordinary control points, whereas my mods also tell it the direction.

When I write "dx" and "dy", I really mean just two components in 
orthogonal directions that have the same scale.  In the code that I 
posted, the cdiff[1] component is in the direction of changing latitude 
(from pole to pole).  The cdiff[0] component is in the direction of 
changing longitude, and is scaled by sin(latitude) so that 
cdiff[0]==cdiff[1] represents the same angular distance on both axes, at 
least in the limit of small numbers.

Wraparound is always annoying, but it's not really a problem in this 
case because the optimizer only has to work with small differences.  The 
code just chooses whichever direction (eastward or westward) is less 
than half-way around the sphere.

The PTools image transforms can be found in math.c.  I have not studied 
the code in detail.  On quick scan, it looks like PTools' strategy is to 
represent the overall transformation between spherical coordinates and 
image coordinates as a stack of simpler transformations, each of which 
can be easily inverted.  PTools does the optimization by running the 
stack "outward" from source image coordinates to spherical coordinates, 
and computing projection parameters that minimize the angular difference 
in spherical coordinates.  Then during rendering, it runs the stack 
"inward", from panorama coordinates to spherical coordinates to source 
image coordinates, from which it gets the pixel values by interpolating 
in source image space.  [Anyone -- if you can confirm or correct this 
interpretation, please chime in.]

I have no idea what hugin does.

--Rik


juaquin anderson wrote:

>my background is in mathematics.  
>i have experience with things like optimization algorithms and convergence.
>
>i am not familiar with this code, but i am curious about it.
>
>i have wondered why the optimizer doesn't optimize in three dimensions on the unit sphere?  or does it?  it seems like it should.  there are always going to be things like wraparound and azimuths when you use just 2 dimensions dealing with something spherical.  
>
>with dx and dy there is a problem with wraparound and azimuths.  but with (dx,dy,dz) being distance of points on the unit sphere there isn't any special case.
>
>i would like to see the exact form of the PTools image transforms.  they are a 2d to 2d transformation, but it comes from 3d relationships of image projections.   
>
>the other thing that is interesting is the convergence.  there seems to be a fast pairwise optimizer in hugin,  and then other optimizers that are slower.  i wonder what the difference is.  i would like to know.
>
>thanks
>juaquin
>  
>"Littlefields - Rik, Janis, Kyle & Peter" <rj.littlefield at computer.org> wrote:
>
>  
>
>>I am working on internal improvements to the Panorama Tools optimizer, 
>>and I am looking for other people to talk with about this.
>>
>>Briefly, I have working prototype code that changes the way that the 
>>lmdif optimizer is called.  The original code seeks to optimize distance 
>>squared, where distance is what lmdif sees.  My mods also seek to 
>>optimize distance squared, but the formulation is to optimize dx^2 + 
>>dy^2, where dx and dy are what lmdif sees.
>>
>>The change in formulation gives lmdif better information about how to 
>>change the parameters, leading to faster and more accurate convergence.
>>
>>But of course there are wrinkles dealing with wraparound and near-polar 
>>points, and I would like to tap into whatever other people know about 
>>the optimizer, to be sure that I don't mess things up..
>>
>>If you have experience with the guts of adjust.c and are willing to 
>>share it, please chime in.
>>
>>Thanks very much,
>>
>>-- Rik Littlefield
>>
>>
>>
>>    
>>
>
>__________________________________________________________________
>Introducing the New Netscape Internet Service. 
>Only $9.95 a month -- Sign up today at http://isp.netscape.com/register
>
>Netscape. Just the Net You Need. 
>
>New! Netscape Toolbar for Internet Explorer
>Search from anywhere on the Web and block those annoying pop-ups.
>Download now at http://channels.netscape.com/ns/search/install.jsp
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.email-lists.org/pipermail/ptx/attachments/20040428/194b5b89/attachment.htm