POV-Ray : Newsgroups : povray.general : strange problem with srgb color in light_source Server Time
28 Mar 2024 14:30:54 EDT (-0400)
  strange problem with srgb color in light_source (Message 11 to 20 of 45)  
<<< Previous 10 Messages Goto Latest 10 Messages Next 10 Messages >>>
From: Thomas de Groot
Subject: Re: strange problem with srgb color in light_source
Date: 1 Apr 2021 10:54:57
Message: <6065dec1@news.povray.org>
Op 1-4-2021 om 16:00 schreef Ive:
> 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

Well, well, well... It seems I did /not/ remember correctly after all... ;-)

-- 
Thomas


Post a reply to this message

From: Kenneth
Subject: Re: strange problem with srgb color in light_source
Date: 1 Apr 2021 10:55:00
Message: <web.6065de7ea9b7c959d98418916e066e29@news.povray.org>
"Bald Eagle" <cre### [at] netscapenet> wrote:
> It also seems that you're not specifying a light color in your light_source
> block, only a pigment for your looks_like container.

Nope, it's there and works. But thanks for your code example, which is always of
interest ;-)

I originally thought the problem might *be* the addition of the looks_like
object... or even the added old-style 'color' keyword. I spent a few wasted
minutes going down those rabbit holes...


Post a reply to this message

From: Subclick
Subject: Re: strange problem with srgb color in light_source
Date: 1 Apr 2021 12:16:02
Message: <87lfa2yo8u.fsf@sp.am>
"Kenneth" <kdw### [at] gmailcom> writes:

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

According to the documentation, colors are stored internally as
five-component vectors, which represent the color components in the
ordinary RGB space—linear if you’re using ‘assumed_gamma 1’—in addition
to filter and transmit.  Therefore, your ‘TEMP_COLOR’ variable does not
remember that it was set using the ‘srgb’ keyword, or the original sRGB
color values.  In the light-source declaration, you’re multiplying by
50000 each of the five components of the color vector stored in the
variable, i.e., the ordinary RGB color components, along with filter and
transmit, which don’t matter in this context.

Perhaps we could use a macro like this in the ‘colors.inc’ file:

  // Converts a color given in sRGB space to one in the ordinary RGB
  // space determined by ‘assumed_gamma’.
  #macro CsRGB2RGB(Color)
    #local Result = srgbft Color
    (Result)
  #end

Now ‘#declare C4 = CsRGB2RGB(rgb <.5, .3, .7>)*50000;’ does work.


Post a reply to this message

From: Ive
Subject: Re: strange problem with srgb color in light_source
Date: 1 Apr 2021 12:45:08
Message: <6065f894$1@news.povray.org>
Am 4/1/2021 um 16:53 schrieb William F Pokorny:
> On 4/1/21 7:51 AM, Subclick wrote:
> 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'.
> 
The sRGB transfer function is /per definition/ only valid in the 
[0.0..1.0] range. Negative values (i.e. out of gamut values) do make 
only sense within a linear color space and the same goes for values 
above 1.0 (i.e. HDR values).


> --- 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
> 
The un-commended third version is a dangerous one:
first reason: it will happen easily that you leave the defined range for 
the transfer function (see above).
second reason: for any non gray value it will not just change the 
brightness but also the hue, something that usually nobody wants.

> #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).
>
filter and transmit values should always be linear and are completely 
independent from the sRGB transfer function.

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

IMHO yes.

> 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?

I did argue a bit with Christoph at the time he was making the 
suggestion for introducing the srgb keyword.
I was against it and my arguments where pretty much the problems you are 
mentioning here.
Christoph's argument was mainly that whole purpose of the srgb keyword 
is to make life easier for people who use a color picker within any 
paint software to select their colors out of pictures.
Well, reality is that people are using it because they think it somehow 
solves all gamma related problems -  but without actually understanding 
what it does.
But anyhow, I never did use this keyword myself so frankly I don't care 
much.

-Ive


