[ptx] simple nonlinear antialiasing that is good for pictures.

[Rik Littlefield]

Pablo d'Angelo wrote:

>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:
>http://thread.gmane.org/gmane.comp.graphics.panotools/32862
>
Pablo,

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.

Several weeks ago I exchanged email with Thomas about this.  To verify 
that I understood his method, I re-described it like this:

    To compute the value of an output pixel:
    1. Let the integer coordinates of the output pixel be called COC
    (central output coordinates).
    2. Transform COC into floating point coordinates within the input
    image.  Call the latter CIC (central input coordinates).
    3. For all input pixels that "close" to CIC:
    3a. Transform the input pixel's coordinates (IC) to output
    coordinates (OC).
    3b. Determine the output distance OD = OC - COC
    3c. Use OD and the filter function to determine weight w.
    3d. Accumulate w and w * (input pixel value)
    4. Store output pixel value = (weighted sum of input pixels) / (sum
    of weights)

    "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.

    And you cache the transformed coordinates OC to speed things up.

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.

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.

Thomas Rauscher's source code is available online at 
http://sinnfrei.at/pano2qtvr/dll_patch/ and his email is given on that page.

--Rik



-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www.email-lists.org/pipermail/ptx/attachments/20051002/8a539c87/attachment.html