POV-Ray : Newsgroups : povray.binaries.images : Stock colors and assumed_gamma 1 in POV-Ray 3.6 : Re: Stock colors and assumed_gamma 1 in POV-Ray 3.6 Server Time
18 May 2024 13:33:14 EDT (-0400)
  Re: Stock colors and assumed_gamma 1 in POV-Ray 3.6  
From: Kenneth
Date: 24 Oct 2020 11:15:01
Message: <web.5f9444d976c60ba8d98418910@news.povray.org>
"Bald Eagle" <cre### [at] netscapenet> wrote:

> In the same way that the graph shows arrows representing conversions between
> the different curves, I'd like it if we could have a collection macros that
> do the same thing - with a switch to turn on some text output to the debug
> stream describing the inputs and results.  "Converting linear rgb <r, g, b>
> to sRGB <sr, sg, sb>..."   or some such thing.
....

> I would also like to have a way to do what clipka was cautioning me
> about - where a palette of srgb colors could be lightened or darkened using
> a multiplier, and the math would be correct to do it in the proper color
> space.
>
> The new tone-adjusting formulas are:
>
> #declare SRGB_Encode = function (C, M) {
>  select (C-0.0031308, C*12.92*M, C*12.92*M, (1.055 * pow (C, 1/2.4) - 0.055)*M)
> }
>
> #declare SRGB_Decode = function (C, M) {
>  select (C-0.040449936, C/12.92, pow ((C+0.055)/1.055, 2.4)*M)
> }
>
> using M as a multiplier.  Looks like it works correctly, even with  M > 1.
> Perhaps it's not "right", but it's the way I envisioned its usage.
>

I took your advice-- I'm currently working on a complex text scene, taking into
account assumed_gamma, and rgb/srgb colors for both objects AND light sources--
because I personally want to form an opinion about whether or not to use srgb
colors for lights as well, simply to get the color I 'visually' expect as
opposed to 'linear' rgb colors that are intrinsically washed-out in an
assumed_gamma 1.0 environment. I know that Clipka recommended we stick with
'rgb' there, but my test scene will compare the difference.

And I plan to use your excellent conversion functions; it looks like you figured
out how to 'correctly' multiply srgb colors with an M, which is a more complex
situation than multiplying simple rgb colors. Your coding skills are more
sophisticated than mine, so I'll take your word for it ;-)

Can I assume that, if I choose *not* to use the M-multiplier in your functions
(for my simpler test scene), I could just change the function like so? and with
C being a typical 3-part color vector like <.3,.6,.9>)?:

#declare SRGB_Encode = function (C) {
 select (C-0.0031308, C*12.92, C*12.92, (1.055 * pow (C, 1/2.4) - 0.055))

The reason being, that I might restrict any color values to between 0.0 and 1.0,
for a better 'basic' test of things. (Although, I might change my mind.)

When my test scene is complete and working properly, I'll post it elsewhere.


Post a reply to this message

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