 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 24-7-2017 10:14, omniverse wrote:
> Thomas de Groot <tho### [at] degroot org> wrote:
>> On 23-7-2017 16:18, Jim Holsenback wrote:
>>> the syntax diagram has been changed to /correctly/ reflect it's /order/
>>> specific nature when using blend_mode:
>>>
>>> http://wiki.povray.org/content/Reference:Color_Map
>>> http://wiki.povray.org/content/Reference:Pigment_Map
>>
>> Thank you indeed Jim, much clearer now.
>>
>> --
>> Thomas
>
> Documentation is 2nd only to the program itself, and sometimes I think of it the
> other way around.
>
> Thanks goes to Christoph (clipka) too for that more thorough blend explanation.
> Takes me a couple three reads for most things like that. Ahhh that technical
> detail stuff!
>
I fully agree. Would it be going to far to ask if some of that
explanation could be included into the docs? I think it is not trivial.
--
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 7/24/2017 6:48 AM, Thomas de Groot wrote:
> On 24-7-2017 10:14, omniverse wrote:
>> Thomas de Groot <tho### [at] degrootorg> wrote:
>>> On 23-7-2017 16:18, Jim Holsenback wrote:
>>>> the syntax diagram has been changed to /correctly/ reflect it's /order/
>>>> specific nature when using blend_mode:
>>>>
>>>> http://wiki.povray.org/content/Reference:Color_Map
>>>> http://wiki.povray.org/content/Reference:Pigment_Map
>>>
>>> Thank you indeed Jim, much clearer now.
>>>
>>> --
>>> Thomas
>>
>> Documentation is 2nd only to the program itself, and sometimes I think
>> of it the
>> other way around.
>>
>> Thanks goes to Christoph (clipka) too for that more thorough blend
>> explanation.
>> Takes me a couple three reads for most things like that. Ahhh that
>> technical
>> detail stuff!
>>
>
> I fully agree. Would it be going to far to ask if some of that
> explanation could be included into the docs? I think it is not trivial.
>
i just updated (developer suggested) both syntax diagrams again ... if
you could help me out by replying here with relevant portions and i'll
follow up in the morning.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 24-7-2017 13:15, Jim Holsenback wrote:
> On 7/24/2017 6:48 AM, Thomas de Groot wrote:
>> On 24-7-2017 10:14, omniverse wrote:
>>> Thomas de Groot <tho### [at] degrootorg> wrote:
>>>> On 23-7-2017 16:18, Jim Holsenback wrote:
>>>>> the syntax diagram has been changed to /correctly/ reflect it's
>>>>> /order/
>>>>> specific nature when using blend_mode:
>>>>>
>>>>> http://wiki.povray.org/content/Reference:Color_Map
>>>>> http://wiki.povray.org/content/Reference:Pigment_Map
>>>>
>>>> Thank you indeed Jim, much clearer now.
>>>>
>>>> --
>>>> Thomas
>>>
>>> Documentation is 2nd only to the program itself, and sometimes I
>>> think of it the
>>> other way around.
>>>
>>> Thanks goes to Christoph (clipka) too for that more thorough blend
>>> explanation.
>>> Takes me a couple three reads for most things like that. Ahhh that
>>> technical
>>> detail stuff!
>>>
>>
>> I fully agree. Would it be going to far to ask if some of that
>> explanation could be included into the docs? I think it is not trivial.
>>
>
> i just updated (developer suggested) both syntax diagrams again ... if
> you could help me out by replying here with relevant portions and i'll
> follow up in the morning.
I shall do that tomorrow if you don't mind. I have to go away now.
--
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 24.07.2017 um 10:14 schrieb omniverse:
> Thanks goes to Christoph (clipka) too for that more thorough blend explanation.
> Takes me a couple three reads for most things like that. Ahhh that technical
> detail stuff!
I'm not sure if I should get credit for at last explaining the stuff I
implemented myself...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 24-7-2017 13:15, Jim Holsenback wrote:
> i just updated (developer suggested) both syntax diagrams again ... if
> you could help me out by replying here with relevant portions and i'll
> follow up in the morning.
I /think/ it is quite clear now what is intended and what blend_mode
does to the color_map entries. I find it a difficult matter altogether
though. Like always, I need a simple example to play with in order to
show me the differences. I have not yet done that with Christoph's
examples but will do so presently....
After playing a bit with that, I think I understand the theory but less
the (practical) use of blend_mode :-/
--
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 25.07.2017 um 09:42 schrieb Thomas de Groot:
> On 24-7-2017 13:15, Jim Holsenback wrote:
>
>> i just updated (developer suggested) both syntax diagrams again ... if
>> you could help me out by replying here with relevant portions and i'll
>> follow up in the morning.
>
> I /think/ it is quite clear now what is intended and what blend_mode
> does to the color_map entries. I find it a difficult matter altogether
> though. Like always, I need a simple example to play with in order to
> show me the differences. I have not yet done that with Christoph's
> examples but will do so presently....
>
> After playing a bit with that, I think I understand the theory but less
> the (practical) use of blend_mode :-/
Problem #1:
Linear greyscale gradients (which is what you get by default with
`assumed_gamma 1.0`) are typically perceived as non-linear.
Solution:
Introduce a mechanism to interpolate colour gradients in a non-linear
fashion. Enter `blend_mode 2`. (`blend_mode 1` was defined as a
mechanism to interpolate gradients in a linear fashion even when
`assumed_gamma 2.2` or similar is used.)
Problem #2:
Non-linear interpolation of colour gradients, if done on RGB values,
causes colour gradients to exhibit a midway dip in brightness and a poor
midway hue (note that this effect can be seen not only with `blend_mode
2`, but also with default blend mode if `assumed_gamma 2.2` or similar
is used).
Solution:
Introduce a mechanism to interpolate brightness in a non-linear fashion
while interpolating chromaticity (the relative ratio of R:G:B) in a
linear fashion. Enter `blend_mode 3`.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 25-7-2017 18:07, clipka wrote:
> Problem #1:
>
> Linear greyscale gradients (which is what you get by default with
> `assumed_gamma 1.0`) are typically perceived as non-linear.
>
> Solution:
>
> Introduce a mechanism to interpolate colour gradients in a non-linear
> fashion. Enter `blend_mode 2`. (`blend_mode 1` was defined as a
> mechanism to interpolate gradients in a linear fashion even when
> `assumed_gamma 2.2` or similar is used.)
>
>
> Problem #2:
>
> Non-linear interpolation of colour gradients, if done on RGB values,
> causes colour gradients to exhibit a midway dip in brightness and a poor
> midway hue (note that this effect can be seen not only with `blend_mode
> 2`, but also with default blend mode if `assumed_gamma 2.2` or similar
> is used).
>
> Solution:
>
> Introduce a mechanism to interpolate brightness in a non-linear fashion
> while interpolating chromaticity (the relative ratio of R:G:B) in a
> linear fashion. Enter `blend_mode 3`.
>
Thank you indeed Christoph, much appreciated. My thoughts were not a
criticism towards the methods but more a failure from my side to
/really/ understand what was going on, and I did not go too deep into
experimentations. Your explanation is (as always) welcome and clear.
Next time I need some blending I shall certainly explore deeper.
--
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
