Am 24.12.2016 um 16:21 schrieb jhu:


I've made no attempt to "un-out-wash" it, so that's not much of a surprise.

Post a reply to this message

Am 24.12.2016 um 16:21 schrieb jhu:


Better?

Post a reply to this message

Attachments:
Download 'gamma_smoking_gun.png' (98 KB)

Preview of image 'gamma_smoking_gun.png'

clipka <ano### [at] anonymousorg> wrote:
> Am 24.12.2016 um 16:21 schrieb jhu:

>
> Better?

Significantly. Radiosity?

Post a reply to this message

Am 24.12.2016 um 23:42 schrieb jhu:
> clipka <ano### [at] anonymousorg> wrote:
>> Am 24.12.2016 um 16:21 schrieb jhu:

>>
>> Better?
> 
> Significantly. Radiosity?

That, and gave the light source a realistic inverse-square-law falloff
while moving it closer.

Post a reply to this message

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

>
> #version 3.7;
> global_settings { assumed_gamma 2.2 }
>
> ....
>
> light_source { <-3000,3000,-3000> color rgb 1.2 }
>

Hello all! I finally have a new computer (well, a used one, with Windows 7
Ultimate, and a dual-core processor. No more Windows XP, sadly-- that one died.)
I've been away from the newsgroups for several months...

But I digress...

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'
with all the other srgb colors I use), and noticed that the scene gets
*brighter.* It's an interesting (and unexpected) effect-- unexpected because,
when substituting srgb colors for rgb (under assumed_gamma 1.0), it usually
causes the lighting/colors to be be somewhat *darker* (as expected, due to the
gamma shift of the color components away from linear.) But in this case, the
result is the opposite-- it's brighter!

I assume this is because the light's intensity is greater than 1.0; but I don't
quite understand why. Is it a natural consequence of the srgb 'gamma curve',
affecting color components above 1.0? (Or maybe above a particular
'intermediate' value between 0.0 and 1.0?)

Post a reply to this message

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'
> with all the other srgb colors I use), and noticed that the scene gets
> *brighter.* It's an interesting (and unexpected) effect-- unexpected because,
> when substituting srgb colors for rgb (under assumed_gamma 1.0), it usually
> causes the lighting/colors to be be somewhat *darker* (as expected, due to the
> gamma shift of the color components away from linear.) But in this case, the
> result is the opposite-- it's brighter!
> 
> I assume this is because the light's intensity is greater than 1.0; but I don't
> quite understand why. Is it a natural consequence of the srgb 'gamma curve',
> affecting color components above 1.0? (Or maybe above a particular
> 'intermediate' value between 0.0 and 1.0?)

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.

The sRGB "transfer function" (that's the official technical term) is
indeed designed in such a way that it is neutral for values of 0 and 1,
while adjusting any values in between. Since it was designed for
situations where colours are clipped to this range, no special handling
is provided for larger values, and the effect is reversed there.


BTW, in the nominal region (between 0 and 1) the largest absolute effect
of gamma adjustment is roughly around an sRGB value of 0.5 (a linear
value of about 0.24), while the largest relative effect is near black.

Post a reply to this message

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

Post a reply to this message

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