There are many things concerning the alpha channel that I'd like to see
changed.

When the output-colour is calculated, the background should be ignored in
the output-colour, and only be stored in the output-alpha. Currently the
background is stored in both.

But then a new question arises - exactly *how* should the background be
stored in the alpha channel? How should it be calculated?

Currently the alpha channel behaves strange in many cases. If a transparent
or semi-transparent object is hit, the transmit value of the *first* hit
surface will be stored in the alpha channel. Fog also works strange. Media
is completely ignored I think. I haven't looked into all the different
POV-Ray features but it generally works in a strange and not very useful
way.

I think the alpha channel should take all surfaces and all other effects
into account. There are some problems related to this that I will try to
explain and suggest a solution for.

There are different kinds of transparency in POV-Ray. Some effects take up a
certain percentage of the output-colour. One example of that is surfaces
with transmit values. Another example is fog (that includes fog with no
transmit value).

However, there are also different kinds of transparency that adds,
subtracts, multiplies, or divides the output-colour with something. For
example media and surfaces with filter values.

The problem is that the alpha channel (not just in POV-Ray, but in general)
is designed for only the kind of transparency that takes up a percentage of
the output-colour. So the other kinds of transparency can not be stored in
the alpha channel - at least not without being converted first.

I think that POV-Ray, when the alpha channel is turned on, should convert
all kinds of transparency into the kind that can be stored in the alpha
channel. I know that it will not work 100% correct, but it's the only option
if we want to be able to use effects such as media together with the alpha
channel.

The good news is that there's a simple way to convert any kind of
transparency into the percentage kind of type that can be stored in the
alpha channel. The method is a very general one. For the percentage type of
transparency it will be calculated completely accurate. For other types of
transparency it will convert it in a somewhat meaningful way.

Here's the method. For a given camera ray do this:

Trace the ray and find out what the output-colour would have been if the
background had been set to be black. Also find out what the output-colour
would have been if the background had been white. Now subtract the first
colour-vector from the second. Let's call the resulting colour the
"difference-colour".

The difference-colour is the impact the background has on the output-colour,
so this is actually what we want to have stored in the alpha channel.
However, the alpha channel doesn't store vectors, only floats. We must
convert the vector into a float. For the percentage kind of transparency the
difference-colour will *always* be grey, so it's no problem to convert that
to a float - just take any of the 3 colour-components (or average them!).
But for the other types of transparency the difference-colour can be
anything. I think the best solution would be to take the average of the 3
colour-components.

And that's it actually. As you can see, no matter what effects are used, the
alpha channel can always be found by taking the average of the 3 colour
components of the difference-colour. Because the method is so general, it
will also automatically work when new features are implemented in POV-Ray.

So, what do you think of this solution? I'd like to hear your opinions.

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 August 7)
/ Also visit http://www.povrayusers.org

Post a reply to this message

"Rune" <run### [at] inamecom> wrote in message
news:39d4a5b8@news.povray.org...
|
| When the output-colour is calculated, the background should be ignored in
| the output-colour, and only be stored in the output-alpha. Currently the
| background is stored in both.
|
| But then a new question arises - exactly *how* should the background be
| stored in the alpha channel? How should it be calculated?
<snip>
| I think that POV-Ray, when the alpha channel is turned on, should convert
| all kinds of transparency into the kind that can be stored in the alpha
| channel. I know that it will not work 100% correct, but it's the only
option
| if we want to be able to use effects such as media together with the alpha
| channel.
|
| The good news is that there's a simple way to convert any kind of
| transparency into the percentage kind of type that can be stored in the
| alpha channel. The method is a very general one. For the percentage type
of
| transparency it will be calculated completely accurate. For other types of
| transparency it will convert it in a somewhat meaningful way.

