Am 4/1/2021 um 16:53 schrieb William F Pokorny:
> On 4/1/21 7:51 AM, Subclick wrote:
> 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'.
> 
The sRGB transfer function is /per definition/ only valid in the 
[0.0..1.0] range. Negative values (i.e. out of gamut values) do make 
only sense within a linear color space and the same goes for values 
above 1.0 (i.e. HDR values).


> --- 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
> 
The un-commended third version is a dangerous one:
first reason: it will happen easily that you leave the defined range for 
the transfer function (see above).
second reason: for any non gray value it will not just change the 
brightness but also the hue, something that usually nobody wants.

> #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).
>
filter and transmit values should always be linear and are completely 
independent from the sRGB transfer function.

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

IMHO yes.

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

I did argue a bit with Christoph at the time he was making the 
suggestion for introducing the srgb keyword.
I was against it and my arguments where pretty much the problems you are 
mentioning here.
Christoph's argument was mainly that whole purpose of the srgb keyword 
is to make life easier for people who use a color picker within any 
paint software to select their colors out of pictures.
Well, reality is that people are using it because they think it somehow 
solves all gamma related problems -  but without actually understanding 
what it does.
But anyhow, I never did use this keyword myself so frankly I don't care 
much.

-Ive

Post a reply to this message