Rune wrote:
> 
> How should POV-Ray antialiase pixels when the alpha channel is used?
> I think that it currently behave in an undesirable way.

How does POV-Ray determine the alpha channel setting to be output for
a given pixel?

I did some masking in my July IRTC entry.  To generate the masks I
textured all of the objects white with ambient=1, and set the background
to black.  I then converted the results of a GIF, and used that GIF as
the basis for a material_map.

Regards,
John

Post a reply to this message

I have a method for doing this, btw,on my site.

The demonstration is a bit dull:

http://www.spiritone.com/~english/cyclopedia/background.html

It at least gets rid of some of these steps

Josh

Rune wrote:

> How should POV-Ray antialiase pixels when the alpha channel is used?
> I think that it currently behave in an undesirable way.
>
> Example:
>
> (A) I render a white torus on a red background with AA on
>     and alpha channel on too.
>
> (B) In a paint program I want to put this background behind
>     my POV-Ray image.
>
> (C) Around my white torus there's a red halo - a leftover
>     from the red background I originally used. I don't like that.
>
> (D) Instead I think POV-Ray should produce images that works
>     this way (like in image D). However, it won't be changed
>     because the developers think it's better as it currently is
>     (like in image C).
>
> Now I've told you my opinion. What do *you* think? Should it be changed or
> not?
>
> Or even better: It could be optional. That should satisfy everyone. (Would
> it affect the speed? I don't know.)
>
> 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 July 23)
> / Also visit http://www.povrayusers.org
>
>  [Image]

--
Josh English -- Lexiphanic Lethomaniac
eng### [at] spiritonecom
The POV-Ray Cyclopedia http://www.spiritone.com/~english/cyclopedia/

Post a reply to this message

"Josh English" wrote:
> I have a method for doing this, btw,on my site.
>
> The demonstration is a bit dull:
>
> http://www.spiritone.com/~english/cyclopedia/background.html

It's a very nice technique, but not really related to the alpha channel.
Using the alpha channel lets you make a background for your POV-Ray image
*outside* POV-Ray, while your technique allows one to add a background image
*inside* POV-Ray. There's a big difference.

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

I know the difference, I was providing it as a grand work around to the general
problem. If you already have the image ready, you can add it to the scene with
my technique and not worry aobut the alpha channel. I'm not savvy enough in
programming to understand how POV-Ray does the Anti Aliasing and alpha channels,
so I fake it.

Josh

Rune wrote:

> "Josh English" wrote:
> > I have a method for doing this, btw,on my site.
> >
> > The demonstration is a bit dull:
> >
> > http://www.spiritone.com/~english/cyclopedia/background.html
>
> It's a very nice technique, but not really related to the alpha channel.
> Using the alpha channel lets you make a background for your POV-Ray image
> *outside* POV-Ray, while your technique allows one to add a background image
> *inside* POV-Ray. There's a big difference.
>
> 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

--
Josh English -- Lexiphanic Lethomaniac
eng### [at] spiritonecom
The POV-Ray Cyclopedia http://www.spiritone.com/~english/cyclopedia/

Post a reply to this message

Rune wrote:
> 
> How should POV-Ray antialiase pixels when the alpha channel is used?
> I think that it currently behave in an undesirable way.

It works the way it ought to.  When using alpha/opacity, you have four
channels in the image.  Three carry color, one carries alpha/opacity. 
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.

The alpha channel only tells you the amount of contribution of the
background to the final pixel.  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).

> 
> Example:
> 
> (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.

> 
> (B) In a paint program I want to put this background behind
>     my POV-Ray image.
> 
> (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.  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.

> 
> (D) Instead I think POV-Ray should produce images that works
>     this way (like in image D). However, it won't be changed
>     because the developers think it's better as it currently is
>     (like in image C).

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

Xander

Post a reply to this message

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

"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

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

"Alexander Enzmann" <xan### [at] mitreorg> 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

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