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 <3bea5a84$1@news.povray.org> , "Alex Falappa" 
<afa### [at] remove-medatamatit> wrote:

> (maybe related to that reported by John David
> Haiducek in the thread "Alpha output"):

No, not really.

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

What you probably refer to is the visual difference if you look at the
antialiased borders of any object (there is nothing "special" about text
objects) they look "lighter" if the alpha-channel output is on and the image
is presented on a (nearly plain) background taking the alpha channel into
account.  This is simply because both the color and the alpha channel are
antialiased and thus the resulting borders where antialiasing is used look
different.  I know this doesn't look perfect or wrong, but it is the way
antialiasing works.  Try it with a dark background and you will see the
effect change as it should...

    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

It seems to me that +am2 works fine (I don't see anything strange) but
+am1 doesn't. It *might* be caused by the same problem that makes the
+ua +am1 combination so slow.

-- 
#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 <3bea66ce@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

>   It seems to me that +am2 works fine (I don't see anything strange) but
> +am1 doesn't. It *might* be caused by the same problem that makes the
> +ua +am1 combination so slow.

I tried both, and I don't see a problem other than the one described - in
the Mac version the user can turn on and off the alpha-channel preview of
the image in the preview window (since 3.1).  So I can see the imae witha dn
without in direct comparison easily.

    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:
: I tried both, and I don't see a problem other than the one described - in
: the Mac version the user can turn on and off the alpha-channel preview of
: the image in the preview window (since 3.1).  So I can see the imae witha dn
: without in direct comparison easily.

  When I render the example scene without +ua, all parts of the the text is
antialiased equally.
  If I render it with +ua (and antialiasing method 1), then the part of the
text which has only background behind it doesn't get antialiased (while the
part which has the boxes behind does). The preview of POV-Ray shows clearly
this and when I open the resulting image with Gimp, it is identical (that is,
the edges really aren't antialiased in those parts).

  I'm using the unix version (yes, it supports preview taking into account
the alpha channel, as the Windows version does), but I suppose that the Windows
version works in the same way (I suppose that the original poster is using
that).

  However, I think the problem seems to be somewhere else. I tried putting
another black object in the image (a cylinder) and it didn't get antialiased in
the lower half of the image either.
  It seems to me that the color of the objects has something to do with this.
If I make the cylinder and the text red, then they get antialiased.

  Could it perhaps be that the antialiasing routine thinks that the background
is black and thus doesn't perform antialiasing with black objects?
  This is specially curious since the background is specifically set to white.
Put perhaps the +ua has some effect here.
  It's also curious why it works with +am2.

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

"Thorsten Froehlich" <tho### [at] trfde> ha scritto nel messaggio
news:3bea6141@news.povray.org...

> What you probably refer to is the visual difference if you look at the
> antialiased borders of any object (there is nothing "special" about text
> objects) they look "lighter" if the alpha-channel output is on and the
image
> is presented on a (nearly plain) background taking the alpha channel into
> account.  This is simply because both the color and the alpha channel are
> antialiased and thus the resulting borders where antialiasing is used look
> different.

So why the lower part of the blue box gets correctly antialiased?

>I know this doesn't look perfect or wrong, but it is the way
> antialiasing works.  Try it with a dark background and you will see the
> effect change as it should...

I've tried setting a black background, no change.

Personally I believe Warp (in the other thread) is guessing something
correct by saying POV doesn't antialias cause interprets the transparent
background being black. Infact if you change the color of the lower text
object to a more saturated one (red for example) it gets antialiased in both
cases.

Alessandro

Post a reply to this message

>   When I render the example scene without +ua, all parts of the the text
is
> antialiased equally.
>   If I render it with +ua (and antialiasing method 1), then the part of
the
> text which has only background behind it doesn't get antialiased (while
the
> part which has the boxes behind does). The preview of POV-Ray shows
clearly
> this and when I open the resulting image with Gimp, it is identical (that
is,
> the edges really aren't antialiased in those parts).

This is why I've overlapped the text with the checkered boxes

>   I'm using the unix version (yes, it supports preview taking into account
> the alpha channel, as the Windows version does), but I suppose that the
Windows
> version works in the same way (I suppose that the original poster is using
> that).

