clipka <ano### [at] anonymousorg> wrote:

>
> You can think of "srgb C" as (roughly) equivalent to "rgb pow(C,2.2)",
> i.e. very roughly squaring the colour value. As you may be aware, the
> square of a (positive) value below 1 is an even smaller value, while the
> square of a value above 1 is an even larger value.

Ah, of course; that makes perfect sense (now that you've explained it, ha!)

> BTW, there's a caveat when using "srgb" in light sources: To modify the
> brightness without affecting the hue, you need to use
>
>     colour (srgb <R,G,B>)*Brightness
>
> rather than
>
>     colour srgb <R,G,B>*Brightness
>
> because the latter would be interpreted as
>
>     colour srgb (<R,G,B>*Brightness)
>

Wow, that's a subtle difference that I wasn't aware of. Thanks! I'm curious--
would the same logic apply to colors in MEDIA? Or does the above formula apply
*only* to lights?

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 27.12.2016 um 09:21 schrieb Kenneth:
>
> > I decided to run your test scene with assumed_gamma 1.0 instead of 2.2, and
> > noticed something about your use of 'rgb' in the light_source. I changed it to
> > srgb (which I've started doing in all my v3.7xx scenes, to be 'color-consistent'
>
> BTW, there's a caveat when using "srgb" in light sources: To modify the
> brightness without affecting the hue, you need to use
>
>     colour (srgb <R,G,B>)*Brightness
>
> rather than
>
>     colour srgb <R,G,B>*Brightness
>
> because the latter would be interpreted as
>
>     colour srgb (<R,G,B>*Brightness)
>
> and in the sRGB world multiplying a colour vector by a constant does
> /not/ correspond to an even scaling of the corresponding linear colour
> components. (That would work for f(x)=pow(x,2.2), but sRGB gamma is more
> complicated than that.)

The moral seems to be get all of your srgb declarations out of the way as early
as possible--including before you do any math on such colors.

Post a reply to this message

Am 27.12.2016 um 21:28 schrieb Kenneth:

>> BTW, there's a caveat when using "srgb" in light sources: To modify the
>> brightness without affecting the hue, you need to use
>>
>>     colour (srgb <R,G,B>)*Brightness

I'm just noticing that this syntax actually doesn't work; you'll need to use

    #declare C = srgb <R,G,B>;
    colour C * Brightness

>> rather than
>>
>>     colour srgb <R,G,B>*Brightness
>>
>> because the latter would be interpreted as
>>
>>     colour srgb (<R,G,B>*Brightness)
>>
> 
> Wow, that's a subtle difference that I wasn't aware of. Thanks! I'm curious--
> would the same logic apply to colors in MEDIA? Or does the above formula apply
> *only* to lights?

It applies anywhere you want to change the "magnitude" (be it
brightness, density or whatever) of a colour by a factor while retaining
the same hue and saturation.


What /is/ perfectly ok is dividing sRGB colour data for the purpose of
normalizing it to the range [0..1] when the "raw" data is normalized for
another range, e.g.:

    srgb <0,192,255>/255

Post a reply to this message