Thomas de Groot <tho### [at] degrootorg> wrote:
> On 23-7-2017 8:21, omniverse wrote:
> > clipka <ano### [at] anonymousorg> wrote:
> >> Am 22.07.2017 um 20:21 schrieb omniverse:
> >>
> >>> And something curious going on, I'm not sure about, when I add blend_mode to my
> >>> example; I can't get the same appearance as yours, which seems to remove the
> >>> purple color between blue and red.
> [...]
>
> Now I am completely lost indeed. Where do you put that "blend_mode"
> parameter??? The wiki doesn't show in the examples, while it discusses
> it; something to correct I guess.

Hey Thomas, apparently first thing within color_map. POV-Ray kindly informed me
of my error when trying it after the color index.

Maybe it's supposed to be something like image_map when 'gamma' is used there,
needing it immediately after the image file name and no where else.

My bet is source code guru clipka knows the reason for these precise keyword
placements.

About my inability to find a way to get few enough color indicies in the
color_map for blend_mode 2 to match the 0 to 1 way... well... a solution I found
was to do just that, reduce to those pairs, 0 and 1.

Just not getting through to me why 0 to 0.5 to 1 (or just 3 entries in
color_map) doesn't seem to be similar at all. Again, that was using the #for
loop I was doing before too.

Bob

Post a reply to this message

"omniverse" <omn### [at] charternet> wrote:
> Thomas de Groot <tho### [at] degrootorg> wrote:
> > On 23-7-2017 8:21, omniverse wrote:
> > > clipka <ano### [at] anonymousorg> wrote:
> > >> Am 22.07.2017 um 20:21 schrieb omniverse:
> > >>
> > >>> And something curious going on, I'm not sure about, when I add blend_mode to
my
> > >>> example; I can't get the same appearance as yours, which seems to remove the
> > >>> purple color between blue and red.
>
> Just not getting through to me why 0 to 0.5 to 1 (or just 3 entries in
> color_map) doesn't seem to be similar at all. Again, that was using the #for
> loop I was doing before too.

Almost forgot. Below is what I tried when checking the "blend", although lacks
"steps" from other way. Thanks to you others with the various ideas.

BTW, good luck jr!
Bob

#declare BeginColorCount=0; /* or zero and < EndColorCount */

#declare EndColorCount=255; /* or > BeginColorCount (must be 255 if doing below
parenthesis example) */

#declare StepsCount=1; /* number to increment by (255 makes only indicies 0 and
1) */

box { // apply to this shape
0.00001, 0.99999 // avoid color map coincident surfaces
pigment {
 gradient x // choose a directional axis
 //ramp_wave // default
 color_map {
//blend_mode 2
//blend_gamma 2.5
  #for (It,BeginColorCount,EndColorCount,StepsCount)
  [
  It/EndColorCount
  color rgb <It/EndColorCount,0,(EndColorCount-It)/EndColorCount>
  ]
  #end
 }
}
}

Post a reply to this message

Am 23.07.2017 um 08:21 schrieb omniverse:

> Thanks for the explanation, guess I thought there must still be some "blending"
> going on in there somewhere, from one color entry to next, especially if the
> actual blending is limited only by usable memory.

The /actual blending/ is not even limited by usable memory -- it is
computed on the fly while rendering.

> Ohhh! Maybe I get it now. Reduce the number of entries/indices and the between
> zones should exist more visibly...?
> Um, nope. Not it. At least I'm unable to reduce it down to fewer colors and see
> the purple lessen in the middle of blue and red.
> So I'm still not understanding why I can't get blend_mode 2 the same as when the
> color_map includes only a 0 and 1 entry by using only a few instead. Main
> difference being the #for loop, only thing I can imagine causing this.

Suppose you have the followng object:

    box { <-1,-1,-1>, <1,1,1>
      texture {
        pigment {
          gradient x
          colour_map {
            blend_mode BLENDMODE
            [0.0 colour rgb <0,0,1>]
            [1.0 colour rgb <1,0,0>]
          }
        }
      }
    }

Now assume that for one particular pixel the camera ray hits the box
surface at <0.4,-1,0>; that's halfway along the gradient, giving a
pattern value of 0.4.

