I have some new findings for POVers who wish to use the named colors in 
colors.inc with assumed_gamma 1 in old versions of POV-Ray.

You may recall that I noted a few years ago that the named colors in 
colors.inc seemed to have been determined without taking non-linear 
representation into consideration.  In other words, they don't look 
right with assumed_gamma 1.  So, I recommended applying srgb to these 
colors, as one would do with color values from third-party software, and 
ignoring the "suspicious expression" warning.  Shortly thereafter, I 
discovered the srgbft keyword, which eliminates the warning on colors 
that are already defined.

But while fooling around with my render rig wish list the other day, I 
discovered that 3.5 and 3.6 renders of the dark grays were lighter than 
3.7 and 3.8 renders!

So I wrote a scene to render some of the grays with different gamma 
configurations under different POV-Ray versions, then sampled the output 
images and created montages with the sampled values.  The ground plane, 
sky colors, and ambient were adjusted per frame to be comparable 
regardless of assumed_gamma, which is why the assumed_gamma 1 renders do 
not appear much different from the others.  In each frame, the light 
source is rgb 1 and diffuse was set such that the sum of diffuse and 
ambient is exactly one; this ensures that a Lambertian surface facing 
the light source reflects the pigment value.

The number in the center of each frame is a sample of the upper left 
facet, which directly faces the light source.

My goal was to use the unregulated color (upper left frame) as a 
control, and match that color using assumed_gamma 1.  The closest 
results are:

   Color    Control   POV-Ray 3.6          POV-Ray 3.7
   -----    -------   -----------          -----------
   Gray05   0.0037    Gamma 2.2 (0.0037)   sRGB (0.0040)
   Gray25   0.0497    Gamma 2.2 (0.0497)   sRGB (0.0513)
   Gray50   0.2122    Gamma 2.2 (0.2122)   Either (0.2159)
   Gray75   0.5210    Gamma 2.2 (0.5210)   sRGB (0.5210)

So, it appears that my initial recommendation holds for POV-Ray 3.7:

   #version 3.7;
   global_settings { assumed_gamma 1 }
   #include "colors.inc"
   pigment { srgbft ColorFromColorsDotInc }

But for earlier versions of POV-Ray, the power function should be used:

   #version 3.6; // or #version 3.5;
   global_settings { assumed_gamma 1 }
   #include "colors.inc"
   #include "math.inc"
   pigment { rgb VPow (ColorFromColorsDotInc, 2.2) }

The 3.5 renders are not shown because they sampled identical to the 
corresponding 3.6 frames.  I haven't sampled 3.8 frames, but unless 
someone knows differently, I have no reason to believe that changes were 
made in its gamma handling.  I have not tested any versions prior to 
3.5, nor have I tested any versions on an old Macintosh, which I 
understand used an unconventional gamma.

An implication that I have realized is that this rendering difference is 
not limited to stock colors.  *Any* color you define with rgb will look 
slightly different from 3.6 to 3.7.

In doing the automated sampling, I also discovered that a 3.7 image map 
loaded from a 3.5 or 3.6 rendered PNG source will look different from 
the source image!  To avoid this, put gamma 2.2 into the image_map 
block.  Whether this is a property of the rendering engine or just how 
the PNG chunks were set up, I don't know.  At the moment, I have no 
means of a proper comparison of the other supported image formats.

Post a reply to this message

Attachments:
Download 'stock_gamma-montage1.png' (77 KB) Download 'stock_gamma-montage2.png' (77 KB) Download 'stock_gamma-montage3.png' (75 KB) Download 'stock_gamma-montage4.png' (73 KB)

Preview of image 'stock_gamma-montage1.png'

Preview of image 'stock_gamma-montage2.png'

Preview of image 'stock_gamma-montage3.png'

Preview of image 'stock_gamma-montage4.png'

Thank you very much for the detailed report. This actually quite interests me as
I had trouble with the same matter a while ago, and your insight may help me
understand what was happening there.

Pascal


