Thorsten Froehlich <tho### [at] trfde> wrote:
: I have to object:  The idea was first introduced in the Mac version of a
: POV-Ray 3.1 beta about three and a half years ago.

  I apologize. :)

-- 
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}//                     - Warp -

Post a reply to this message

I pointed this bug out a while ago... it only takes into account the color
when anti-aliasing. It was agreed, I believe, that in the future it should
take the alpha value into account when anti-aliasing. But nothing was done
about it in beta 7.

- Slime
[ http://www.slimeland.com/ ]
[ http://www.slimeland.com/images/ ]

"Alex Falappa" <afa### [at] remove-medatamatit> wrote in message
news:3bea5a84$1@news.povray.org...
> Hi all,
> while experimenting with producing an alpha channel in output images I
came
> across what seems a bug (maybe related to that reported by John David
> Haiducek in the thread "Alpha output"):
> - text object are not antialiased against the background (they do against
> other objects) using alpha output on and method 1
> - text object are antialiased oddly against the background using alpha
> output on and method 2
>
> Environments:
> Pov 3.5beta7, Win2000professional, Dual celeron 400 mhz, 320 Mb RAM
> Pov 3.5beta7, Win98SE, PentiumIII 650mhz, 384 Mb RAM
>
> Test scene:
>
> #version 3.5
> // try to render with:
> // +UA +A0.1 +R3 +FN8
> // +UA +A0.1 +AM2 +R3 +FN8
>
> global_settings {
> //  assumed_gamma 1.0
>  max_trace_level 4
> }
> background { color rgb <1,1,1> }
>
> // ----------------------------------------
> camera {
>   orthographic
>   location <0,0,1>
>   look_at  <0,0,0>
>   right 1*x
>   up 1*y
> }
> // ----------------------------------------
>
> box {
>   <-0.5, 0, 0>, <0, 0.5, 0>
>   texture {
>     pigment {
>       checker color rgbt <.6,.5,.4,.2> color rgbt <.8,.9,1,.2>
>     }
>     finish {
>       ambient 1.0
>       diffuse 0.0
>     }
>  scale .25
>   }
> }
> box {
>   <0, 0, 0>, <0.5, 0.5, 0>
>   texture {
>     pigment {
>       checker color rgbf <.6,.5,.4,.2> color rgbf <.8,.9,1,.2>
>     }
>     finish {
>       ambient 1.0
>       diffuse 0.0
>     }
>  scale .25
>   }
> }
> box {
>   <-0.4, 0.35, -0.1>, <0.4, 0.45, -0.1>
>   texture {
>     pigment {
>       color red 1
>     }
>     finish {
>       ambient 1.0
>       diffuse 0.0
>     }
>   }
>   rotate 15*z
> }
> box {
>   <-0.4, 0.2, -0.1>, <0.4, 0.3, -0.1>
>   texture {
>     pigment {
>       color green 1
>     }
>     finish {
>       ambient 1.0
>       diffuse 0.0
>     }
>   }
>   rotate 15*z
> }
> box {
>   <-0.4, 0.05, -0.1>, <0.4, 0.15, -0.1>
>   texture {
>     pigment {
>       color blue 1
>     }
>     finish {
>       ambient 1.0
>       diffuse 0.0
>     }
>   }
>   rotate 15*z
> }
> text {
>   ttf
>   "Arial.ttf",
>   "POV-Ray",
>   1,
>   0
>   scale .2
>   translate <-.4,-.3,0>
>   texture {
>     pigment {
>       color rgb 0
>     }
>     finish {
>       ambient 1.0
>       diffuse 0.0
>     }
>   }
> }
> text {
>   ttf
>   "Arial.ttf",
>   "POV-Ray",
>   1,
>   0
>   scale .2
>   translate <-.2,-.06,0>
>   texture {
>     pigment {
>       color rgb 0
>     }
>     finish {
>       ambient 1.0
>       diffuse 0.0
>     }
>   }
> }
>
>
>

Post a reply to this message

In article <3beadbc2@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

>   This is a partial snapshot of the winpov preview window (which has been
> maximized to show the pixels more clearly). The behaviour is exactly the same
> as in the unix version.
>   And no, it's not something with the preview. When opening the image with
> another program (eg. Gimp), the result is identical to that.

I see.  I finally was able to reproduce your problem.  There is indeed
something very wrong with the alpha channel output.  The Mac version allows
to view the alpha channel even if POV-ray does not explicitly outout one.
When activating alpha channel output the whole output is suddenly screwed
up.  Obviously this is not right, so i can confirm this is a bug - alpha
channel output is completely broken.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
: alpha channel output is completely broken.

  Completely broken? I haven't had _any_ problem with it. This is the only
case where there has been a problem (and seems a quite trivial problem; the
background seems to be considered black when +ua is on).
  Are you having some other problems besides the ones described here?

-- 
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}//                     - Warp -

Post a reply to this message

In article <3beafd4e@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

>   Completely broken? I haven't had _any_ problem with it. This is the only
> case where there has been a problem (and seems a quite trivial problem; the
> background seems to be considered black when +ua is on).
>   Are you having some other problems besides the ones described here?

Yes, as you know, I can turn off the alpha-channel preview.  basically, if
you look at an image that was rendered then, the plain background will be
all black because of this.  Obviously the image should still "make sense" if
no alpha channel is available.  At least in image editing programs it does
work that way.  And it did work in 3.1...

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
: Yes, as you know, I can turn off the alpha-channel preview.  basically, if
: you look at an image that was rendered then, the plain background will be
: all black because of this.  Obviously the image should still "make sense" if
: no alpha channel is available.  At least in image editing programs it does
: work that way.  And it did work in 3.1...

  Sorry, but I don't follow. What exactly is happening "wrong"?

  IIRC, when using alpha channel, the completely transparent pixels are
colored black by design. Pixels that are half-transparent will not take
into account the color of the background (because basically there is no
background to take color from; the background is transparent) but this
is handled with the alpha channel. That is, the pixel will have the color
of the object(s) and some alpha value (which is used to mix this color
with whatever will be behind). This means that if the alpha value is not
taken into account when drawing the pixel, the edge of objects against
the background will look jagged and non-antialiased. This is completely normal.

-- 
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}//                     - Warp -