POV-Ray then looks up the pattern value in the colour map: It finds 0.0
and 1.0 as the two closest index values, with colours rgb <0,0,1> and
rgb <1,0,0> respectively. It computes the colour at pattern value 0.4 as
a weighted average of the two colours:

    P1 = 0.0; C1 = <0,0,1>
    P2 = 1.0; C2 = <1,0,0>
    P  = 0.4

    W1 = (P2-P)/(P2-P1)
    W2 = 1.0-W1
    Result = Average(W1,C1, W2,C2)

For `blend_mode 0`, we have:

    Average(W1,C1, W2,C2) = W1*C1 + W2*C2

And thus:

    W1 = (1.0-0.4)/(1.0-0.0) = 0.6/1.0 = 0.6
    W2 = 1.0-0.6 = 0.4
    Result = 0.6*<0,0,1>+0.4*<1,0,0> = <0,0,0.6>+<0.4,0,0>
           = <0.4,0,0.6>

However, for the other blend modes the formula is more complicated. The
only property that's guaranteed for all blend modes is that

    Average(1.0,C1, 0.0,C2) = C1
    Average(0.0,C1, 1.0,C2) = C2

but that's not the case here, so for a pattern value of 0.4 the result
depends on the blend mode.


Now suppose you specify interim entries in the colour map:

    box { <-1,-1,-1>, <1,1,1>
      texture {
        pigment {
          gradient x
          colour_map {
            blend_mode BLENDMODE
            #for(I,0,1,0.1)
              [I colour rgb (1-I)*<0,0,1> + I*<1,0,0>]
            #end
          }
        }
      }
    }

It does not matter that this uses a `#for` loop; the following is
entirely equivalent:

    box { <-1,-1,-1>, <1,1,1>
      texture {
        pigment {
          gradient x
          colour_map {
            blend_mode BLENDMODE
            [0.0 colour <0.0,0.0,1.0>]
            [0.1 colour <0.1,0.0,0.9>]
            [0.2 colour <0.2,0.0,0.8>]
            [0.3 colour <0.3,0.0,0.7>]
            [0.4 colour <0.4,0.0,0.6>]
            ... // I'm too lazy here
            [1.0 colour <1.0,0.0,0.0>]
          }
        }
      }
    }

In this case, when POV-Ray looks up the pattern value 0.4 in the colour
map, it finds 0.3 and 0.4 as the two closest index values, with colours
rgb <0.3,0.0,0.7> and rgb <0.7,0.0,0.3> respectively. Again, it computes
the colour at pattern value 0.4 as a weighted average of the two colours:

    P1 = 0.3; C1 = <0.3,0.0,0.7>
    P2 = 0.4; C2 = <0.4,0.0,0.6>
    P  = 0.4

    W1 = (P2-P)/(P2-P1)
    W2 = 1.0-W1
    Result = Average(W1,C1,W2,C2)

We get:

    W1 = (0.4-0.4)/(0.4-0.3) = 0.0/0.1 = 0.0
    W2 = 1.0-0.0 = 0.0
    Result = Average(0.0,<0.3,0.0,0.7>, 1.0,<0.4,0.0,0.6>)

Now remember that for all blend modes we have:

    Average(0.0,C1, 1.0,C2) = C2

And thus:

    Result = <0.4,0.0,0.6>

Note that this result is /independent/ of the blend mode.

For pattern values in between the interim entries (e.g. 0.44) you'd
still get results that depend on the blend mode, but those differences
would be far less pronounced as the interim entry colours are already
quite close to each other.


To achieve the same effect with interim entries as you'd get with just
two colour map entries, you'd have to modify the formula for the interim
entry colours to match the averaging formula used for the particular
blend mode.

Post a reply to this message

hi,


On 23/07/2017 09:33, omniverse wrote:
> BTW, good luck jr!
> Bob

cheers.  :-)



On 23/07/2017 03:04, Alain wrote:
> If you want the long and painfull way...:

lol, I suppose so.  I've been toying around with the info and tips given
in this thread and now think that it might be better to generate the
color_map only after I know the voxel size (ie octets), to allow for the
increases in the value ranges.

I've posted an example from a WIP script which builds a 255 entry map,
using a handful of colours cyclically, using a method somewhere between
Kurtz le pirate's and yours.  getting there for 8-bit data but the same
map produces just not enough detail when applied to 16-bit data.


again, thanking all who chipped in.
jr.

Post a reply to this message

