[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 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.

-------
#version 3.7;
global_settings{assumed_gamma 1.0}
#default{finish{ambient .07 emission 0 diffuse .85}}

camera {
  perspective
  location  <0, 4, -4>
  look_at   <0, 0,  0>
  right     x*image_width/image_height
  angle 67
}

#declare TEMP_COLOR = srgb <.5,.3,.7>; // pre-#declaring the srgb color
// solves the multiplication problem in the light

light_source {
  0*x
// three choices...

//color rgb <.5,.3,.7>*50000 // this works OK

  // OR...
color srgb <.5,.3,.7>*50000    // this does NOT work correctly-- very
// odd results

  // OR...
 //color TEMP_COLOR*50000 // this DOES work correctly

  looks_like{sphere{0,.1
  texture{pigment{srgb <1,.5,.5>}finish{ambient 0 emission 1 diffuse 0}}}}
  fade_distance .01
  fade_power 2.0
  translate 2*y
}

plane{y,0 pigment{srgb .5}}

// objects
#declare SC = seed(34);
#for(i,1,15)
cylinder{0, 1*y,.2
pigment{srgb <.3 + .7*rand(SC),.3 + .7*rand(SC),.3 + .7*rand(SC)>}
translate 2*x
rotate i*360/15*y
}
#end

Post a reply to this message

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

Op 31/03/2021 om 23:28 schreef Cousin Ricky:
> 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.
> 

If I remember correctly, Clipka always hammered on:
- NEVER do this: srgb <.5, .3, .7>*50000;
- ALWAYS do this: srgb <.5*50000, .3*50000, .7*50000>;


-- 
Thomas

Post a reply to this message

It also seems that you're not specifying a light color in your light_source
block, only a pigment for your looks_like container.
#macro added and tweaked.
Should be (mostly) good.

#version 3.8;
global_settings {assumed_gamma 1.0}
#default {finish {ambient 0.07 emission 0 diffuse 0.85}}

camera {
  perspective
  location  <0, 4, -4>
  look_at   <0, 0,  0>
  right     x*image_width/image_height
  angle 67
}

#macro msrgb (vec, mult)
 srgb <vec.x*mult, vec.y*mult, vec.z*mult>
#end


#declare TEMP_COLOR = srgb <.5,.3,.7>;

light_source {
  0*x
 msrgb (<0.5, 0.3, 0.7>, 50)
  looks_like {
   sphere {0, 0.1
    texture {
     pigment {rgb 1}
     finish {ambient 0 emission 1 diffuse 0}
    }
   }
  }
  fade_distance 0.1
  fade_power 2.0
  translate 2*y
}

plane {y, 0 pigment {srgb .5}}

// objects
#declare SC = seed(34);
#for(i,1,15)
cylinder{0, 1*y,.2
pigment{srgb <.3 + .7*rand(SC),.3 + .7*rand(SC),.3 + .7*rand(SC)>}
translate 2*x
rotate i*360/15*y
}
#end

Post a reply to this message

Thomas de Groot <tho### [at] degrootorg> writes:

> If I remember correctly, Clipka always hammered on:
> - NEVER do this: srgb <.5, .3, .7>*50000;
> - ALWAYS do this: srgb <.5*50000, .3*50000, .7*50000>;

If anything, the latter makes it clearer the multiplications are being
done /before/ interpreting the vector’s components as sRGB color
values.  If you want to multiply a light source’s intensity, you have to
either store the color in a variable and then multiply it, like Kenneth
did, or use a function to convert the sRGB values to linear RGB and
multiply the latter.  From reading the documentation, I’d expect this to
work, too, but unfortunately I get an error when I run it:

  C4 = color (srgb <.5, .3, .7>)*50000;

Post a reply to this message

Cousin Ricky <ric### [at] yahoocom> wrote:
>
> 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.
>

Thanks for the #debug breakdown; I didn't think to try that. It's very obvious
that the numbers are as you say. I'm still trying to fully grasp the
mathematical results of srgb color multiplication-- even after re-reading Ive's
and Clipka's older newsgroup caveats about this subject! Your succinct
explanation has helped a lot.

But there's one aspect of my example that is still mysterious to me:
By pre-#declaring  TEMP_COLOR=srgb <.5,.3,.7> and then plugging that into the
light as
         color TEMP_COLOR*50000
it would *appear* that the syntax result is again simply  srgb <.5,.3,.7>*50000
-- or maybe a segregated   (srgb <.5,.3,.7>)*50000 ?  I'm not seeing the
essential difference that the #declare produces. So it looks like the parser
*is* making some kind of mathematical distinction, whatever that is.

(BTW, I tried various combinations of parentheses in the light's color itself,
before hitting on the idea of pre-#declaring the color. No combination worked;
some produced fatal errors.)

Here's what made me question whether or not fade_distance/fade_power were even
working with srgb colors: By simply removing those terms from the light, both
rgb <.5,.3,.7>*50000 and srgb <.5,.3,.7>*50000 produced blown-out lighting--
which is to be expected, of course! But the srgb result *with*
fade_distance/fade_power still looked blown out the same way. So I assumed that
the light-fading simply wasn't working. I was fooled :-(

The old scene I was revamping with srgb colors is a *really* complex combination
of #include files, regular lights, spotlights, light_groups etc. The first thing
I did was to change almost all of the scene's colors (and light colors) to srgb
versions, with no testing along the way. Only *then* did I notice the blown-out
super-bright lighting in the scene. I spent hours tracking down the cause-- a
single light with fade_distance/fade_power.

Post a reply to this message

Thomas de Groot <tho### [at] degrootorg> wrote:
>
> If I remember correctly, Clipka always hammered on:
> - NEVER do this: srgb <.5, .3, .7>*50000;
> - ALWAYS do this: srgb <.5*50000, .3*50000, .7*50000>;
>

Unfortunately, that does not work either; the light is still blown-out and super
bright:
Using #debug,
srgb <.5*50000, .3*50000, .7*50000> =
<31568424960.000, 9264402432.000, 70787989504.000>

As Cousin Ricky's #debug analysis shows, it should be:

C3 = <10702.1, 3661.9, 22399.4>

So it seems that there are only two ways to get this srgb-multiplication scheme
to work successfully:

1) To pre-#declare the color as srgb <.5,.3,.7>, and then to plug that into the
light as  TEMP_COLOR*50000

