On 23.03.10 17:05, Warp wrote:
>    IIRC, POV-Ray 3.5 mishandled alpha transparency against the background
> in that with antialiased edges and semi-transparent surfaces it blended
> the surface's color with the background color and then saved the resulting
> color with an alpha value. This caused object borders to have a pixel-wide
> halo of the wrong shade, and especially semi-transparent surfaces would have
> the wrong color.
>
>    This was fixed in POV-Ray 3.6, where it's calculated correctly (iow. the
> background color has no effect on the pixel colors when using +UA).
>
>    Last time I checked (it has been some time, though), the same problem had
> resurfaced in POV-Ray 3.7 beta. Someone had undone the fix in POV-Ray 3.6.
>
>    Has this been corrected already?

The fix was that alpha is treated differently depending on the version 
directive as the 3.6 change was unpopular...

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> The fix was that alpha is treated differently depending on the version 
> directive as the 3.6 change was unpopular...

  Unpopular? I think you are confusing this with how antialiasing is
calculated.

  I'm not talking about antialiasing. I'm talking about the +UA command-line
option and the alpha channel in the resulting image.

  POV-Ray 3.5 did it wrongly: The background color was mixed with the
semi-transparent pixels. This was fixed, correctly, in 3.6. In 3.7beta
the same problem resurfaced once again.

  The +UA option becomes almost unusable if the background color is mixed
with the semi-transparent pixels.

-- 
                                                          - Warp

Post a reply to this message

> On 23.03.10 17:05, Warp wrote:
>> IIRC, POV-Ray 3.5 mishandled alpha transparency against the background
>> in that with antialiased edges and semi-transparent surfaces it blended
>> the surface's color with the background color and then saved the
>> resulting
>> color with an alpha value. This caused object borders to have a
>> pixel-wide
>> halo of the wrong shade, and especially semi-transparent surfaces
>> would have
>> the wrong color.
>>
>> This was fixed in POV-Ray 3.6, where it's calculated correctly (iow. the
>> background color has no effect on the pixel colors when using +UA).
>>
>> Last time I checked (it has been some time, though), the same problem had
>> resurfaced in POV-Ray 3.7 beta. Someone had undone the fix in POV-Ray
>> 3.6.
>>
>> Has this been corrected already?
>
> The fix was that alpha is treated differently depending on the version
> directive as the 3.6 change was unpopular...

Most of the time, when you use the alpha channel, it's because the image 
need to be placed in/on another one.
You must assume that:
  - the background colour is unknown
  - the background is not of any continuous shade, but probably some pattern
  - the background can be a photo
  - the background may not yet exist, or is not yet available

If the background is known and available, then, you don't need to use 
the alpha channel, as you can render directly with the intended 
background integrated into the scene.

Given those obligatory assumptions, it's impossible to set a background 
in the rendered image that can match the intended background.

I agree with Warp, it was broken in version 3.5, corrected in version 
3.6, then broken again in version 3.7.

The change between 3.5 and 3.6 that is unpolupar is the antialiasing. 
The difference between aa after clipping in 3.5 vs. before clipping in 3.6.



Alain

Post a reply to this message

Warp schrieb:
>   IIRC, POV-Ray 3.5 mishandled alpha transparency against the background
> in that with antialiased edges and semi-transparent surfaces it blended
> the surface's color with the background color and then saved the resulting
> color with an alpha value. This caused object borders to have a pixel-wide
> halo of the wrong shade, and especially semi-transparent surfaces would have
> the wrong color.
> 
>   This was fixed in POV-Ray 3.6, where it's calculated correctly (iow. the
> background color has no effect on the pixel colors when using +UA).
> 
>   Last time I checked (it has been some time, though), the same problem had
> resurfaced in POV-Ray 3.7 beta. Someone had undone the fix in POV-Ray 3.6.
> 
>   Has this been corrected already?

No, apparently not - I just took the time to test it.

That means POV-Ray 3.7 /is/ actually doin' it plain wrong, as this 
behavior effectively constitutes writing premultiplied alpha. I don't 
know about TGA, but the PNG file format is explicitly specified to use 
/non/-premultiplied alpha. Which, when viewed with some piece of 
software that totally ignores the alpha channel, may look like crap for 
some scenes (e.g. a glass sphere on an opaque plane), but that's how the 
file format is specified.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> That means POV-Ray 3.7 /is/ actually doin' it plain wrong, as this 
> behavior effectively constitutes writing premultiplied alpha. I don't 
> know about TGA, but the PNG file format is explicitly specified to use 
> /non/-premultiplied alpha. Which, when viewed with some piece of 
> software that totally ignores the alpha channel, may look like crap for 
> some scenes (e.g. a glass sphere on an opaque plane), but that's how the 
> file format is specified.

  It's specified like that for a good reason. When you take a PNG with an
