hi,

can someone please point me to a color_map example which provides a
smooth blend/gradient from (ideally) blue at 0 to red at 1 in 254
increments?  I'd prefer a solution which does not require (an array of)
named colours.

thank you, jr.

Post a reply to this message

jr <cre### [at] gmailcom> wrote:
>
> can someone please point me to a color_map example which provides a
> smooth blend/gradient from (ideally) blue at 0 to red at 1 in 254
> increments?  I'd prefer a solution which does not require (an array of)
> named colours.
>
> thank you, jr.

Thinking ahead here: You are welcome!
You will probably get the idea from my fast example. Funny thing, still took me
half hour to write and edit again and again! I wanted it to do stepped colors
too, and comment on parts.

Bob

P.S. you can ignore the "by bob", no need to keep that. :)

/* SIMPLE SPECIFIC NUMBER OF COLORS FOR A GRADIENT PATTERN by bob */

#declare BeginColorCount=1; // or zero and < EndColorCount

#declare EndColorCount=254; // or > BeginColorCount

#declare StepsCount=12; // number to increment by (1 is good too)

box { // apply to this shape
0.00001,0.99999 // unequalize surface and color map
pigment {
 gradient x // choose a directional axis
 //ramp_wave // default
 color_map {

  #for (It,BeginColorCount,EndColorCount,StepsCount)
  [
  It/EndColorCount, (It+StepsCount)/EndColorCount
  color rgb <(EndColorCount-It)/EndColorCount,0,It/EndColorCount>
  color rgb <(EndColorCount-It)/EndColorCount,0,It/EndColorCount>
  ]
  #end

 }
}
finish {
 ambient 1 emission 0 diffuse 0 // see it without light
}
 translate -0.5 // center on origin vector
 scale 2 // double unit size
 rotate <30,30,30> // change orientation
 translate <0,0,4> // move location
}

Post a reply to this message

"omniverse" <omn### [at] charternet> wrote:
> jr <cre### [at] gmailcom> wrote:
> >
> > can someone please point me to a color_map example which provides a
> > smooth blend/gradient from (ideally) blue at 0 to red at 1 in 254
> > increments?

Sorry, I blame my awful speed reading. I put the red first and blue last, not
the way you said there.

And guess I should have asked why "254" instead of the usual 0 to 255. Won't
matter really, you only need to change the numbers to what you want.

Below is the blue to red way, obviously only a switch around of the rgb elements
to do that. And complete 256 color gradation, of course, just to show that.
Hopefully I did this example correctly, since I am known for flawing the
simplist things... and fouling up complexities for sure.
:D

Bob

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

#declare EndColorCount=255; // or > BeginColorCount

#declare StepsCount=1; // number to increment by (1 is good too)

box { // apply to this shape
0.00001,0.99999 // unequalize surface and color map
pigment {
 gradient x // choose a directional axis
 //ramp_wave // default
 color_map {

  #for (It,BeginColorCount,EndColorCount,StepsCount)
  [
  It/EndColorCount, (It+StepsCount)/EndColorCount
  color rgb <It/EndColorCount,0,(EndColorCount-It)/EndColorCount>
  color rgb <It/EndColorCount,0,(EndColorCount-It)/EndColorCount>
  ]
  #end

 }
}
finish {
 ambient 1 emission 0 diffuse 0 // see it without light
}
 translate -0.5 // center on origin vector
 scale 2 // double unit size
 rotate <30,30,30> // change orientation
 translate <0,0,4> // move location
}

Post a reply to this message

Am 22.07.2017 um 00:28 schrieb jr:
> hi,
> 
> can someone please point me to a color_map example which provides a
> smooth blend/gradient from (ideally) blue at 0 to red at 1 in 254
> increments?  I'd prefer a solution which does not require (an array of)
> named colours.
> 
> thank you, jr.

For a smooth gradient, all you need are the two color_map entries at 0
and 1:

    pigment {
      gradient x
      color_map {
        [0, <0,0,1>]
        [1, <1,0,0>]
      }
    }

This will give the exact same gradient as omniverse's suggestion. If it
is not to your liking, you'll have to specify additional constraints for
the gradient.

If you're unhappy with the above gradient and feel that its brightness
appears non-linear, try the `blend_mode` parameter, and maybe also
`blend_gamma`. For aesthetically pleasing results, `blend_mode 3` is
currently the best choice; it interpolates chromaticity and brightness
separately, using non-linear interpolation for the latter:

    global_settings { assumed_gamma 1.0 }
    ...

    pigment {
      gradient x
      color_map {
        blend_mode 3
        blend_gamma 2.5 // default
        [0, <0,0,1>]
        [1, <1,0,0>]
      }
    }


