On 10-10-2017 16:10, clipka wrote:
> Am 10.10.2017 um 09:27 schrieb Stephen:
> 
>>> I seem to remember to have had problems generating transparent png
>>> images while I never had problems with tga.
>>>
>>
>> I recognised the form of the spell. I had the same problem donkey's
>> years ago.
>> There was a time when PNGs behaved badly. I think it was not writing the
>> Alpha values in the output.
> 
> If I may clarify:
> 
> PNG output in POV-Ray v3.6 had the alpha mode wrong - i.e. how the alpha
> channel is supposed to interact with the colour channels.
> 
> The PNG specification mandates so-called "straight alpha", i.e. the
> colour channels should hold the colour as if the image was fully opaque,
> and blending should be done entirely by the display software, using
> Alpha:(1-Alpha) as the ratio between stored colour and background. This
> is akin to the way in which semi-transparent pigments are specified in
> POV-Ray's SDL.
> 
> However, POV-Ray's internal computations yield colour channel values
> that already take opacity into account, which is akin to so-called "gay
> alph..." uh, I mean, "associated alpha" aka "premultiplied alpha", in
> which the display software is only responsible for the background
> portion of the blending, using 1:(1-Alpha) as the ratio between stored
> colour and background.
> 
> POV-Ray v3.6 neglected the issue of alpha mode entirely: In file output
> it directly wrote the computed colour values, thus always writing in
> associated alpha mode (which happens to be wrong for PNG files). In file
> input, on the other hand, it interpreted the colour values in much the
> same way as in SDL, thus always reading in straight alpha mode (which
> happens to be correct for PNG files but wrong for certain other files).
> 
> So not only was POV-Ray v3.6 in violation of the PNG file format specs,
> it also was inconsistent in itself.
> 
> In POV-Ray v3.7, a proper alpha handling framework was implemented, and
> the problem fixed for PNG files.
> 
> 
> (Interestingly, even though the modes are referred to as "associated
> alpha" and "straight alpha", it's not actually the alpha channel that's
> different between the two modes -- the value stored is actually
> identical for both modes -- but the colour channel.)
> 
> 
> The advantage of "straight alpha" is that you can display an opaque
> version of the image simply by ignoring the alpha channel.
> 
> The advantages of "associated alpha" are that (a) it takes less
> computational effort to display, and (b) it can account for situations
> where bright light is to be shown against a highly transparent
> background (e.g. a transparent sphere with highlights).
> 

It comes back now, yes. Thanks for the reminder. Interesting to notice 
how it is former bad behaviour that sticks in the memory rather than the 
later correction. Survival adaptation, no doubt ;-)

-- 
Thomas

Post a reply to this message