alpha channel and overlay it on top of something else (eg. on an image
manipulation program or on a web page), you get the proper behavior with
respect to the alpha blending.

  POV-Ray 3.6 did this right. If you rendered something with +UA and the
background (ie. nothingness) was "visible", you could then take the resulting
png and use it on top of something else (eg. on a web page) and it would just
work. The image would perfectly blend with the background (at least assuming
you have used antialiasing; also semi-transparent surfaces would work fine).

  With +UA the actual color of the background was completely ignored, as it
should be.

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
>   With +UA the actual color of the background was completely ignored, as it
> should be.

  Correction: The background color was ignored for rays which hit the
bakground directly or through a tansparent surface (iow. rays which would
produce non-opaque alpha to the result). Naturally the background color
still shows up on reflections.

-- 
                                                          - Warp

Post a reply to this message

Warp schrieb:
> clipka <ano### [at] anonymousorg> wrote:
>> That means POV-Ray 3.7 /is/ actually doin' it plain wrong, as this 
>> behavior effectively constitutes writing premultiplied alpha. I don't 
>> know about TGA, but the PNG file format is explicitly specified to use 
>> /non/-premultiplied alpha. Which, when viewed with some piece of 
>> software that totally ignores the alpha channel, may look like crap for 
>> some scenes (e.g. a glass sphere on an opaque plane), but that's how the 
>> file format is specified.
> 
>   It's specified like that for a good reason. When you take a PNG with an
> alpha channel and overlay it on top of something else (eg. on an image
> manipulation program or on a web page), you get the proper behavior with
> respect to the alpha blending.

That's actually nonsense; for the purpose of overlaying it over 
something else, you'll have to multiply the colors with alpha anyway, 
then add it to the background multiplied by 1-alpha; no difference in 
suitability here, you can do that with premultiplied alpha just as well. 
Actually premultiplied alpha saves you a computational step here.

The reason why PNG is specified like this is instead that 
non-premultiplied alpha allows for retrieving the original color of a 
semi-transparent image without loss of precision, in case someone wants 
to reduce its transparency.

However, while this is generally a good idea, it only works when the 
object to be "opaquified" does not overlap any other objects.

Or, in other words: The benefit of non-premultiplied alpha over 
premultiplied alpha is that the former retains some more information. No 
more and no less.

>   POV-Ray 3.6 did this right.

I'm not saying anything else by now.

Post a reply to this message

On 23.03.10 19:38, Alain wrote:
>> The fix was that alpha is treated differently depending on the version
>> directive as the 3.6 change was unpopular...
<snip>
> I agree with Warp, it was broken in version 3.5, corrected in version
> 3.6, then broken again in version 3.7.

My point was not putting this up for discussion. I merely stated the fact 
that there are people who disagree.

	Thorsten

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> On 23.03.10 19:38, Alain wrote:
> >> The fix was that alpha is treated differently depending on the version
> >> directive as the 3.6 change was unpopular...
> <snip>
> > I agree with Warp, it was broken in version 3.5, corrected in version
> > 3.6, then broken again in version 3.7.

> My point was not putting this up for discussion. I merely stated the fact 
> that there are people who disagree.

  Could you give some reference to this? Personally I don't remember even
one post in this newsgroup which said that POV-Ray 3.5 behaved better with
respect to the +UA than POV-Ray 3.6 does.

  On the contrary, the behavior was fixed for 3.6 precisely because people
complained that 3.5 was broken in that respect. Even if there were people
who for some strange reason want the 3.5 way of doing it, they are clearly
the minority.

  Reverting back to the way 3.5 did it is just plain wrong. The resulting
images are broken.

  My guess is that 3.7 reverted back to the old behavior because of an
oversight when the related routines were rewritten, not because of a
conscious decision done on purpose. In other words, it was a mistake.
A mistake which should be corrected.

-- 
                                                          - Warp

Post a reply to this message

Thanks To all of you for considering the matter. if I need to test some more on
any eventual revision, I'm sorry to say that I can't compile. so I would ask for
a build. (or maybe a lot of explanations on how to build with free tools)

Post a reply to this message