If you're actually interested in the numerical values, you can use the
`eval_pigment` function.

Post a reply to this message

Am 22.07.2017 um 09:31 schrieb clipka:

> This will give the exact same gradient as omniverse's suggestion.

Hm... no, actually not. Reading omniverse's suggestion again, he seems
to be using steps, i.e. not a smooth gradient at all.

Post a reply to this message

Am 22.07.2017 um 06:26 schrieb omniverse:

>   #for (It,BeginColorCount,EndColorCount,StepsCount)
>   [
>   It/EndColorCount, (It+StepsCount)/EndColorCount
>   color rgb <(EndColorCount-It)/EndColorCount,0,It/EndColorCount>
>   color rgb <(EndColorCount-It)/EndColorCount,0,It/EndColorCount>
>   ]
>   #end

That syntax is obsolete, and should be avoided. Instead, use the
following for exactly the same effect:

  #for (It,BeginColorCount,EndColorCount,StepsCount)
  [
    It/EndColorCount,
    color rgb <(EndColorCount-It)/EndColorCount,0,It/EndColorCount>
  ]
  [
    (It+StepsCount)/EndColorCount,
    color rgb <(EndColorCount-It)/EndColorCount,0,It/EndColorCount>
  ]
  #end

Post a reply to this message

hi,

thank you for the quick replies, Omniverse & Clipka.


On 22/07/2017 06:16, omniverse wrote:
> And guess I should have asked why "254" instead of the usual 0 to 255.
> Won't matter really, you only need to change the numbers to what you
> want.

simple memory fault :-(  I thought I'd read 254 being the max # entries
but, checking, the doc does say "from 2 to 256 entries".


On 22/07/2017 08:31, clipka wrote:
> If you're unhappy with the above gradient and feel that its brightness
> appears non-linear, try the `blend_mode` parameter, and maybe also
> `blend_gamma`. For aesthetically pleasing results, `blend_mode 3` is
> currently the best choice; it interpolates chromaticity and brightness
> separately, using non-linear interpolation for the latter:
> 
>     global_settings { assumed_gamma 1.0 }
>     ...
> 
>     pigment {
>       gradient x
>       color_map {
>         blend_mode 3
>         blend_gamma 2.5 // default
>         [0, <0,0,1>]
>         [1, <1,0,0>]
>       }
>     }

I just tried this and get good-ish results (a little too homogeneous
perhaps (the color_map is used to visualise data in a DF3)), but there's
no mention of the blend_* constraints in the installed (v 3.7.1a)
documentation.  I'll have a look in the online docs later.


again, many thanks.
jr.

Post a reply to this message

Am 22.07.2017 um 11:04 schrieb jr:

> On 22/07/2017 06:16, omniverse wrote:
>> And guess I should have asked why "254" instead of the usual 0 to 255.
>> Won't matter really, you only need to change the numbers to what you
>> want.
> 
> simple memory fault :-(  I thought I'd read 254 being the max # entries
> but, checking, the doc does say "from 2 to 256 entries".

... and, as a matter of fact, that's no longer valid for current
versions anyway ;)

Post a reply to this message

Le 22/07/2017 à 00:28, jr a écrit :
> hi,
>
> can someone please point me to a color_map example which provides a
> smooth blend/gradient from (ideally) blue at 0 to red at 1 in 254
> increments?  I'd prefer a solution which does not require (an array of)
> named colours.
>
> thank you, jr.
>

You can try this :


// --- build colors map ---------------------------------
#declare colorStart = <1.00, 0.00, 0.00>;  // Red
#declare colorEnd = <0.00, 0.00, 1.00>;	   // Blue
#declare colorDelta = colorEnd - colorStart;

#declare nStep = 64; // or others values
#declare colorStep = colorDelta/(nStep);

#declare myMap = color_map {
#declare index = 0;
#while (index <= nStep)
	#declare c = colorStart + index*colorStep;
	#declare s = index/nStep;
	[ s rgb c]
	#declare index=index+1;
#end
}


// --- use colors map --------------------------------
box {
   <0, 0, 0>,< 5, 5, 100>
   pigment {
     gradient z
     color_map { myMap }
     scale <1,1,100>
     }
   }



-- 
Kurtz le pirate
Compagnie de la Banquise

Post a reply to this message

