![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On Fri, 29 Sep 2000 08:28:05 -0400, Alexander Enzmann wrote:
>>
>> (A) I render a white torus on a red background with AA on
>> and alpha channel on too.
>
>If you are going to do compositing, you should probably use a black
>background. That way there's no extraneous color contributions.
That's not true. You'll get dark fringes as the black darkens whatever it's
averaged with.
>Then you shouldn't have used a red background. However, since you know
>the color you originally used for a background, you can remove it from
>the image:
> - multiply the original background color by the alpha value
> - subtract from the pixel
> - hope there weren't any out of range values anywhere along the way.
It seems that if this works manually, it should work for POV when +UA is
specified. I agree with Rune; I can't think of a single instance where it
would be a good thing to average in the background color when the user
requests an alpha channel.
>I disagree. That would be different from almost every image processing
>package in existence (besides not being possible without also storing
>the entire background along with every image).
I'm not sure I follow this statement.
--
Ron Parker http://www2.fwi.com/~parkerr/traces.html
My opinions. Mine. Not anyone else's.
Proudly not helping RIAA and SDMI steal my rights --
http://www.eff.org/Misc/EFF/Newsletters/EFFector/HTML/effect13.08.html
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"Alexander Enzmann" wrote:
> When using alpha/opacity, you have four channels in the image.
> Three carry color, one carries alpha/opacity.
I know.
> Once you have collected together background color and object
> color into a pixel (the three color channels), you can't
> (easily) separate them back out.
Yes you can. It can be done internally just as easily as externally.
> If you wanted to remove the background color from the pixel,
> you would also need to know the color of the background that
> got added in (three more channels in the image).
Not if POV-Ray itself remove the background from the colour channels. Then
you don't need to do it yourself later, and then you don't need any extra
channels.
> If you are going to do compositing, you should probably use
> a black background. That way there's no extraneous color
> contributions.
Yes there is. If I make a red sphere with 50% transparency on a black
background then the colour of the sphere will be darkened.
> > (C) Around my white torus there's a red halo - a leftover
> > from the red background I originally used. I don't like that.
>
> Then you shouldn't have used a red background.
There is leftovers from the background no matter which background colour I
use.
> However, since you know the color you originally used for a
> background, you can remove it from the image:
Why should I do it myself if POV-Ray can do it?
> That would be different from almost every image processing
> package in existence
So with other programs I have to remove the background manually while
POV-Ray could do it automatically? I wouldn't mind that.
> (besides not being possible without also storing
> the entire background along with every image).
Again, you don't need to store the background in some extra channels,
because it is already removed from the colour channels by POV-Ray and then
you don't need the information anymore.
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Ron Parker wrote:
>
> On Fri, 29 Sep 2000 08:28:05 -0400, Alexander Enzmann wrote:
> >>
> >> (A) I render a white torus on a red background with AA on
> >> and alpha channel on too.
> >
> >If you are going to do compositing, you should probably use a black
> >background. That way there's no extraneous color contributions.
>
> That's not true. You'll get dark fringes as the black darkens whatever it's
> averaged with.
Exactly as it should be - if 50% of the pixel is black (background), and
50% is red, then you should have a final pixel that is a dark red. If
you don't do that, your final image will always look aliased (jaggy).
Also, suppose you used, say, a mint green color as the background - how
would any program understand how to back it out (without knowing that
that mint green was used as a background) - the background color isn't
stored in the image file. How would you know how much to back out of
each color channel? And if you didn't store the background color in the
color channels, how would it ever appear as part of the final image?
Basically there are two ways typically used to store color +
alpha/opacity:
- color * alpha, alpha
- color, alpha
POV-Ray (as well as many other programs) uses the first method. It
produces images that look correct in typical image viewers.
Xander
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"Alexander Enzmann" <xan### [at] mitre org> wrote in message
news:39D89FB5.1E8AC150@mitre.org...
|
| Exactly as it should be - if 50% of the pixel is black (background), and
| 50% is red, then you should have a final pixel that is a dark red. If
| you don't do that, your final image will always look aliased (jaggy).
|
| POV-Ray (as well as many other programs) uses the first method. It
| produces images that look correct in typical image viewers.
My commonsensical way of thinking tells me this original idea is to have a
invisible factor, something to antialias with that isn't color at all but in
fact a transparency info layer. Which is what Alpha Channel seems to
advertise. Red edge should go semitransparent is all, and when overlayed
later via post process in a piant program for example then the red edges
would be only shades of clear red.
Sorry, I'm just here to blab a little.
Bob
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On Mon, 02 Oct 2000 10:46:13 -0400, Alexander Enzmann wrote:
>Basically there are two ways typically used to store color +
>alpha/opacity:
> - color * alpha, alpha
> - color, alpha
>
>POV-Ray (as well as many other programs) uses the first method. It
>produces images that look correct in typical image viewers.
I assume you mean "typical image viewers that don't understand alpha
channels." If your image viewer doesn't understand alpha, don't use it.
If it does, premultiplied alpha is ugly because it carries a bit of the
background along as a fringe. Different output options for different usage.
I know that when I load an image generated with +UA into, for example,
MS Image Composer (formerly Altimira Composer) it looks horrible unless I
turn off antialiasing while rendering (which somewhat reduces the usefulness
of +UA, as you can no doubt imagine.)
Perhaps the best solution would be to allow both options.
--
Ron Parker http://www2.fwi.com/~parkerr/traces.html
My opinions. Mine. Not anyone else's.
Proudly not helping RIAA and SDMI steal my rights --
http://www.eff.org/Misc/EFF/Newsletters/EFFector/HTML/effect13.08.html
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |