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