<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
Juaquin,<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.]<br>
<br>
I have no idea what hugin does.<br>
<br>
--Rik<br>
<br>
<br>
juaquin anderson wrote:<br>
<blockquote type="cite"
cite="mid79A9FCA7.1F907A3C.40CC31E1@netscape.net">
<pre wrap="">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" <a class="moz-txt-link-rfc2396E" href="mailto:rj.littlefield@computer.org"><rj.littlefield@computer.org></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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
</pre>
</blockquote>
<pre wrap=""><!---->
__________________________________________________________________
Introducing the New Netscape Internet Service.
Only $9.95 a month -- Sign up today at <a class="moz-txt-link-freetext" href="http://isp.netscape.com/register">http://isp.netscape.com/register</a>
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 <a class="moz-txt-link-freetext" href="http://channels.netscape.com/ns/search/install.jsp">http://channels.netscape.com/ns/search/install.jsp</a>
</pre>
</blockquote>
</body>
</html>