Cousin Ricky <ric### [at] yahoocom> wrote:
> I have some new findings for POVers who wish to use the named colors in
> colors.inc with assumed_gamma 1 in old versions of POV-Ray.
>
> You may recall that I noted a few years ago that the named colors in
> colors.inc seemed to have been determined without taking non-linear
> representation into consideration.  In other words, they don't look
> right with assumed_gamma 1.  So, I recommended applying srgb to these
> colors, as one would do with color values from third-party software, and
> ignoring the "suspicious expression" warning.  Shortly thereafter, I
> discovered the srgbft keyword, which eliminates the warning on colors
> that are already defined.
>
> But while fooling around with my render rig wish list the other day, I
> discovered that 3.5 and 3.6 renders of the dark grays were lighter than
> 3.7 and 3.8 renders!
>
> So I wrote a scene to render some of the grays with different gamma
> configurations under different POV-Ray versions, then sampled the output
> images and created montages with the sampled values.  The ground plane,
> sky colors, and ambient were adjusted per frame to be comparable
> regardless of assumed_gamma, which is why the assumed_gamma 1 renders do
> not appear much different from the others.  In each frame, the light
> source is rgb 1 and diffuse was set such that the sum of diffuse and
> ambient is exactly one; this ensures that a Lambertian surface facing
> the light source reflects the pigment value.
>
> The number in the center of each frame is a sample of the upper left
> facet, which directly faces the light source.
>
> My goal was to use the unregulated color (upper left frame) as a
> control, and match that color using assumed_gamma 1.  The closest
> results are:
>
>    Color    Control   POV-Ray 3.6          POV-Ray 3.7
>    -----    -------   -----------          -----------
>    Gray05   0.0037    Gamma 2.2 (0.0037)   sRGB (0.0040)
>    Gray25   0.0497    Gamma 2.2 (0.0497)   sRGB (0.0513)
>    Gray50   0.2122    Gamma 2.2 (0.2122)   Either (0.2159)
>    Gray75   0.5210    Gamma 2.2 (0.5210)   sRGB (0.5210)
>
> So, it appears that my initial recommendation holds for POV-Ray 3.7:
>
>    #version 3.7;
>    global_settings { assumed_gamma 1 }
>    #include "colors.inc"
>    pigment { srgbft ColorFromColorsDotInc }
>
> But for earlier versions of POV-Ray, the power function should be used:
>
>    #version 3.6; // or #version 3.5;
>    global_settings { assumed_gamma 1 }
>    #include "colors.inc"
>    #include "math.inc"
>    pigment { rgb VPow (ColorFromColorsDotInc, 2.2) }
>
> The 3.5 renders are not shown because they sampled identical to the
> corresponding 3.6 frames.  I haven't sampled 3.8 frames, but unless
> someone knows differently, I have no reason to believe that changes were
> made in its gamma handling.  I have not tested any versions prior to
> 3.5, nor have I tested any versions on an old Macintosh, which I
> understand used an unconventional gamma.
>
> An implication that I have realized is that this rendering difference is
> not limited to stock colors.  *Any* color you define with rgb will look
> slightly different from 3.6 to 3.7.
>
> In doing the automated sampling, I also discovered that a 3.7 image map
> loaded from a 3.5 or 3.6 rendered PNG source will look different from
> the source image!  To avoid this, put gamma 2.2 into the image_map
> block.  Whether this is a property of the rendering engine or just how
> the PNG chunks were set up, I don't know.  At the moment, I have no
> means of a proper comparison of the other supported image formats.

Post a reply to this message

Funny thing: This week, I've been running tests that are very similar to yours,
solely in v3.8 (the latest development version). For my city buildings scene, I
am trying to figure out why two colors-- both evaluated using the eval_pigment()
macro-- return slightly different values, when the values should be identical.

My *current* belief is that the reason has to do with the 'srgb' gamma itself,
as opposed to gamma 2.2. SRGB has a gamma that is not a straight power law (like
2.2), but rather a sort of combination of gammas-- with both a power law segment
and a linear segment. The 'average' of those is not quite 2.2. Wikipedia has a
good article about it. My own results so far show that an SRGB color vs. a
'linear' RGB color (that has been re-transformed into a gamma 2.2 color by using
an inverse power law) produce the slightly different values. AFAIU, the
Wikipedia article gives a rather complex formula which better approximates this
'gamma inversion' of RGB to arrive at the SRGB gamma color, with a better match
between expected values.

I *think* that POV-ray version 3.6 and earlier did not make use of 'srgb' as a
gamma in any way, but rather 1.0 or 2.2, depending on the "user's preference",
ha. I used to use 2.2, but that was because of a basic 'color misunderstanding'
on my part, prior to the introduction of srgb colors. ;-)

I'm still absorbing your comments, and thinking it all through. I need to do a
visual test like yours, in v3.8.

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
>
> My *current* belief is that the reason has to do with the 'srgb' gamma itself,
> as opposed to gamma 2.2.
[snip]
>
> I *think* that POV-ray version 3.6 and earlier did not make use of 'srgb' as a
> gamma in any way, but rather 1.0 or 2.2, depending on the "user's preference"...

