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 Apr 2024 16:02:45 EDT (-0400)
  Re: Stock colors and assumed_gamma 1 in POV-Ray 3.6  
From: BayashiPascal
Date: 12 Oct 2020 19:25:00
Message: <web.5f84e4d576c60ba8dfdf9a980@news.povray.org>
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

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