> 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