Sorry, I probably didn't make my point very clear.

n POV-ray versions prior to 3.7(?), and using an assumed_gamma of 1.0 for a
scene back then, the colors in 'colors.inc' (being 'linear colors') didn't look
right when used as-is-- they had a washed-out appearance, due to the
assumed_gamma of 1.0. Changing assumed_gamma to 2.2 'corrected' those colors to
be what we (I?) might expect, or so it appeared. (but disregarding the other
'internal' computational problems that this probably caused vis a vis using a
suggested assumed_gamma of 1.0)

Jump forward to v3.7xx and 3.8, with its 'proper' use of assumed_gamma 1.0 and
the introduction of the srgb color keyword for using 'gamma-corrected' color
values that do not look washed out-- for example, using srgb to change a
'linear' rgb color in colors.inc.

SO... using assumed_gamma of 2.2 in earlier POV-ray versions along with linear
color values there, but then in later versions using assumed_gamma 1.0 and with
srgb-corrected colors, the respective gamma appearance (and value) of a
particular color might be slightly off when the two schemes are compared-- due
to the slight difference in gamma-bending between srgb and 'straight' 2.2


Or so my reasoning goes ;-)

Post a reply to this message

Hi Kenneth - this is something that I was concerned about, tried to address, and
IIRC, did it backwards.

Maybe you can take a look, and see what you think.

http://news.povray.org/povray.text.scene-files/thread/%3Cweb.58cc101945a951b1c437ac910%40news.povray.org%3E/

Apparently there's something with the linear interpolation of the color map that
needs to be addressed as well.

I'm accumulating one of those "infinite to-do lists..."   ;)

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Hi Kenneth - this is something that I was concerned about, tried to
> address, and IIRC, did it backwards.
>
> Maybe you can take a look, and see what you think.
>
>
http://news.povray.org/povray.text.scene-files/thread/%3Cweb.58cc101945a951b1c437ac910%40news.povray.org%3E/
>

I'm genuinely sorry to say that I didn't take note of your color-conversion
macros at the time (March 2017.) That is some NICE work.

I just spent a couple of enjoyable and challenging hours, going through your
macros' code there, and comparing it to the Wikipedia 'conversion' formulae (at
Wikipedia's "srgb" entry). Your math looks to be spot-on-- but of course you're
better at math than I am. ;-) Thanks for the opportunity for the mathematical
'brain boost'.

And you are correct-- your two macros are *reversed* as to their respective
operations! Through no fault of your own: the Wikipedia formulae themselves are
REVERSED. Which may mean that Wikipedia's source for those formulae is also
wrong. I'm amazed that no one has yet corrected the Wikipedia article.

'Fixing' your two macros is a simple matter-- just rename RGB2SRGB(C_linear) as
SRGB2RGB(C_exponential), ha. And vice-versa.

Having done so myself, I converted rgb <.75,.75,.75> to its srgb equivalent.
Result: <0.522522,0.522522,0.522522>

Compare that to:
#declare MY_PIG = pigment{srgb .75}
#debug concat(
"\n","srgb color = <",vstr(3,eval_pigment(MY_PIG, <.2,.2,.2>),",
",0,6),">","\n")
// Result: <0.522522,0.522522,0.522522>

A perfect match. Congrats!

As I experimented with your macros, three things pointed me to the conclusion
that the macro operations were reversed:
1) Your own hint ;-)
2) My *original* <.75,.75,.75> rgb-to-srgb result was 0.880825 -- which was
clearly wrong.
3) In the (mis-named) RGB2SRGB macro, at the near-ending line of
       #local C_srgb = ...
I changed that on a whim to
       #local C_srgb = srgb ....
and the #debug result was... <.75,.75,.75> -- the same as the original color! In
other words, it was first converting the color to (rgb) 0.880825 by the formula,
then #re*-converting it back to (srgb) 0.75. So *something* was amiss somewhere!

Btw, it may not be clear that to *use* your macros, the macro call in a scene
should include  srgb (or rgb, as the case may be). Like so:

box{0,1
pigment{srgb RGB2SRGB(<.75,.75,.75>)}
....
}

If it is left out, POV-ray apparently assumes the color to be 'linear' RGB by
default.

I would humbly suggest that you make a few changes to your March 2017 post. ;-)

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:

