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