On 23-7-2017 9:55, omniverse wrote:
> Thomas de Groot <tho### [at] degrootorg> wrote:
>> On 23-7-2017 8:21, omniverse wrote:
>>> clipka <ano### [at] anonymousorg> wrote:
>>>> Am 22.07.2017 um 20:21 schrieb omniverse:
>>>>
>>>>> And something curious going on, I'm not sure about, when I add blend_mode to my
>>>>> example; I can't get the same appearance as yours, which seems to remove the
>>>>> purple color between blue and red.
>> [...]
>>
>> Now I am completely lost indeed. Where do you put that "blend_mode"
>> parameter??? The wiki doesn't show in the examples, while it discusses
>> it; something to correct I guess.
> 
> Hey Thomas, apparently first thing within color_map. POV-Ray kindly informed me
> of my error when trying it after the color index.
> 
> Maybe it's supposed to be something like image_map when 'gamma' is used there,
>

Thanks for that Bob. I think that with Christoph's explanations below, 
we are in business. I am going to play with this a little bit. Until now 
I had failed to be aware of the blend_mode options offered, but that is 
life I guess ;-)

-- 
Thomas

Post a reply to this message

On 7/23/2017 2:56 AM, Thomas de Groot wrote:
> On 23-7-2017 8:21, omniverse wrote:
>> clipka <ano### [at] anonymousorg> wrote:
>>> Am 22.07.2017 um 20:21 schrieb omniverse:
>>>
>>>> And something curious going on, I'm not sure about, when I add 
>>>> blend_mode to my
>>>> example; I can't get the same appearance as yours, which seems to 
>>>> remove the
>>>> purple color between blue and red.
> [...]
> 
> Now I am completely lost indeed. Where do you put that "blend_mode" 
> parameter??? The wiki doesn't show in the examples, while it discusses 
> it; something to correct I guess.
> 

true enough no example ... but i thought i hinted about the order with 
the syntax diagram

Post a reply to this message

On 7/23/2017 7:43 AM, Jim Holsenback wrote:
> On 7/23/2017 2:56 AM, Thomas de Groot wrote:
>> On 23-7-2017 8:21, omniverse wrote:
>>> clipka <ano### [at] anonymousorg> wrote:
>>>> Am 22.07.2017 um 20:21 schrieb omniverse:
>>>>
>>>>> And something curious going on, I'm not sure about, when I add 
>>>>> blend_mode to my
>>>>> example; I can't get the same appearance as yours, which seems to 
>>>>> remove the
>>>>> purple color between blue and red.
>> [...]
>>
>> Now I am completely lost indeed. Where do you put that "blend_mode" 
>> parameter??? The wiki doesn't show in the examples, while it discusses 
>> it; something to correct I guess.
>>
> 
> true enough no example ... but i thought i hinted about the order with 
> the syntax diagram

well ok now ... looking closer i'm not entirely comfortable with that 
syntax diagram. i think i can do better. i'm trying to get 3.8 docs 
squared away so we can get back to doing a release ... standby

Post a reply to this message

On 7/23/2017 9:13 AM, Jim Holsenback wrote:
> On 7/23/2017 7:43 AM, Jim Holsenback wrote:
>> On 7/23/2017 2:56 AM, Thomas de Groot wrote:
>>> On 23-7-2017 8:21, omniverse wrote:
>>>> clipka <ano### [at] anonymousorg> wrote:
>>>>> Am 22.07.2017 um 20:21 schrieb omniverse:
>>>>>
>>>>>> And something curious going on, I'm not sure about, when I add 
>>>>>> blend_mode to my
>>>>>> example; I can't get the same appearance as yours, which seems to 
>>>>>> remove the
>>>>>> purple color between blue and red.
>>> [...]
>>>
>>> Now I am completely lost indeed. Where do you put that "blend_mode" 
>>> parameter??? The wiki doesn't show in the examples, while it 
>>> discusses it; something to correct I guess.
>>>
>>
>> true enough no example ... but i thought i hinted about the order with 
>> the syntax diagram
> 
> well ok now ... looking closer i'm not entirely comfortable with that 
> syntax diagram. i think i can do better. i'm trying to get 3.8 docs 
> squared away so we can get back to doing a release ... standby

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

Post a reply to this message

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

Post a reply to this message

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!

Bob

Post a reply to this message