or...
2) to actually use the complex rgb-to-srgb conversion formula itself in the
light (or srgb-to-rgb?), when specifying the color.

I prefer option 1)-- it's so much easier, even if I don't fully understand why
it works  ;-)

Post a reply to this message

Am 4/1/2021 um 8:31 schrieb Thomas de Groot:
> 
> If I remember correctly, Clipka always hammered on:
> - NEVER do this: srgb <.5, .3, .7>*50000;
> - ALWAYS do this: srgb <.5*50000, .3*50000, .7*50000>;
> 

I'm certain Christoph NEVER suggested such a thing. It just involves a 
lot more typing to produce the same wrong/unwanted result. Thats not the 
kind of logic Clipka was usually following.

-Ive

Post a reply to this message

Subclick <no### [at] spam> wrote:
>

> work, too, but unfortunately I get an error when I run it:
>
>   C4 = color (srgb <.5, .3, .7>)*50000;

Yeah, that was one of my experiments as well, trying to use the same logic. But
POV-ray doesn't accept the syntax. If it *did* work, it would be interesting to
see the result.

Post a reply to this message

On 4/1/21 7:51 AM, Subclick wrote:
> Thomas de Groot <tho### [at] degrootorg> writes:
> 
>> If I remember correctly, Clipka always hammered on:
>> - NEVER do this: srgb <.5, .3, .7>*50000;
>> - ALWAYS do this: srgb <.5*50000, .3*50000, .7*50000>;
> 
> If anything, the latter makes it clearer the multiplications are being
> done /before/ interpreting the vector’s components as sRGB color
> values.  If you want to multiply a light source’s intensity, you have to
> either store the color in a variable and then multiply it, like Kenneth
> did, or use a function to convert the sRGB values to linear RGB and
> multiply the latter.  From reading the documentation, I’d expect this to
> work, too, but unfortunately I get an error when I run it:
> 
>    C4 = color (srgb <.5, .3, .7>)*50000;
> 

