<!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">
Pablo d'Angelo wrote:<br>
<blockquote type="cite" cite="mid433F890A.5060300@web.de">
<pre wrap="">Thomas Rauscher has build an experimental version with support for
antialiasing. I believe he sends rays through each corner of the pixels
and then adaptively determines a suitable filtersize.
See:
<a class="moz-txt-link-freetext" href="http://thread.gmane.org/gmane.comp.graphics.panotools/32862">http://thread.gmane.org/gmane.comp.graphics.panotools/32862</a></pre>
</blockquote>
Pablo,<br>
<br>
I have studied Thomas Rauscher's algorithm/code. Actually it is a lot
more elegant than just determining a "suitable filtersize". What his
method does is to correctly identify all and only those input pixels
that will contribute to an output pixel, then it combines them all with
appropriate weighting
to produce that output. It does this even where lens distortions are
extreme, such as near the edges of a fisheye image where the pre-image
of each output pixel is a very elongated and slightly crescent-shaped
ellipse. The method is extremely accurate. The only drawback I could
find is that it can be relatively slow especially where the pre-image
is very large, such as around the poles when mapping from
equirectangular to rectilinear. However, Thomas has applied some nice
optimizations that make even those cases not too painful.<br>
<br>
Several weeks ago I exchanged email with Thomas about this. To verify
that I understood his method, I re-described it like this:<br>
<blockquote>To compute the value of an output pixel:
<br>
1. Let the integer coordinates of the output pixel be called COC
(central output coordinates).
<br>
2. Transform COC into floating point coordinates within the input
image. Call the latter CIC (central input coordinates).
<br>
3. For all input pixels that "close" to CIC:
<br>
3a. Transform the input pixel's coordinates (IC) to output coordinates
(OC).
<br>
3b. Determine the output distance OD = OC - COC
<br>
3c. Use OD and the filter function to determine weight w.
<br>
3d. Accumulate w and w * (input pixel value)
<br>
4. Store output pixel value = (weighted sum of input pixels) / (sum of
weights)
<br>
<br>
"Close" in step 3 is defined as being any pixel that will have non-zero
weight. You find those using a flood-fill algorithm based on steps
3a-3c.
<br>
<br>
And you cache the transformed coordinates OC to speed things up.
<br>
</blockquote>
It is a fair question whether this algorithm is more accurate than it
needs to be -- perhaps a slightly less accurate algorithm could run
significantly faster and would be preferred in practice. One
possibility would be to do a slight modification of what Pablo suggests
-- shoot through the corners of each pixel to determine a suitable
filtersize and footprint (for example a tipped ellipse), and if the
footprint is large, then sample it randomly. <br>
<br>
In any case, what Thomas has produced is a very nice reference
algorithm that seems to be fully implemented and is usable as it stands.<br>
<br>
Thomas Rauscher's source code is available online at
<a class="moz-txt-link-freetext" href="http://sinnfrei.at/pano2qtvr/dll_patch/">http://sinnfrei.at/pano2qtvr/dll_patch/</a> and his email is given on that
page.<br>
<br>
--Rik<br>
<br>
<br>
<br>
</body>
</html>