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