I use Windows, which when +UA is on makes the checkered background of the
preview window visible trough the transparent pixels of the image.

>   However, I think the problem seems to be somewhere else. I tried putting
> another black object in the image (a cylinder) and it didn't get
antialiased in
> the lower half of the image either.
>   It seems to me that the color of the objects has something to do with
this.
> If I make the cylinder and the text red, then they get antialiased.
>
>   Could it perhaps be that the antialiasing routine thinks that the
background
> is black and thus doesn't perform antialiasing with black objects?
>   This is specially curious since the background is specifically set to
white.

I agree with you, maybe is something related to the way POV promote the
three component color used for background directive into the internal five
component format.

Alessandro

Post a reply to this message

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

> Thorsten Froehlich <tho### [at] trfde> wrote:
> : I tried both, and I don't see a problem other than the one described - in
> : the Mac version the user can turn on and off the alpha-channel preview of
> : the image in the preview window (since 3.1).  So I can see the imae witha dn
> : without in direct comparison easily.
>
>   When I render the example scene without +ua, all parts of the the text is
> antialiased equally.
>   If I render it with +ua (and antialiasing method 1), then the part of the
> text which has only background behind it doesn't get antialiased (while the
> part which has the boxes behind does). The preview of POV-Ray shows clearly
> this and when I open the resulting image with Gimp, it is identical (that is,
> the edges really aren't antialiased in those parts).

I have posted versions of the image with alpha-channel display and without
in p.b-t.binaries.  The image is rendered with method 1 and the Mac preview
window magnification is set to 400%.  Tell me if this is the same you see,
and if so, what is supposed to be different and where.

    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

Alex Falappa <afa### [at] remove-medatamatit> wrote:
: I use Windows, which when +UA is on makes the checkered background of the
: preview window visible trough the transparent pixels of the image.

  As an anecdotical (and perhaps historical?) note: The idea of making the
preview window support the alpha channel using a white-grey-checkered
background was first implemented in the unix-version of POV-Ray. Only after
it resulted to be a superb idea it was implemented in the Windows version
as well.

-- 
#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 <3beacb01@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

>   As an anecdotical (and perhaps historical?) note: The idea of making the
> preview window support the alpha channel using a white-grey-checkered
> background was first implemented in the unix-version of POV-Ray. Only after
> it resulted to be a superb idea it was implemented in the Windows version
> as well.

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.

At the time it was "stolen" from a not less historic Macintosh application
that existed long before there even was a usable WinDOS or an established
and accepted X based GUI - Photoshop.

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

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

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

No, 3.5 fades to black while 3.1 would fade to the background color.  The
border do not fade to black because of the alpha channel.  If you deactivate
view of the alpha channel (like I can do in the Mac version even if it is
on), you will notice it.

    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:
: No, 3.5 fades to black while 3.1 would fade to the background color.  The
: border do not fade to black because of the alpha channel.  If you deactivate
: view of the alpha channel (like I can do in the Mac version even if it is
: on), you will notice it.

  I made a small test file:

global_settings { assumed_gamma 1 }
camera { location -z*10 look_at 0 angle 35 }
cylinder { <10,22,0><-10,-22,0>, 1 pigment { rgb x } finish { ambient 1 } }

and rendered with:

./povray35 test.pov -w512 -h384 +a0.1 +ua +fn

  Then I checked how many colors are there in the resulting image. There
are exactly two colors, black (0,0,0) and red (255,0,0). There are no other
colors in the image. The pixels have a varying amount of alpha, but their
color is either (0,0,0) or (255,0,0), nothing else. (To be more specific,
all the pixels which have an alpha value which is not completely transparent,
are colored (255,0,0).)
  I can't understand how it could "fade to black" if alpha channel would not
be taken into account when drawing the pixels.
  This seems to work perfectly ok.

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

Glad to see I've tracked down a real bug.
Perhaps the bug may be re-classified as "Alpha problems: black objects are
not antialiased on Unix and Windows versions, alpha is not correctly output
on Mac".

Alessandro

Post a reply to this message

Alex Falappa <afa### [at] remove-medatamatit> wrote:
: "Alpha problems: black objects are
: not antialiased

  Only against the background.

-- 
#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 <3befb639@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

> : "Alpha problems: black objects are
> : not antialiased
>
>   Only against the background.

Actually, it doesn't depend on the object color.  The aa effect is also
incorrect for other objects, but there it is (far) less noticable.

    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:
: Actually, it doesn't depend on the object color.  The aa effect is also
: incorrect for other objects, but there it is (far) less noticable.

  Yes, a non-black, but extremely dark object (eg. rgb 0.05) may not trigger
the antialiasing threshold either and thus not get antialiased.
  However, you make it sound like there's always a problem, regardless of
the object color. Could you explain in more detail?

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

"Thorsten Froehlich" <tho### [at] trfde> wrote...
> 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...

As Warp says, this is "completely normal" and it is by design. If you're not
going to use the alpha channel, don't turn it on.  It is necessary to
produce images that look "bad" in order to make the alpha channel work
correctly.

-Nathan

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote...
>   I can't understand how it could "fade to black" if alpha channel would
not
> be taken into account when drawing the pixels.
>   This seems to work perfectly ok.

Interestingly enough, you BOTH are correct.

The antialiasing algorithm still blends the object with the background.
However, the new code compensates by adjusting weights to "unblend" the
color and blend the alpha channel instead.  Once the "unblending" is
complete, the antialiased pixels no longer contain any background color
information!  Only object information and alpha-channel blending remains.
The unblending & reblending is easiest if the background color is black
(otherwise we would have to somehow determine the raw BG color so we can
remove it).

The problem, as described earlier, is that "Colour_Distance" in colour.cpp
does not include the transparancy channels, and therefore a black object on
a black (clear) background will not be antialiased.

-Nathan

Post a reply to this message

On Tue, 13 Nov 2001 00:20:22 -0500, "Nathan Kopp" <nat### [at] koppcom>
wrote:

>The antialiasing algorithm still blends the object with the background.
>However, the new code compensates by adjusting weights to "unblend" the
>color and blend the alpha channel instead.  Once the "unblending" is
>complete, the antialiased pixels no longer contain any background color
>information!

Is this done using raw or clipped colors? 

As a side note, here's a description of the Defringe filter in
Photoshop, if it could be of any use. The idea of using adjacent
pixels is neat, but POV is already doing this by anti-aliasing :)