With my personal povr branch I've been pondering changes to how the 
srgb* keywords work...

The srgb keyword allows us to specify colors in the mostly sRGB space we 
see on the web or in what POV-Ray itself renders by default in v3.7 and 
v3.8 to output file and preview screen.

As a habit I've been declaring colors using srgb space and multiplying 
for adjustment after. The thought being the declared srgb color is a set 
color in a set color space. Further, I can refer to that 'srgb color' by 
common web name and always get that color in my render.

By coding this way I'm also protecting against 'run away' intensity due 
multiplications ahead of the srgb adjustment where the multiplied values 
end up larger than 1.0(a). I only multiply post srgb input; I only 
multiply the previously defined color name.

(a) - Ponder one. Is the srgb adjustment valid outside the [0..1] range? 
It works, but you get essentially a pow(>1,2.2) result which doesn't 
correspond to any 'display adjustment' or 'web visual color'.

--- Ramblings on my srgb use today.
Suppose I first code up a background color which I find too bright. If I 
multiply the defined name by 0.2 while thinking / picking colors in the 
srgb space, I won't get the srgb space 0.1 grey I expect. Multiplying
GreyBkGnd by 0.2 is an adjustment in the linear color space.

Thinking in the srgb color space we most "see," what I really want is to 
multiply the original color vector ahead of the srgb translation into 
linear space so long as the resultant values are all still in the 0-1 range.

--- Some code with which to play
#version 3.8;
global_settings { assumed_gamma 1 }
#declare GreyBckGnd = srgb <0.5,0.5,0.5>;
// background { color GreyBckGnd } // Found it too bright
// background { GreyBckGnd * 0.2 } // Adjustment linear space
    background { srgb <0.5,0.5,0.5>*0.2 } // Adjustment srgb space

#declare GreyAdjust = srgb 0.2;  // I find this oddly useful too, but
// background { GreyBckGnd * GreyAdjust } // adjustment in srgb*srgb


The questionable part is when one or more of the srgb input channels 
goes above 1.0. Or when we have filter transmit channels greater than 
1.0 or summing to more than 1.0 on the vector's multiplication. Perhaps 
filter/transmit a separate issue from the behavior of the srgb* 
keywords?)(b).

(b) Ponder two. Would it be better to warn or err/fail during parse 
where the srgb keyword sees channel inputs >1.0? This would force users 
to deal explicitly with questionable channel input; force them to 
explicitly set the linear intent.

Another option would be to try and manage somehow doing linear 
adjustments for incoming channels >1 in value and srgb adjustments 
otherwise. However, I see that as problematic and likely more confusing 
to end users even if we could work out some standard treatment. In a way 
we have such behavior today, but I think it hard to use and probably 
making no sense where only some of the channels end up at values >1. In 
that case the srgb adjustments are moving differently for the values >1 
than they are for values in the 0-1 range.

Overall, what I'm thinking is srgb makes sense where we are in fact 
defining colors within the srgb visual/display color space. Further, 
that the old linear encoding is better where any of the incoming 
channels values are larger than 1.0(c). I think it likely better to have 
the parser force rgb* use over srgb* where any of the channel values are 
outside expected srgb space(d).

(c) Or less than 0.0 / negative color channel values.
(d) And thinking warnings on filter/transmit values >1.0 or <0 as there 
are useful tricks with odd f/t values.

Thoughts?

Bill P.

Post a reply to this message