Am 20.03.2017 um 01:08 schrieb Mike Horvath:
> On 3/19/2017 6:30 PM, clipka wrote:
>> As the entire shape is outside the linear RGB gamut, a straightforward
>> implementation of the functions would inevitably have exceeded the 0..1
>> range, and thus have caused undesired wraparound in the function
>> pattern; I therefore designed the functions to nominally return values
>> in the range from 0.5 to 0.6, and chose the colour map in a manner to
>> compensate (using e.g. `color_map{[0, red -5*3][1, red 5*3]}` for the
>> red component; note that the values of -5 and +5 compensate for the
>> uncommon nominal function range, while the factor of 3 is the one
>> required to effectively turn the average into a sum).
>>
...

> Also, I don't understand why I can color each triangle by converting XYZ
> to RGB and have the result look okay, but when I try to do the same
> thing with a function the result is messed up (unless I follow your
> method).

That's because when you colour individual triangles you're using the
colour conversion function directly; but when you're using (an average
of multiple) function pigments, the function is used via a pattern,
where an implicit mod(f,1) is applied to the function, wrapping around
values outside the range 0..1 (e.g. a function value of 1.1 gets
translated to a colour map index of 0.1).

Or at least that's what I presume you're seeing. Been there, seen that.

Post a reply to this message