>
> 'Fixing' your two macros is a simple matter-- just
> rename RGB2SRGB(C_linear) as SRGB2RGB(C_exponential), ha. And vice-versa.

Well, I guess the macros do need a bit more than that in their code... only to
have consistency among the names of their internal variables. Minor work.

>
> Btw, it may not be clear that to *use* your macros, the macro call in a scene
> should include  srgb (or rgb, as the case may be). Like so:

Sorry, I didn't notice that you already gave examples of use, within the macros'
comments.

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
>
> >
> > 'Fixing' your two macros is a simple matter-- just
> > rename RGB2SRGB(C_linear) as SRGB2RGB(C_exponential), ha. And vice-versa.
>
> Well, I guess the macros do need a bit more than that in their code... only to
> have consistency among the names of their internal variables. Minor work.
>

I had some free time, so I 're-packaged' the macros for you, with all the
(minor) changes, and the switch of the macro names. All should work well, but
re-test them for any last-minute typos I may have made.

Post a reply to this message

Attachments:
Download 'color_conversion_macros_redone.txt' (3 KB)

Cousin Ricky <ric### [at] yahoocom> wrote:
>
> So I wrote a scene to render some of the grays with different gamma
> configurations under different POV-Ray versions, then sampled the output
> images and created montages with the sampled values...

Getting back to your original post here, about the slight discrepancies in color
values among the various versions of POV-ray:

I did some *basic* tests, solely in v3.8, using a simple pigment plus the
eval_pigment{...) macro, and I still get slight discrepancies in compared color
values. It somehow comes from the use of  srgb  vs.  rgb  in a color, AND on the
assumed_gamma of the scene.

#declare PIG_C = pigment{rgb <.75,.75,.75>} // CHANGE this from srgb to rgb

#debug concat("\n","PIGMENT_C evaluation = <",vstr(3,eval_pigment(PIG_C,
<.2,.2,.2>),", ",0,6),">","\n\n")

The various results using different assumed_gamma values:
--- With assumed_gamma 1.0:
1) using srgb: eval_pigment = <0.522522,0.522522,0.522522> // correct
2) using rgb:  eval_pigment = <0.750000,0.750000,0.750000> // correct
--- With assumed_gamma 2.2:
// 1) using srgb: eval_pigment = <0.744501,0.744501,0.744501> // ??
// 2) using rgb:  eval_pigment = <0.750000,0.750000,0.750000>
--- with assumed_gamma srgb:
// 1) using srgb: eval_pigment = <0.750000,0.750000,0.750000>
// 2) using rgb:  eval_pigment = <0.750000,0.750000,0.750000>

Under assumed_gamma 1.0, the evaluated values are correct. But under
assumed_gamma 2.2, the result with srgb is *slightly* off from the original
value. I have no idea why. (I would have thought that those two values would be
MUCH different, like under assumed_gamma 1.0).

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
>
> The various results using different assumed_gamma values:
> --- With assumed_gamma 1.0:
> 1) using srgb: eval_pigment = <0.522522,0.522522,0.522522> // correct
> 2) using rgb:  eval_pigment = <0.750000,0.750000,0.750000> // correct
> --- With assumed_gamma 2.2:
> // 1) using srgb: eval_pigment = <0.744501,0.744501,0.744501> // ??
> // 2) using rgb:  eval_pigment = <0.750000,0.750000,0.750000>
> --- with assumed_gamma srgb:
> // 1) using srgb: eval_pigment = <0.750000,0.750000,0.750000>
> // 2) using rgb:  eval_pigment = <0.750000,0.750000,0.750000>
>
> Under assumed_gamma 1.0, the evaluated values are correct. But under
> assumed_gamma 2.2, the result with srgb is *slightly* off from the original
> value. I have no idea why. (I would have thought that those two values would be
> MUCH different, like under assumed_gamma 1.0).

The srgb keyword always returns a color that *looks* the same across all
assumed_gamma settings.  To take your example, srgb 0.75 will *look* the same
whether your scene uses assumed_gamma 1, assumed_gamma 2.2, or assumed_gamma
srgb.  But this implies that, internally, it will evaluate to different rgb
values depending on the assumed_gamma setting.

When you use assumed_gamma srgb, the scene's nonlinearity aligns with the color
definition, which is why rgb and srgb return the same value.  And since sRGB is
close to gamma 2.2, rgb and srgb return close, but not identical, values under
assumed_gamma 2.2.

Post a reply to this message