Post a reply to this message

From: Bald Eagle
Subject: Re: strange problem with srgb color in light_source
Date: 1 Apr 2021 13:35:00
Message: <web.60660391a9b7c9591f9dae3025979125@news.povray.org>
I was doing a little surfing around when looking at some ShaderToy methods, and
perhaps normalizing all of the color data to 0-1 before applying any power
functions would be helpful.

https://towardsdatascience.com/everything-you-need-to-know-about-min-max-normalization-in-python-b79592732b79

https://towardsdatascience.com/how-and-why-to-standardize-your-data-996926c2c832

Anything out of range gets a multiplier stored for later use.
Values get abs () and MinMaxed, then whatever other operations can be performed.
Then the MinMax gets undone, the sign corrected, and the result spit out.

I'm thinking that there have to be other softwares that have handled all of
this, and certainly companies that manufacture film, printers, monitors, and
other color-sensitive products must have worked a lot of this out already.   I
know that the guy who did the polynomial texture mapping for Hewlett Packard
posted all of that work on the web for free.   Might be worth contacting some
color-correction specialists or just posting some ads requesting help.
StackExchange, StackOverflow, ... those sorts of places.


No sense in keeping this place an echo chamber when we can draw on the whole
wide world of experience.


Post a reply to this message

From: Cousin Ricky
Subject: Re: strange problem with srgb color in light_source
Date: 1 Apr 2021 19:00:09
Message: <60665079$1@news.povray.org>
On 2021-04-01 8:55 AM (-4), Kenneth wrote:
> 
> 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.

It's not mathematical; it's procedural.  Once the srgb keyword does its
job, it goes home for the day.  So in your color TEMP_COLOR*50000, there
is no srgb calculation.

Try thinking of TEMP_COLOR as having been permanently converted to
linear rgb; once the srgb keyword conversion is applied, it has no
memory of having ever been non-linear.


Post a reply to this message

From: Kenneth
Subject: Re: strange problem with srgb color in light_source
Date: 1 Apr 2021 19:55:00
Message: <web.60665c27a9b7c959d98418916e066e29@news.povray.org>
Cousin Ricky <ric### [at] yahoocom> wrote:
> On 2021-04-01 8:55 AM (-4), Kenneth wrote:

> > ...So it looks like the parser
> > *is* making some kind of mathematical distinction, whatever that is.
>
> It's not mathematical; it's procedural.  Once the srgb keyword does its
> job, it goes home for the day.  So in your color TEMP_COLOR*50000, there
> is no srgb calculation.
>
> Try thinking of TEMP_COLOR as having been permanently converted to
> linear rgb; once the srgb keyword conversion is applied, it has no
> memory of having ever been non-linear.

Ah!! My "light bulb of understanding" has finally turned on. That's fascinating,
and extremely helpful. Thanks.

