On Sat, 30 Sep 2000 13:17:12 +0200, Rune wrote:
>"Peter J. Holzer" wrote:
>> I like it. However, now we have two RGB triplets for every pixel,
>> and none of them is the correct value to store in a PNG file.
>>
>> It is pretty easy to compute however. If pb and pw are the RGB
>> colour vectors for black and white background, respectively, we
>> can compute:
>>

>>
>>     alpha = 1 - tr
>
>Well, that's exactly what I was trying to say in my explanation. :-)
>
>However, I think this would be more correct (because the vector
>components are averaged):
>
>    tr = (pw-pb) * <0.59, 0.30, 0.11>
>
>    alpha = 1 - (tr.red + tr.green + tr.blue)


think we are talking about the same thing (tr is a scalar then).

>>     p = pb / alpha
>
>I hadn't thought about doing it just that way, but it seems like it creates
>the same
>result as I was thinking of. However, I can't figure out if it is more
>correct to divide by the Alpha before or after Alpha is converted to
>grey-scale

After. The alpha value must affect all three channels alike.

>and before or after it is clipped to the 0 to 1 range.

Not sure about that.

>> Doing it in Povray will shave off the parse time, but every pixel
>> will still have to be computed twice.
>
>I don't know the details about the raytracing process, but does the ray
>really have to be traced twice just to find the result with two different
>BG-colours?
>
>Isn't a ray made up of several steps (several rays) where only one step
>would have to be calculated twice?

Depends on how you do it. 

If you simply compute every ray twice, you can centralize the change at
a single point - just before writing the pixel to the file.

If you want to optimize it, you will have to change a few data
structures and probably lots of code. But then you need to do the
intersection tests only once per ray, and you may save some (or even a
lot) of the color computations, too.

The extra data and checks will probably slow down normal renders down a
bit. 

	hp

-- 

|_|_) | Sysadmin WSR       | vor dem rechner.

__/   | http://www.hjp.at/ |       at.linux, 2000-09-24

Post a reply to this message

"Rune" wrote:
> It may be better to weight the colours that way when
> calculating the transparency. I don't know.

I've done some more tests and found out that it's better to evenly weight
the colours when averaging them; that is, red, green, and blue all weight
33%. The reason is that the transparency of an object should not be
dependant on the colour of the object. If I make a red, green and blue
filtering sphere with the same amount of filtering, I want them all to be
equally much transparent in the output-image.

> However, I can't figure out if it is more correct to divide
> by the Alpha before or after Alpha is converted to grey-scale

By doing some more tests I've found out that the image should be divided
with the "alpha-vector" *before* it is converted to a float. That way the
background-colour is correctly removed from the output-colour.

So I think it should go like this:

   white_result: the traced colour when the background is white

   black_result: the traced colour when the background is black

   opacity = 1 - (white_result - black_result)

   output_colour = black_result / opacity

   output_alpha = ( opacity.red/3 + opacity.green/3 + opacity.blue/3 )

   now write output_colour and output_alpha to the PNG file.

Greetings,

Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated September 25)
/ Also visit http://www.povrayusers.org

Post a reply to this message

"Peter J. Holzer" wrote:
> > I can't figure out if it is more correct to divide by the
> > Alpha before or after Alpha is converted to grey-scale
>
> After. The alpha value must affect all three channels alike.

After some more experimenting I believe you are right. I also found out that
the method we are talking about is indeed not very good at handling filter
transparency. As the filter value goes towards 1, the colour of the object
in the output-image goes towards black! Of course the not-so-good results
are understandable, since the alpha channel really is not made for filter
transparency.

> If you simply compute every ray twice, you can centralize the change
> at a single point - just before writing the pixel to the file.

But that's a render time increase of 100%!

> If you want to optimize it, you will have to change a few data
> structures and probably lots of code. But then you need to do
> the intersection tests only once per ray, and you may save some
> (or even a lot) of the colour computations, too.

So turning the alpha channel on would maybe not increase render times
considerable when doing it this way...

> The extra data and checks will probably slow down normal
> renders down a bit.

New features such as all the new reflection and refraction options in
MegaPOV don't seem to slow down the rendering at all when not used. Maybe
the new alpha channel feature wouldn't either. But as I said, I don't know
anything about the details here.

Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated September 25)
/ Also visit http://www.povrayusers.org

Post a reply to this message