are there any plans to support straight alpha channel information as the PNG
format requires or will pov-ray remain in partial complience with the PNG
standard?  is there any known way to enable this functionality in v3.1 or
v3.5?

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.

- joshua kaelin

Post a reply to this message

On Fri, 28 Dec 2001 19:59:31 -0500, joshua kaelin wrote:
> are there any plans to support straight alpha channel information as the PNG
> format requires or will pov-ray remain in partial complience with the PNG
> standard?  is there any known way to enable this functionality in v3.1 or
> v3.5?
> 
> 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.

You posted this in povray.general, too.  In what way does the output from
the current beta of POV-Ray v3.5 not seem correct?

-- 
#macro R(P)z+_(P)_(P)_(P+1)_(P+1)+z#end#macro Q(C,T)bicubic_patch{type 1u_steps
6v_steps 6R(1)R(3)R(5)R(7)pigment{rgb z}}#end#macro _(Y)#local X=asc(substr(C,Y
,1))-65;<T+mod(X,4)div(X,4)9>-2#end#macro O(T)Q("ABEFUQWS",T)Q("WSXTLOJN",T)#
end O(0)O(3)Q("JNKLCGCD",0)light_source{x 1}// ron### [at] povrayorg

Post a reply to this message

> 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

On Sat, 29 Dec 2001 14:20:30 +0100, Christian Walther wrote:
> In a nutshell: I second this feature request!

In a nutshell: this group is not for feature requests, but even if it
were, we'd ask that you make sure the feature you request doesn't already
exist.  Don't take the word of the PNG group on this; they haven't looked
at v3.5 yet.

I ask again: in what way does the current behavior of version 3.5 not meet
your expectations?

-- 
#macro R(P)z+_(P)_(P)_(P+1)_(P+1)+z#end#macro Q(C,T)bicubic_patch{type 1u_steps
6v_steps 6R(1)R(3)R(5)R(7)pigment{rgb z}}#end#macro _(Y)#local X=asc(substr(C,Y
,1))-65;<T+mod(X,4)div(X,4)9>-2#end#macro O(T)Q("ABEFUQWS",T)Q("WSXTLOJN",T)#
end O(0)O(3)Q("JNKLCGCD",0)light_source{x 1}// ron### [at] povrayorg

Post a reply to this message

Ron Parker <ron### [at] povrayorg> wrote:
: I ask again: in what way does the current behavior of version 3.5 not meet
: your expectations?

  This seems to be a typical case of "hear somewhere that povray does not
work with this and that and complain without checking that it's true".

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

> In a nutshell: this group is not for feature requests, but even if it
> were, we'd ask that you make sure the feature you request doesn't already
> exist.  Don't take the word of the PNG group on this; they haven't looked
> at v3.5 yet.

I'm sorry! I apologize! I'm taking all back! It's there! It works! My post
grew a bit out of control yesterday when I added this and added that and so
I ended up talking about something that I didn't test in 3.5 yet. I'll be
more careful...

 -Christian

Post a reply to this message