On 2021-03-31 12:04 PM (-4), Kenneth wrote:
> [running Windows 10]
> 
> While updating a very old scene's rgb colors to srgb, I came across what seems
> to be a bug when using a *multiplied* srgb color in a light_source--
> specifically, when using fade_distance and fade_power in the light. The effect
> is as if fade_distance/fade power are not working at all-- the light is
> completely blasted-out and too bright-- whereas those features do work correctly
> with rgb colors. I get the same results in v3.7.0 and in the latest experimental
> v3.8xx Windows build that 'piggybacks' on v3.7.
> 
> I originally thought that this was a consequence of merely multiplying an srgb
> color-- due to the underlying complex math formula for converting rgb-to-srgb.
> But that's not the reason, because I experimented and found a rather strange way
> to solve the problem-- although *why* the fix works is kind of a mystery too.
> 
> I've included a simple test scene to see the results, which has three choices
> for which 'kind' of color to use.
> 
> When simply specifying srgb <.5,.3,.7>*50000  *within* the light's code, the
> effect is super-bright, as if fade_distance and fade_power are non-existent. But
> when pre-#declaring the color as  srgb <.5,.3,.7>,  the color and lighting
> intensity both work as expected. For some reason, the  srgb  keyword itself
> seems to be part of the problem, when used *directly* in the light_source block.

It's working exactly as it should.  When you include the 50000 in the
srgb statement itself, the 50000 is multiplied by the vector *before*
the sRGB function is applied.  Raise that to power 2.4, and you get a
very big number.

To see what is going on, render the following code with -F, then check
the message window.

----------[BEGIN CODE]----------
#version 3.7;
global_settings { assumed_gamma 1.0 }

#declare C1 = color rgb <.5,.3,.7>*50000;
#declare C2 = color srgb <.5,.3,.7>*50000;
#declare C2a = color srgb <25000,15000,35000>;
#declare TEMP_COLOR = srgb <.5,.3,.7>;
#declare C3 = color TEMP_COLOR*50000;

#debug concat ("C1 = <", vstr (5, C1, ", ", 0, 1), ">\n")
#debug concat ("C2 = <", vstr (5, C2, ", ", 0, 1), ">\n")
#debug concat ("C2a = <", vstr (5, C2a, ", ", 0, 1), ">\n")
#debug concat ("TEMP_COLOR = <", vstr (5, TEMP_COLOR, ", ", 0, 4), ">\n")
#debug concat ("C3 = <", vstr (5, C3, ", ", 0, 1), ">\n")
-----------[END CODE]-----------

> It would be interesting to know if others who use Linux builds of the source
> code see the same problem, and if the solution works there too.

I'm Using GNU/Linux, and my results are:

----------[BEGIN OUTPUT]----------
C1 = <25000.0, 15000.0, 35000.0, 0.0, 0.0>
C2 = <31568418816.0, 9264400384.0, 70787989504.0, 0.0, 0.0>
C2a = <31568418816.0, 9264400384.0, 70787989504.0, 0.0, 0.0>
TEMP_COLOR = <0.2140, 0.0732, 0.4480, 0.0000, 0.0000>
C3 = <10702.1, 3661.9, 22399.4, 0.0, 0.0>
-----------[END OUTPUT]-----------

Post a reply to this message