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