> we are trying to render objects with transparency and composite them in a
> game using the alpha channel, but the current output produces inadequate
> results; the object displays fringes of the render background color.

If I'm understanding correctly what you want to do, as far as I know this is
not possible in POV-Ray (nor do I know any other software that can do it
accurately). That's why I happen to be working on a program that takes some
images of the same scene against different backgrounds and statistically
computes the best possible image-with-alpha that matches the input. See the
screenshot I posted in povray.beta-test.binaries. Of course this is not the
most efficient process because it requires at least 2 renders, but it
produces quite high-quality results. The number crunching already works
well, what's still missing is a decent user interface (and some
optimizations).

As for not supporting the PNG standard, I suppose you are talking about
what's described on http://www.libpng.org/pub/png/pngap3d.html by

> POV-Ray [POV-Ray Team] (Unix, DOS, Macintosh, Amiga, OS/2, Windows 9x/NT) -
> version 3.0 and later; read/write; full gamma support; partial, broken alpha
> support (only for anti-aliasing, not transparent objects, and premultiplied
> instead of non-premultiplied as required by PNG spec); up to 16 bits per
> channel (i.e., 48-bit truecolor); uses libpng and zlib; freeware with source.
> (This is one of the more famous ray-tracers in existence.)

I'm not from the POV-Team (and I don't know POV-Ray's source code at all),
but I suspect that enabling proper alphaing for transparent objects would be
quite a big project. Even worse if you also want transparent shadows. For
the antialiasing alpha being premultiplied however, the solution would be
simple: The fact (and the problem) is that the image is rendered as if there
were no alpha rendered, which results (if you use a black background) in an
output image that appears to have premultiplied alpha, but without any
intention on "premultiplying". Thus, the solution would be a simple
additional divide operation as described in the PNG specification (chapter
"9.4 Alpha channel creation" in png-1.2,
http://www.libpng.org/pub/png/spec/PNG-Encoders.html).

In a nutshell: I second this feature request!

 -Christian

Post a reply to this message