Before reading your post, I did a visual 'difference' test in Photoshop (wildly
exaggerated) of two renders, one using
       color TEMP_COLOR*50000  (with my pre-#declared srgb color)
and the 2nd using the #debug results of that construct...
       rgb <10702.1, 3661.9, 22399.4>

The results are absolutely identical. Maybe that was to be expected, given that
the 2nd is derived from the 1st(?) But I wanted to be certain that the colors
and brightness values agreed, and that it wasn't just 'wishful thinking'.


Post a reply to this message

From: Cousin Ricky
Subject: Re: strange problem with srgb color in light_source
Date: 1 Apr 2021 20:16:47
Message: <6066626f$1@news.povray.org>
On 2021-04-01 12:45 PM (-4), Ive wrote:
> Am 4/1/2021 um 16:53 schrieb William F Pokorny:
>>
>> 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.

This is a good policy.  In fact it would seem the only policy that works.

>> (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.
> 
> IMHO yes.

This sounds like an excellent idea; and for negative values as well.  It
would even have forestalled Kenneth's problem to begin with.

However, it would break some existing scenes, including Norbert Kern's
"Light & Shadows."  I'm not sure how to handle a feature that was
allowed to be used outside its defined domain.  Perhaps a version check
could resolve this, or maybe just stick with a warning?

> I did argue a bit with Christoph at the time he was making the
> suggestion for introducing the srgb keyword.
> I was against it and my arguments where pretty much the problems you are
> mentioning here.
> Christoph's argument was mainly that whole purpose of the srgb keyword
> is to make life easier for people who use a color picker within any
> paint software to select their colors out of pictures.
> Well, reality is that people are using it because they think it somehow
> solves all gamma related problems -  but without actually understanding
> what it does.

I must say I did not foresee all the confusion that the srgb keywords
would cause, perhaps because I understood the general concept of gamma
before I started using POV-Ray.  But I still think the keywords are a
great convenience, given Christoph's rationale--especially considering
that the color definitions in POV-Ray's own colors.inc are gamma
pre-encoded, whether or not the author of that module knew that they were.

However, the Reference Manual does leave the impression that the
keywords are a general gamma solution, even if that wasn't the intent.
While it does mention third party color sources, it doesn't warn against
inappropriate usage.  What constitutes "inappropriate usage" may need to
be fleshed out.


Post a reply to this message

From: Kenneth
Subject: Re: strange problem with srgb color in light_source
Date: 1 Apr 2021 21:10:00
Message: <web.60666dfaa9b7c959d98418916e066e29@news.povray.org>
"Kenneth" <kdw### [at] gmailcom> wrote:

>
> Ah!! My "light bulb of understanding" has finally turned on. That's fascinating,
> and extremely helpful. Thanks.
>
And thanks to Subclick too, for his very similar comments. (I couldn't reply
directly to his message without producing strange syntax problems; seems that
there are still some gremlins hiding in the revamped server/web page
mechanism...)

His idea of a macro is also a very good one, and efficient. It will save me a
lot of effort in not having to first pre-#declare dozens of my old 'multiplied
rgb' colors as  srgb TEMP_____


Post a reply to this message

From: Kenneth
Subject: Re: strange problem with srgb color in light_source
Date: 1 Apr 2021 22:25:00
Message: <web.60668015a9b7c959d98418916e066e29@news.povray.org>
Ive <ive### [at] lilysoftorg> wrote:
> Am 4/1/2021 um 16:53 schrieb William F Pokorny:
> >
> > --- 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
> >
> The un-commented third version is a dangerous one:
> first reason: it will happen easily that you leave the defined range for
> the transfer function (see above).
> second reason: for any non gray value it will not just change the
> brightness but also the hue, something that usually nobody wants.
>

This made me re-think one of my old questions regarding basic rgb-to-srgb color
conversions in a POV-ray scene, that's still a bit of a mystery: Do I understand
correctly now that *any* srgb conversion of a *multiplied* rgb color has the
same kind of hue distortion-- even when the multiplier is <= 1.0? I assume so,
but I want to clearly understand it. For example, given rgb <.7,.8,.9>*.4, the
*wrong* way to do the conversion would be  srgb <.7,.8,.9>*.4 ... and the
correct way (one way) would be to #declare TEMP = srgb <.7,.8,.9> and *then*
multiply TEMP*.4

Long ago, either you or Clipka had given a different kind of example of this,
but used an rgb value of something like
           rgb <104,230,75>/255
and then warned about naively converting that to srgb with a simple
          srgb <104,230,75>/255

But as far as I could tell, there wasn't a clear solution given. Or maybe I just
didn't grasp the whole concept well enough.

So even though the *result* of the three divisions above is < 1.0 for each
vector component, the division operation itself still causes problems with the
new srgb hue? (With the correct solution again being to pre-#declare it as
      srgb <.7,.8,.9>
and *then* to divide that by 255?)

Sorry to rehash this old chestnut, but it's the one remaining/nagging question
for me.


Post a reply to this message

<<< Previous 10 Messages Goto Latest 10 Messages Next 10 Messages >>>

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