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