POV-Ray : Newsgroups : povray.general : srgb vs. rgb for *every* color in v3.7xx? : Re: srgb vs. rgb for *every* color in v3.7xx? Server Time
2 May 2024 18:35:50 EDT (-0400)
  Re: srgb vs. rgb for *every* color in v3.7xx?  
From: clipka
Date: 15 Feb 2016 14:59:59
Message: <56c22e3f$1@news.povray.org>
Am 15.02.2016 um 13:45 schrieb Kenneth:
> I've been kind of confused for awhile about just where and when to use srgb
> colors in my scenes since v3.7 came out. (Assume that I'm using assumed_gamma
> 1.0 and that I'm already using srgb colors for OBJECTS.) The docs mention using
> srgb "everywhere that color literals are used", but it's not clear (to me) what
> other things in the scene require them, in order for all elements to be
> *consistent*, both visually and for POV-Ray to work correctly.

I'm not sure where you got that quote from; I just searched the Wiki
(which includes the text of the docs) and couldn't find it anywhere.

I suspect you extrapolated that from statements saying something like:

"When converting an old scene to assumed_gamma 1.0, replace rgb with
srgb everywhere."

There is NO requirement whatsoever that a scene must use "srgb" instead
of "rgb" for physical realism.

The "srgb" keyword is just for convenience of entering colours that you
get from somewhere else: PhotoShop's colour picker, the World Wide Web,
or even a 3.6 POV-Ray scene without explicit assumed_gamma. What all
these sources have in common is that they typically use some non-linear
representation of colour values, often closely matching the sRGB colour
space. Most notably, sRGB is the official standard for the Web.

You can consider "srgb C" shorthand for

    rgb <f_srgb(C.red),f_srgb(C.green),f_srgb(C.blue)>

where f_srgb(x) is the so-called "sRGB transfer function" defined in the
sRGB standard, being approximately (but exactly) equal to exp(x,2.2).

If you're already using "assumed_gamma 1.0", and have found a colour
that you think looks great with "rgb", by all means do NOT replace it
with "srgb".


> Should I also use it in lights, media, etc. etc.? In other words, for
> *everything* that uses a color? There's a big visual difference when using rgb
> vs. srgb in lights, for example.

There is, indeed. That is why there is both the "srgb" and "rgb" keywords.

> AFAIU, v3.7 always uses 'linear' values in its computations now-- for correct
> physical behavior-- regardless of whether rgb or srgb is specified in a scene.

That is correct (presuming you use a "#version 3.7" statement and don't
explicitly specify an assumed_gamma other than 1.0). The only difference
between the two is that if you use "rgb", POV-Ray presumes the data
specified to be linear already and will use it as-is, while if you use
"srgb", POV-Ray presumes the data to be sRGB and will apply the
corresponding conversion first.

> So is my question really just a matter of 'visual or artistic preference' rather
> than computational consistency? Or, are there some things in POV-Ray that should
> *not* use srgb at all?

I wouldn't call it "visual or artistic preference", but rather
"technical preference" -- for each "srgb" colour there is a matching
"rgb" colour (albeit with different values) and vice versa, so there is
no result you can achieve with either keyword that you cannot achieve
with the other keyword; "all" you need to do is change the data
accordingly (except for values of 0.0 or 1.0, which happen to stay the
same).


For light sources I would typically recommend using "rgb", as you may
want to adjust the light source's brightness by multiplying with a
constant factor, like this:

    light_source {
      <X,Y,Z>
      rgb <R,G,B> * BRIGHTNESS
    }

As this multiplication is applied /before/ conversion, the same
construct with "srgb" will NOT increase the brightness by a factor of
BRIGHTNESS, but by some much larger factor, and may even result in a
colour shift.

Alternatively, use:

    #declare LightColour = srgb <R,G,B>;
    light_source {
      <X,Y,Z>
      LightColour * BRIGHTNESS
    }


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.