On 9-10-2017 14:00, Stephen wrote:
> On 09/10/2017 12:38, Thomas de Groot wrote:
>> It might be better to render as tga and later convert to png if 
>> necessary.
> 
> Is that one of those "Plant thy Mandrake when the moon is in Taurus and 
> waning gibbous.", things? :-P
> 
> 

LOL Yes, but then adapted to the digital world. Even so, I indeed 
recommend Mandrake over a Homunculus. ;-)

I seem to remember to have had problems generating transparent png 
images while I never had problems with tga.

-- 
Thomas

Post a reply to this message

On 10/10/2017 07:41, Thomas de Groot wrote:
> On 9-10-2017 14:00, Stephen wrote:
>> On 09/10/2017 12:38, Thomas de Groot wrote:
>>> It might be better to render as tga and later convert to png if 
>>> necessary.
>>
>> Is that one of those "Plant thy Mandrake when the moon is in Taurus 
>> and waning gibbous.", things? :-P
>>
>>
> 
> LOL Yes, but then adapted to the digital world. Even so, I indeed 
> recommend Mandrake over a Homunculus. ;-)
> 

Definitely Mandrake over Homunculus. Unless you are going to...



> 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.

-- 

Regards
     Stephen

Post a reply to this message

On 10-10-2017 9:27, Stephen wrote:
> On 10/10/2017 07:41, Thomas de Groot wrote:
>> On 9-10-2017 14:00, Stephen wrote:
>>> On 09/10/2017 12:38, Thomas de Groot wrote:
>>>> It might be better to render as tga and later convert to png if 
>>>> necessary.
>>>
>>> Is that one of those "Plant thy Mandrake when the moon is in Taurus 
>>> and waning gibbous.", things? :-P
>>>
>>>
>>
>> LOL Yes, but then adapted to the digital world. Even so, I indeed 
>> recommend Mandrake over a Homunculus. ;-)
>>
> 
> Definitely Mandrake over Homunculus. Unless you are going to...

Yes, unless. ;-)

> 
> 
> 
>> 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.
> 

That must be the origin of my dim memory of ancient trouble...

-- 
Thomas

Post a reply to this message

On 10/10/2017 08:34, Thomas de Groot wrote:
> On 10-10-2017 9:27, Stephen wrote:
>> On 10/10/2017 07:41, Thomas de Groot wrote:
>>> On 9-10-2017 14:00, Stephen wrote:
>>>> On 09/10/2017 12:38, Thomas de Groot wrote:
>>>>> It might be better to render as tga and later convert to png if 
>>>>> necessary.
>>>>
>>>> Is that one of those "Plant thy Mandrake when the moon is in Taurus 
>>>> and waning gibbous.", things? :-P
>>>>
>>>>
>>>
>>> LOL Yes, but then adapted to the digital world. Even so, I indeed 
>>> recommend Mandrake over a Homunculus. ;-)
>>>
>>
>> Definitely Mandrake over Homunculus. Unless you are going to...
> 
> Yes, unless. ;-)

Indeed.


> 
>>
>>
>>
>>> 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.
>>
> 
> That must be the origin of my dim memory of ancient trouble...
> 

I seem to remember Billboards were all the rage about that time.

-- 

Regards
     Stephen

Post a reply to this message

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).

Post a reply to this message

On 10-10-2017 14:26, Stephen wrote:
> On 10/10/2017 08:34, Thomas de Groot wrote:
>> On 10-10-2017 9:27, Stephen wrote:
>>> On 10/10/2017 07:41, Thomas de Groot wrote:
>>>> On 9-10-2017 14:00, Stephen wrote:
>>>>> On 09/10/2017 12:38, Thomas de Groot wrote:
>>>>>> It might be better to render as tga and later convert to png if 
>>>>>> necessary.
>>>>>
>>>>> Is that one of those "Plant thy Mandrake when the moon is in Taurus 
>>>>> and waning gibbous.", things? :-P
>>>>>
>>>>>
>>>>
>>>> LOL Yes, but then adapted to the digital world. Even so, I indeed 
>>>> recommend Mandrake over a Homunculus. ;-)
>>>>
>>>
>>> Definitely Mandrake over Homunculus. Unless you are going to...
>>
>> Yes, unless. ;-)
> 
> Indeed.

As you say.

> 
> 
>>
>>>
>>>
>>>
>>>> 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.
>>>
>>
>> That must be the origin of my dim memory of ancient trouble...
>>
> 
> I seem to remember Billboards were all the rage about that time.
> 

Yes, and then it faded away. I wonder what will be next.. ;-)

-- 
Thomas

Post a reply to this message

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

On 10.10.2017 10: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).
> 
Interesting insight, thanks. :-)

---
Diese E-Mail wurde von AVG auf Viren geprüft.
http://www.avg.com

Post a reply to this message

On 09.10.2017 06:56, Sven Littkowski wrote:
> Hi
> 
> is it possible to create a scene where the rendered items are visible
> but the entire empty background becomes transparent, if the output image
> is a PNG?
> 
> ---
> Diese E-Mail wurde von AVG auf Viren geprüft.
> http://www.avg.com
> 
I want to mention another problem that I have since I switched monitors
(now using a 16:9 monitor): the object of the scene has shifted to the
right side.

I tried to create a better camera, but still fail to get the 0.0 center
of the scene as center of the camera. Any assistance?

This is what i have now:

camera
{
 location < 0.0,  0.0, -50.0 >
 look_at  < 0.0,  0.0,   0.0 >
 right 1.77*x
}

Post a reply to this message

Am 11.10.2017 um 12:31 schrieb Sven Littkowski:

> I want to mention another problem that I have since I switched monitors
> (now using a 16:9 monitor): the object of the scene has shifted to the
> right side.
> 
> I tried to create a better camera, but still fail to get the 0.0 center
> of the scene as center of the camera. Any assistance?
> 
> This is what i have now:
> 
> camera
> {
>  location < 0.0,  0.0, -50.0 >
>  look_at  < 0.0,  0.0,   0.0 >
>  right 1.77*x
> }

That should work just fine -- at any resolution.

Are you sure it's not just your display software?

A test scene might be helpful.

(Also, I'd recommend using `right x*16/9` rather than the fudgy factor
of 1.77; with full-resolution renders it does make a difference of
something in the order of 10-20 pixels. Or use `right
x*image_width/image_height` to be independent of output image aspect ratio.)

Post a reply to this message