Post a reply to this message

In article <3beb9ed6@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

> This is completely normal.

Well, if you look at the images I posted, don't you agree that the result
looks like it should look like and indeed does look like in image editing
programs?  There is no other program that I know that sets the color of
pixels that are "invisible" to black, and doing so causes lots of problems
as no other program (that I have) expects it that way.  In particular is
makes the images unusable without alpha channel display always on...


    Thorsten


____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
: Well, if you look at the images I posted, don't you agree that the result
: looks like it should look like and indeed does look like in image editing
: programs?

  I'm sorry but I don't quite understand.
  What I see in the snapshots you posted is that the version which doesn't
use the alpha channel for preview does something weird. Pixels which are
antialiased against the background use the alpha channel, and the alpha
channel alone, for this. The color of these pixels is _not_ changed due to
antialiasing, but only the proper alpha value is calculated for them.
  This means that if alpha channel is turned off in the preview, the edges
of objects against background should not look smooth (because it's precisely
the alpha channel which makes them smooth, not the color of the pixels).

:  There is no other program that I know that sets the color of
: pixels that are "invisible" to black

  If a pixel is completely transparent, it doesn't really matter what is
its color. It could be black, white, cyan or orange; if it's completely
transparent, then it's completely transparent; the color has no effect
whatsoever.

: and doing so causes lots of problems
: as no other program (that I have) expects it that way.

  What problems?

:  In particular is
: makes the images unusable without alpha channel display always on...

  But that's absolutely normal!
  The alpha channel contains essential information about the image. It tells
how the pixels should be blended against the background in order to get the
correct result. If an image viewing program does not take into account the
alpha channel then it's dropping out this essential information, thus
destroying the original image.
  The image is unusable without alpha channel because it isn't even supposed
to be usable. There isn't anything wrong here.

-- 
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}//                     - Warp -

Post a reply to this message

In article <3bebd8a8@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

> : and doing so causes lots of problems
> : as no other program (that I have) expects it that way.
>
>   What problems?
>
> :  In particular is
> : makes the images unusable without alpha channel display always on...
>
>   But that's absolutely normal!
>   The alpha channel contains essential information about the image. It tells
> how the pixels should be blended against the background in order to get the
> correct result. If an image viewing program does not take into account the
> alpha channel then it's dropping out this essential information, thus
> destroying the original image.
>   The image is unusable without alpha channel because it isn't even supposed
> to be usable. There isn't anything wrong here.

Ok, take Photoshop for example (version 3.0, I am not a millionaire!).  If
one draws with a brush using i.e. blue color on a transparent layer and then
gets a historgram, it will show you only perfect blue.  So what it at least
seems to do, is to set all anti-aliased pixel color component values to pure
blue.  POV-ray on the other hand (for obvious reasons) will determine a
middle value for both the color and the alpha-channel, which in turn is
fixed by saying the background is always black.  Of course this does fix the
problems without this assumption, but it isn't perfect.

For now (as discussed outside this group) the best solution for POV-Ray is
be to use antialiasing bailout based on the alpha-channel rather than the
color value.  Of course there are still a few minor implementation details
to be worked out (so this may not be in beta 8) first...

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
: POV-ray on the other hand (for obvious reasons) will determine a
: middle value for both the color and the alpha-channel, which in turn is
: fixed by saying the background is always black.

  Uh, I don't think this is how it does it. That was how 3.1 did it (if the
background was black). The color of pixels which are antialiased against the
background do not use the background color at all. If there's an object which
is completely <0,0,1> (and we make it so that it doesn't change due to
illumination, eg. with ambient 1), then the edge pixels will be completely
<0,0,1> and they will not be faded to black. Only the alpha channel is changed
in the antialiased pixels.
  If POV-Ray did use black as the "background color" when calculating
antialiasing, then the borders would fade to black. This is what 3.1 did, and
it was wrong, and consecuently fixed in 3.5.

-- 
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}//                     - Warp -

Post a reply to this message