How is it done in computer games?
Not something I know about but I can see the reasoning behind this
discussion.  If the alpha channel affected antialiased edges of objects in a
way that the edges were treated as semi-transparent when loaded into a post
processing program then no matter what background the image were pasted over
it would mix with it correctly.
That seems a lot different than what you are suggesting, but maybe because I
don't know what it is exactly.  Well, I am following it somewhat anyway.
The root of the matter still seems to be about the discontinuity at the
rudimentary level of alpha channeling, so you're saying to fill that void
with a purposeful color with the intent of doing the already possible
transparency info method in place of the plain background which always is an
inclusion anyhow except it's unavoidable.  And you think a proxy background
could be applied in the source to do a post process sort of thing.  Sorry if
I'm wrong in my interpretation, just trying to describe what I think you
mean.
Well, I don't understand how gray is any better than it being black or any
other color  :-)
My thoughts go toward the need for a self-color blending, which I think has
been mentioned before.  However that would be done... but to my point about
this: isn't some form of transparency already done in other things such as
game graphics, paint programs, etc?  I know that in PSP it's a simple thing
to use a semitransparent image and paste it onto another image but there
never is a implied background color beforehand.
Please excuse me for being late on the talk BTW, and for half listening in
on it until now.

Bob

Post a reply to this message

Reread my reply just now.  Please try to shorten any run-on sentences you
come across  ;-)  And good luck understanding anything I said.

Bob

Post a reply to this message

Rune wrote:
[Snip]
> So, what do you think of this solution? I'd like to hear your opinions.
> 
> Rune

Why not use "associated alpha" approach instead, which is used in
RenderMan (R) renderers (shaders actually): it premultiplies opacity
with color and outputs "dimmed" colors. 
Here is link, which describes image compositing and probably gives
answers to Your questions, no need to reinvent the wheel:
ftp://ftp.alvyray.com/Acrobat/4_Comp.pdf

Other papers could be found in Alvy Ray Smith's site at:
http://www.alvyray.com/
select Memos and then Microsoft.

Post a reply to this message

On Fri, 29 Sep 2000 19:24:45 +0200, Vahur Krouverk wrote:
>Why not use "associated alpha" approach instead, which is used in
>RenderMan (R) renderers (shaders actually): it premultiplies opacity
>with color and outputs "dimmed" colors. 

This is exactly what povray does with a black background, if I
understood the discussion correctly. The problem is that this is wrong
for PNG files, which require non-premultiplied RGB values (See RFC 2083,
Sections 2.4 and 12.8).

	hp

-- 

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

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

Post a reply to this message

On Fri, 29 Sep 2000 16:21:30 +0200, Rune wrote:
>Here's the method. For a given camera ray do this:
>
>Trace the ray and find out what the output-colour would have been
>if the background had been set to be black. Also find out what the
>output-colour would have been if the background had been white. Now
>subtract the first colour-vector from the second. Let's call the
>resulting colour the "difference-colour".
>
>The difference-colour is the impact the background has on the
>output-colour, so this is actually what we want to have stored in the
>alpha channel. However, the alpha channel doesn't store vectors, only
>floats. We must convert the vector into a float. For the percentage
>kind of transparency the difference-colour will *always* be grey, so
>it's no problem to convert that to a float - just take any of the
>3 colour-components (or average them!). But for the other types of
>transparency the difference-colour can be anything. I think the best
>solution would be to take the average of the 3 colour-components.

When converting an RGB value to grey, the components are usually
weighted <0.59, 0.30, 0.11>.

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 color
vectors for black and white background, respectively, we can compute:



    alpha = 1 - tr

    p = pb / alpha

now write p, alpha to the PNG file.

This could even be done now by rendering the scene with a black and
white background and calculating the final image plus alpha from the two
results.

Doing it in Povray will shave off the parse time, but every pixel will
still have to be computed twice. 

I am also a bit worried about reflective surfaces. They may erroneously
show up as "transparent".

	hp

-- 

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

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

Post a reply to this message

On Fri, 29 Sep 2000 22:25:29 +0200, Peter J. Holzer wrote:
>On Fri, 29 Sep 2000 19:24:45 +0200, Vahur Krouverk wrote:
>>Why not use "associated alpha" approach instead, which is used in
>>RenderMan (R) renderers (shaders actually): it premultiplies opacity
>>with color and outputs "dimmed" colors. 
>
>This is exactly what povray does with a black background, if I
>understood the discussion correctly.

