On 4/1/21 7:51 AM, Subclick wrote:
> Thomas de Groot <tho### [at] degrootorg> writes:
> 
>> If I remember correctly, Clipka always hammered on:
>> - NEVER do this: srgb <.5, .3, .7>*50000;
>> - ALWAYS do this: srgb <.5*50000, .3*50000, .7*50000>;
> 
> If anything, the latter makes it clearer the multiplications are being
> done /before/ interpreting the vector’s components as sRGB color
> values.  If you want to multiply a light source’s intensity, you have to
> either store the color in a variable and then multiply it, like Kenneth
> did, or use a function to convert the sRGB values to linear RGB and
> multiply the latter.  From reading the documentation, I’d expect this to
> work, too, but unfortunately I get an error when I run it:
> 
>    C4 = color (srgb <.5, .3, .7>)*50000;
> 

With my personal povr branch I've been pondering changes to how the 
srgb* keywords work...

The srgb keyword allows us to specify colors in the mostly sRGB space we 
see on the web or in what POV-Ray itself renders by default in v3.7 and 
v3.8 to output file and preview screen.

As a habit I've been declaring colors using srgb space and multiplying 
for adjustment after. The thought being the declared srgb color is a set 
color in a set color space. Further, I can refer to that 'srgb color' by 
common web name and always get that color in my render.

By coding this way I'm also protecting against 'run away' intensity due 
multiplications ahead of the srgb adjustment where the multiplied values 
end up larger than 1.0(a). I only multiply post srgb input; I only 
multiply the previously defined color name.

(a) - Ponder one. Is the srgb adjustment valid outside the [0..1] range? 
It works, but you get essentially a pow(>1,2.2) result which doesn't 
correspond to any 'display adjustment' or 'web visual color'.

--- Ramblings on my srgb use today.
Suppose I first code up a background color which I find too bright. If I 
multiply the defined name by 0.2 while thinking / picking colors in the 
srgb space, I won't get the srgb space 0.1 grey I expect. Multiplying
GreyBkGnd by 0.2 is an adjustment in the linear color space.

Thinking in the srgb color space we most "see," what I really want is to 
multiply the original color vector ahead of the srgb translation into 
linear space so long as the resultant values are all still in the 0-1 range.

--- Some code with which to play
#version 3.8;
global_settings { assumed_gamma 1 }
#declare GreyBckGnd = srgb <0.5,0.5,0.5>;
// background { color GreyBckGnd } // Found it too bright
// background { GreyBckGnd * 0.2 } // Adjustment linear space
    background { srgb <0.5,0.5,0.5>*0.2 } // Adjustment srgb space

#declare GreyAdjust = srgb 0.2;  // I find this oddly useful too, but
// background { GreyBckGnd * GreyAdjust } // adjustment in srgb*srgb


The questionable part is when one or more of the srgb input channels 
goes above 1.0. Or when we have filter transmit channels greater than 
1.0 or summing to more than 1.0 on the vector's multiplication. Perhaps 
filter/transmit a separate issue from the behavior of the srgb* 
keywords?)(b).

(b) Ponder two. Would it be better to warn or err/fail during parse 
where the srgb keyword sees channel inputs >1.0? This would force users 
to deal explicitly with questionable channel input; force them to 
explicitly set the linear intent.

Another option would be to try and manage somehow doing linear 
adjustments for incoming channels >1 in value and srgb adjustments 
otherwise. However, I see that as problematic and likely more confusing 
to end users even if we could work out some standard treatment. In a way 
we have such behavior today, but I think it hard to use and probably 
making no sense where only some of the channels end up at values >1. In 
that case the srgb adjustments are moving differently for the values >1 
than they are for values in the 0-1 range.

Overall, what I'm thinking is srgb makes sense where we are in fact 
defining colors within the srgb visual/display color space. Further, 
that the old linear encoding is better where any of the incoming 
channels values are larger than 1.0(c). I think it likely better to have 
the parser force rgb* use over srgb* where any of the channel values are 
outside expected srgb space(d).

(c) Or less than 0.0 / negative color channel values.
(d) And thinking warnings on filter/transmit values >1.0 or <0 as there 
are useful tricks with odd f/t values.

Thoughts?

Bill P.

Post a reply to this message