Le 22/07/2017 à 00:28, jr a écrit :
> hi,
> 
> can someone please point me to a color_map example which provides a
> smooth blend/gradient from (ideally) blue at 0 to red at 1 in 254
> increments?  I'd prefer a solution which does not require (an array of)
> named colours.

From Blue to Red... in which colorspace would the transition be ?


The naive might expects a change in Hue, in HSV or HSL colorspace, with
a vibrant magenta at 0.5 (or going the other way on the circle, blue,
cyan, green, yellow, red ?)

You might want to have a look at the CHSL2RGB macro from colors.inc and
use it in the code provided in the other posts of this thread.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 22.07.2017 um 06:26 schrieb omniverse:

So to clarify the next thing said:

[0, 1 color <0,0,1> color <1,0,0>]

> That syntax is obsolete, and should be avoided. Instead, use the
> following for exactly the same effect:

And again, clarify this to be written as:

[0 color <0,0,1>]
[1 color <1,0,0>]

I am so far behind the times! Old habits and haphazard methods.

And in case anyone else is wondering, documentation for color_map AND blend_mode
is at:

http://wiki.povray.org/content/Reference:Color_Map

FYI, note to clipka... your example using blend_mode lacks either keywords color
or rgb, POV-Ray wants at least one of those in there. Obvious or not, my chance
to nitpick. ;)

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.
Mine just looks the same no matter what blend_mode is set to. Don't know if it's
the incremental steps thing, but I also took out the 2nd color and let a single
color statement do the for loop. No change.

So a heads up goes to OP jr about it anyway.

Bob

Post a reply to this message

hi,

On 22/07/2017 19:21, omniverse wrote:
> And in case anyone else is wondering, documentation for color_map AND
blend_mode
> is at:
>
> http://wiki.povray.org/content/Reference:Color_Map
>

thanks, just found that the online documentation is out of date.


> And something curious going on, I'm not sure about, when I add
blend_mode ...
> So a heads up goes to OP jr about it anyway.

ouch.  ;-)




On 22/07/2017 11:06, clipka wrote:
>> but, checking, the doc does say "from 2 to 256 entries".
>
> ... and, as a matter of fact, that's no longer valid for current
> versions anyway ;)

so, what /is/ the legal range now?




On 22/07/2017 11:55, kurtz le pirate wrote:
> You can try this :

thank you, very clear example.  the multiplication by the colour is
neat, it would never have occurred to me.




On 22/07/2017 19:11, Le_Forgeron wrote:
> From Blue to Red... in which colorspace would the transition be ?

already way over my head, I'm afraid to say.

the purpose of the map is to best present the range of values present in
a DF3 file, ie good contrast even when the difference in values is small.

> You might want to have a look at the CHSL2RGB macro from colors.inc and
> use it in the code provided in the other posts of this thread.

thanks, I'll look into this.


regards, jr.

Post a reply to this message

jr <cre### [at] gmailcom> wrote:
> hi,
>
> On 22/07/2017 19:21, omniverse wrote:
> > And in case anyone else is wondering, documentation for color_map AND
> blend_mode
> > is at:
> >
> > http://wiki.povray.org/content/Reference:Color_Map
> >
>
> thanks, just found that the online documentation is out of date.
>
>
> > And something curious going on, I'm not sure about, when I add
> blend_mode ...
> > So a heads up goes to OP jr about it anyway.
>
> ouch.  ;-)
>
>
>
>
> On 22/07/2017 11:06, clipka wrote:
> >> but, checking, the doc does say "from 2 to 256 entries".
> >
> > ... and, as a matter of fact, that's no longer valid for current
> > versions anyway ;)
>
> so, what /is/ the legal range now?

 Don't know that myself but I tried up to the hundred millions and ran out of
patience waiting for the parse while memory went up to 1 gig.

I think DF3 is 8, 16 and 32 bit. Which I believe translates to 256, 2048 and
16384.

Bob

Post a reply to this message

Le 17-07-21 à 18:28, jr a écrit :
> hi,
> 
> can someone please point me to a color_map example which provides a
> smooth blend/gradient from (ideally) blue at 0 to red at 1 in 254
> increments?  I'd prefer a solution which does not require (an array of)
> named colours.
> 
> thank you, jr.
> 

You don't need to chop your gradient into many pieces:

//The nice and simple way
pigment{gradient x colour_map{[0 rgb<0,0,1>][1 rgb<1,0,0>]}}}

If you want the long and painfull way...:

