|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
From: William F Pokorny
Subject: Re: strange problem with srgb color in light_source
Date: 1 Apr 2021 10:53:36
Message: <6065de70$1@news.povray.org>
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
|
|