Except for the bugs with multiple transparent objects, fog, media, etc.

	hp

-- 

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

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

Post a reply to this message

"Peter J. Holzer" wrote:
> 
> On Fri, 29 Sep 2000 19:24:45 +0200, Vahur Krouverk wrote:
> >Why not use "associated alpha" approach instead, which is used in
> >RenderMan (R) renderers (shaders actually): it premultiplies opacity
> >with color and outputs "dimmed" colors.
> 
> This is exactly what povray does with a black background, if I
> understood the discussion correctly. The problem is that this is wrong
> for PNG files, which require non-premultiplied RGB values (See RFC 2083,
> Sections 2.4 and 12.8).
> 

In this case I've lost point... Due to lack of time I read messages
"diagonally" and probably missed this description. Next time I try to
spend more time reading before jumping in.
Thanks for the clearance about PNG files, I've tried to search
information, how alpha is used in various formats but found only
information about TIFF format (it supports both associated and
unassociated alphas). Does anyone know, is TGA used with masking
transparency or associated alpha? (I guess that first is used)

Post a reply to this message

Hi Bob!

I'm afraid I don't understand so much of what you're saying, but I'll try to
answer what I can.

> If the alpha channel affected antialiased edges of objects in a
> way that the edges were treated as semi-transparent when loaded
> into a post processing program then no matter what background
> the image were pasted over it would mix with it correctly.
> That seems a lot different than what you are suggesting, but
> maybe because I don't know what it is exactly.

The method I describe will make AA work just the way you describe.

> Well, I don't understand how gray is any better than it being
> black or any other color  :-)

Not the background, but the transparency-vector. When that vector is grey
(or black or white) it means that the red, green, and blue components have
the same percentage of transparency, and that's exactly what the
alpha-channel supports. If they don't have the same amount of transparency,
the average of the 3 colour-components will have to be taken. That's not
very good, but there's no better alternative.

> isn't some form of transparency already done in other things
> such as game graphics, paint programs, etc?  I know that in
> PSP it's a simple thing to use a semitransparent image and
> paste it onto another image but there never is a implied
> background color beforehand.

The problem is that the image format is the limitation. They support
transparency, but only the percentage kind of transparency. You will never
see images that contains, say, filter transparency. Therefore all
transparency has to be converted to the percentage kind before it can be
stored in the output-image.

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 August 7)
/ Also visit http://www.povrayusers.org

Post a reply to this message

"Peter J. Holzer" wrote:
> When converting an RGB value to grey, the components are usually
> weighted <0.59, 0.30, 0.11>.

I thought about that. It may be better to weight the colours that way when
calculating the transparency. I don't know.

> 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)

>     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 and before or after it is clipped to the 0 to 1 range.

I'd like to make some more test, but it's a bit difficult. Does PaintShopPro
5 have a way of dividing one image with another? I can only find out how to
subtract.

> now write p, alpha to the PNG file.

Yes.

> This could even be done now by rendering the scene with a black
> and white background and calculating the final image plus alpha
> from the two results.

I've already tried something like that, and it seems to work.

> 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?

> I am also a bit worried about reflective surfaces. They may
> erroneously show up as "transparent".

That's something I had planned to talk about after this discussion (instead
of taking it all in one chunk).

I think it would be nice if the user in the global_settings could choose
between 3 solutions.

alpha_behaviour 1: (semi-)transparent and reflective surfaces will show up
as (semi-)transparent in the output-image. This may be useful for some
purposes.

alpha_behaviour 2: (semi-)transparent and reflective surfaces will show up
as solid in the output-image. This is probably useful for many purposes.

alpha_behaviour 3: For transparent objects with an ior of 1, it works like
alpha_behaviour 1. For other transparent objects and reflective objects, it
works like alpha_behaviour 2. This is probably the most useful behaviour.

Another idea would be to turn on or off alpha for individual objects.

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 August 7)
/ Also visit http://www.povrayusers.org

Post a reply to this message