//The long and ugly way
#declare Steps=1024;
pigment{gradient x colour_map{
  #for(I, 0,1,1/Steps)
   [I rgb<I,0,1-I>]
//As of version 3.7, maps are no longer limited to 256 entries
  #end
}}}

Both should give exactly the same result when using assumed_gamma 1.

Post a reply to this message

Le 17-07-22 à 20:35, omniverse a écrit :
> jr <cre### [at] gmailcom> wrote:
>> hi,
>>
>> On 22/07/2017 19:21, omniverse wrote:
>>> And in case anyone else is wondering, documentation for color_map AND
>> blend_mode
>>> is at:
>>>
>>> http://wiki.povray.org/content/Reference:Color_Map
>>>
>>
>> thanks, just found that the online documentation is out of date.
>>
>>
>>> And something curious going on, I'm not sure about, when I add
>> blend_mode ...
>>> So a heads up goes to OP jr about it anyway.
>>
>> ouch.  ;-)
>>
>>
>>
>>
>> On 22/07/2017 11:06, clipka wrote:
>>>> but, checking, the doc does say "from 2 to 256 entries".
>>>
>>> ... and, as a matter of fact, that's no longer valid for current
>>> versions anyway ;)
>>
>> so, what /is/ the legal range now?
> 
>   Don't know that myself but I tried up to the hundred millions and ran out of
> patience waiting for the parse while memory went up to 1 gig.
> 
> I think DF3 is 8, 16 and 32 bit. Which I believe translates to 256, 2048 and
> 16384.
> 
> Bob
> 
> 
> 
8 bits is 256 values
16 bits is 65365 values
and 32 bits is a little over 4 billions values.

Post a reply to this message

Am 22.07.2017 um 20:21 schrieb omniverse:

> FYI, note to clipka... your example using blend_mode lacks either keywords color
> or rgb, POV-Ray wants at least one of those in there. Obvious or not, my chance
> to nitpick. ;)

I stand nitpicked indeed ;)

> 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.
> Mine just looks the same no matter what blend_mode is set to. Don't know if it's
> the incremental steps thing, but I also took out the 2nd color and let a single
> color statement do the for loop. No change.

That's because `blend_mode` only controls how POV-Ray interpolates
/between/ individual colour map entries; the entries themselves are
always taken as specified.

Since you're pre-computing some ~250 entries between blue and red,
render-time interpolation is only performed on colours that are very
close anyway, so that `blend_mode` has virtually no effect: Your colour
map is dominated by whatever interpolation formula you have implemented
in SDL, which in this particular case happens to match `blend_mode 0`
(the default).

Post a reply to this message

Am 22.07.2017 um 21:54 schrieb jr:

> On 22/07/2017 11:06, clipka wrote:
>>> but, checking, the doc does say "from 2 to 256 entries".
>>
>> ... and, as a matter of fact, that's no longer valid for current
>> versions anyway ;)
> 
> so, what /is/ the legal range now?

From 2 to whatever your computer's main memory can handle ;)

(Technically that's including virtual memory, but exceeding physical RAM
during render can lead to serious performance degradation.)

Post a reply to this message

Am 23.07.2017 um 02:35 schrieb omniverse:

>>>> but, checking, the doc does say "from 2 to 256 entries".
>>>
>>> ... and, as a matter of fact, that's no longer valid for current
>>> versions anyway ;)
>>
>> so, what /is/ the legal range now?
> 
>  Don't know that myself but I tried up to the hundred millions and ran out of
> patience waiting for the parse while memory went up to 1 gig.
> 
> I think DF3 is 8, 16 and 32 bit. Which I believe translates to 256, 2048 and
> 16384.

The density file pattern total size or element size has nothing to do
with colour map size.

Post a reply to this message

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.
> > Mine just looks the same no matter what blend_mode is set to. Don't know if it's
> > the incremental steps thing, but I also took out the 2nd color and let a single
> > color statement do the for loop. No change.
>
> That's because `blend_mode` only controls how POV-Ray interpolates
> /between/ individual colour map entries; the entries themselves are
> always taken as specified.
>
> Since you're pre-computing some ~250 entries between blue and red,
> render-time interpolation is only performed on colours that are very
> close anyway, so that `blend_mode` has virtually no effect: Your colour
> map is dominated by whatever interpolation formula you have implemented
> in SDL, which in this particular case happens to match `blend_mode 0`
> (the default).

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.

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.

Sorry, maybe I'm being dumb and this is probably going astray from the OP topic.

Bob

Post a reply to this message

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.

-- 
Thomas

Post a reply to this message

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

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.

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