:When you move or paste an anti-aliased selection, some of the pixels 
:surrounding the selection border are included with the selection. 
:This can result in a fringe or halo around the edges of the pasted 
:selection. These Matting commands let you edit unwanted edge pixels: 
:
:Defringe replaces the color of any fringe pixels with the colors of 
:nearby pixels containing pure colors (those without background color).
:For example, if you select a yellow object on a blue background and 
:then move the selection, some of the blue background is selected and 
:moved with the object. Defringe replaces the blue pixels with yellow 
:ones.
:
: <snip>
:
:Enter a value in the Width text box for the distance to search for 
:replacement pixels. In most cases, a distance of 1 or 2 pixels is 
:enough.


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG      e-mail : pet### [at] tagpovrayorg

Post a reply to this message

"Peter Popov" <pet### [at] vipbg> wrote...
> On Tue, 13 Nov 2001 00:20:22 -0500, "Nathan Kopp" <nat### [at] koppcom>
> wrote:
>
> >The antialiasing algorithm still blends the object with the background.
> >However, the new code compensates by adjusting weights to "unblend" the
> >color and blend the alpha channel instead.  Once the "unblending" is
> >complete, the antialiased pixels no longer contain any background color
> >information!
>
> Is this done using raw or clipped colors?

Raw.

-Nathan

Post a reply to this message