Op 01/04/2021 om 15:28 schreef Kenneth:
> 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>
> 

Ive, very rightly, called me to order, and I humbly confess my error. In 
my notes I found that for using srgb in light sources, you have to 
pre-declare a light color like Col = srgb <R,G,B>; and in the 
light_source use Col*Brightness for any intensity changes to the light. 
Makes sense, especially as I use this in my own scenes!

[back to the treadmill]


-- 
Thomas

Post a reply to this message

Am 4/2/2021 um 4:23 schrieb Kenneth:
> 
> 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
> 

Just to make it clear - as I have the impression you do misunderstand 
the srgb keyword: it is NOT about rgb-to-srgb conversion, it is the 
other way around. The srgb keyword is for converting a given sRGB color 
value to a linear RGB color.

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

Well, well well... here goes the same as with my response to Thomas. I'm 
certain that Christoph or myself never warned about /this/ particular 
usage. Quite the opposite: this is exactly what the srgb keyword was 
meant for. You have a byte values (either from a color picker or from 
some web color), and the division by 255 transforms this byte value into 
the 0..1 range. The result is still a sRGB value and prefixing this with 
the srgb keyword simply tells POV-Ray to treat it as such and internally 
converts it to a linear RGB value.

-Ive

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:

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


And that is exactly why I'm working on a full, operational code example for
every single keyword.   "THIS works, THIS doesn't.  Here's the render and the
#debug output to prove it and unambiguously show the full range of input and
output."

ONE code example.
not FOUR HUNDRED newsgroup posts that address 99% of the question..... but.....

Post a reply to this message

On 4/1/21 12:45 PM, Ive wrote:
> Am 4/1/2021 um 16:53 schrieb William F Pokorny:
...
>>
>> (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).
> 
...
> 
...
>>
>> 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.
> 

Thanks. I was hoping you'd answer. :-)

I think there is a place for the srgb* keywords. I find them useful.

With your confirmation on the range for the sRGB transfer function, the 
implementation allowing the keywords to 'run' outside of intended srgb 
value range was a mistake. I'll be updating my povr branch's srgb* 
keywords to fail during parse on invalid input channel values.

Rambling... With color vector math, we have long had exposures to misuse 
/ naive use. Have done and continue to do my own share of stupid 
stuff... :-)

Bill P.

Post a reply to this message

in news:6067132e$1@news.povray.org William F Pokorny wrote:

> Rambling... With color vector math, we have long had exposures to
> misuse / naive use. Have done and continue to do my own share of
> stupid stuff... :-)
> 

ehhm, you mean artistic use, I hope?

The linear RGB space beyond <1,1,1> is excellent. The only alternative 
would be CIEXYZ or CIELab, but who can define a color in that as easy as 
with rgb.
The sRGB space is ehm, of very limited use imo for defining colours in 
POV-Ray. You put it on a sphere, add a nice warm light and gone is the 
color you intended. 


Ingo

Post a reply to this message

Ive <ive### [at] lilysoftorg> wrote:
>
>
> Just to make it clear - as I have the impression you do misunderstand
> the srgb keyword:
> it is NOT about rgb-to-srgb conversion, it is the
> other way around. The srgb keyword is for converting a given sRGB color
> value to a linear RGB color.

Yes, I could have it backwards, although I think I know what you're saying; it
may simply boil down to my own 'comfortable interpretation' of the general idea,
and how I personally think of srgb's use: essentially darkening a given rgb
color (as a simplistic way of describing the *visual* effect). That to me means
"rgb-to-srgb conversion" (whatever the math actually describes), and is most
likely not a technically accurate way of looking at it. I do know that POV-ray
has to operate on *linear* colors internally.

In a good way, your comments have forced me to re-think the entire gamut of
colors, gamma etc., and what may be some misconceptions I have in an even wider
sense. I need to formulate a more detailed response, once I work it all out. For
me, these gamma-related discussions continue to be a brain-twister.

Regarding srgb itself and its *visual* effect on colors, it seems to me that
POV-ray's section on the topic at 3.3.1.7.2 (at least in the built-in version of
the docs) is more about the technical workings of the srgb process *under the
hood* than a more user-friendly description of its visual effect. Every time I
re-read it, I come away thinking that it means exactly the opposite of what I
'see' in a render. Maybe Clipka's discussion of it there will finally 'click'
with me, at some point. I hope so.
>
> > 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
> >
>
> ...Quite the opposite: this is exactly what the srgb keyword was
> meant for. You have a byte values (either from a color picker or from
> some web color), and the division by 255 transforms this byte value into
> the 0..1 range. The result is still a sRGB value and prefixing this with
> the srgb keyword simply tells POV-Ray to treat it as such and internally
> converts it to a linear RGB value.
>
Ah! Thanks to you (and Cousin Ricky too) for explaining this. I'm beginning to
finally 'see the light' as to what the difference is between, say, srgb
<.7,.8,.9>*.4 and srgb <104,230,75>/255.  It's a minor 'eureka' moment for me,
and clears up one of my sticky misconceptions.

Btw, I can't presently find the reference to that "different kind of example" I
gave; I know I saw it somewhere, but it seems that I got the meaning completely
wrong.

Post a reply to this message

On 4/2/21 11:45 AM, ingo wrote:
> in news:6067132e$1@news.povray.org William F Pokorny wrote:
> 
>> Rambling... With color vector math, we have long had exposures to
>> misuse / naive use. Have done and continue to do my own share of
>> stupid stuff... :-)
>>
> 
> ehhm, you mean artistic use, I hope?
> 
> The linear RGB space beyond <1,1,1> is excellent. The only alternative
> would be CIEXYZ or CIELab, but who can define a color in that as easy as
> with rgb.
> The sRGB space is ehm, of very limited use imo for defining colours in
> POV-Ray. You put it on a sphere, add a nice warm light and gone is the
> color you intended.
> 

:-) I guess adding an example to my short ramble would have been 
helpful. I was trying to say we have potential pitfalls no matter how 
the linear colors within POV-Ray are initially defined. Whenever we 
start doing math with the color vector, we can slip up.

#declare ThisColor = rgbt <0.4,0.3,0.2,0.5>;
background { ThisColor * 2.0 }

when the intent was:

background { ThisColor * 2.0 transmit 0.5 }

Bill P.

Post a reply to this message

Cousin Ricky <ric### [at] yahoocom> wrote:
> On 2021-04-01 10:23 PM (-4), Kenneth wrote:
>
> > Long ago, either [Ive] 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
>
> ...This is exactly the sort of thing the srgb keyword was intended
> for.  Dividing by 255 is a special case because colors are often
> specified as byte values.  Hue distortion is not an issue here because
> we are not actually changing the luminance of the color; we are merely
> changing its representation.
>
> > 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?)
>
> No, in this case dividing by 255 is unnecessary...

Aside from me being wrong about my first supposition above, I made a glaring
typo error in the 2nd part, that I just noticed. It must have caused some raised
eyebrows. What I meant to say was,

"(With the correct solution again being to pre-#declare it as
  ---->     srgb <104,230,75>   <----
and *then* to divide that by 255 [within the object or light]?)"

Sorry for the confusion. I don't yet know what the correct answer IS-- I'm still
working it out-- but dividing <.7,.8,.9>/255 made no sense, of course.

Post a reply to this message

Ive <ive### [at] lilysoftorg> wrote:
> Am 4/2/2021 um 4:23 schrieb Kenneth:
>
> Just to make it clear - as I have the impression you do misunderstand
> the srgb keyword: it is NOT about rgb-to-srgb conversion, it is the
> other way around. The srgb keyword is for converting a given sRGB color
> value to a linear RGB color.
>
> > 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
> >
>
> ...Quite the opposite: this is exactly what the srgb keyword was
> meant for. You have a byte values (either from a color picker or from
> some web color), and the division by 255 transforms this byte value into
> the 0..1 range. The result is still a sRGB value and prefixing this with
> the srgb keyword simply tells POV-Ray to treat it as such and internally
> converts it to a linear RGB value.
>

This description of the 'srgb' process is confusing to me and always has been,
and I'll try to explain why. (My *own* way of describing it is the opposite, as
"rgb to srgb"). Perhaps it's simply a difference in wording, between a user's
perspective vs. the actual math process itself.

When picking a color visually in a gamma 2.2 color-picker (like Photoshop),
the color appears a certain way there. Let's say I pick a shade of green. The
actual values in PS are in the 0-255 range, like <104,230,75>/255. Although the
*visual* color I see there is a gamma-bent version of the vector values, the
values themselves are linear-- at least, that is what I have always understood
them to be.

Bringing those values into POV-ray, and initially using them as RGB
<104,230,75>/255, means to me that they are again simply being treated as
*linear* values (and the color is 'washed out' in appearance, compared to
Photoshop.) So, I apply the srgb keyword to re-create the color I originally
saw. But the initial <104,230,75>/255 color vector is itself linear-- which is
the color being given to the 'srgb math' that's internal to POV-ray. In other
words, the initial color is still RGB, not (yet) an 'SRGB version'.

So why is the process instead called "srgb-to-rgb conversion"? The initial
'input color' is linear RGB. I do understand that the final 'processed' color is
again RGB-- it started as RGB values, underwent an 'srgb gamma transformation'
under-the-hood, then emerged as a 'new' RGB color.

So is the term "srgb to rgb" actually just a description of the internal
operation being performed, and the math there? The way I see it is, "rgb color
converted by the srgb process". Thus the confusion-- from a user's perspective,
anyway.

Post a reply to this message

Am 4/6/2021 um 17:48 schrieb Kenneth:
> Ive <ive### [at] lilysoftorg> wrote:
>> Am 4/2/2021 um 4:23 schrieb Kenneth:
>>
>> Just to make it clear - as I have the impression you do misunderstand
>> the srgb keyword: it is NOT about rgb-to-srgb conversion, it is the
>> other way around. The srgb keyword is for converting a given sRGB color
>> value to a linear RGB color.
>>
>>
>> ...Quite the opposite: this is exactly what the srgb keyword was
>> meant for. You have a byte values (either from a color picker or from
>> some web color), and the division by 255 transforms this byte value into
>> the 0..1 range. The result is still a sRGB value and prefixing this with
>> the srgb keyword simply tells POV-Ray to treat it as such and internally
>> converts it to a linear RGB value.
>>
> 

> This description of the 'srgb' process is confusing to me and always has been,
> and I'll try to explain why. (My *own* way of describing it is the opposite, as
> "rgb to srgb"). Perhaps it's simply a difference in wording, between a user's
> perspective vs. the actual math process itself.


Well, you did quote me, and I believe you actually did read it. So I 
really do not understand why you insist on your "own way". Too much 
Frank Sinatra?

It is already all there, to quote myself:

You have a byte values (either from a color picker or from
some web color), and the division by 255 transforms this byte value into
the 0..1 range. The result is still a sRGB value and prefixing this with
the srgb keyword simply tells POV-Ray to treat it as such and internally
converts it to a linear RGB value.

And again: "THE RESULT IS STILL A SRGB VALUE"

At some point even I will loose my patience, but it is not yet reached...


> When picking a color visually in a gamma 2.2 color-picker (like Photoshop),
> the color appears a certain way there. Let's say I pick a shade of green. The
> actual values in PS are in the 0-255 range, like <104,230,75>/255. Although the
> *visual* color I see there is a gamma-bent version of the vector values, the
> values themselves are linear-- at least, that is what I have always understood
> them to be.

And what on earth makes you think so? You can almost always by certain 
that values in byte range (or hexadecimal values) are gamma encoded and 
most probably meant to be sRGB values.

And the visual color you see is the result of the internal processing of 
P'shop and this in itself depends on the way you did setup the CMS of 
P'shop.

> 
> Bringing those values into POV-ray, and initially using them as RGB
> <104,230,75>/255, means to me that they are again simply being treated as
> *linear* values

This sentence is indeed correct...

> (and the color is 'washed out' in appearance, compared to
> Photoshop.)

... well the color looks washed out because this <104,230,75>/255 isn't 
linear. By using the rgb prefix you tell POV-Ray that it is linear but 
in fact it isn't.


> So, I apply the srgb keyword to re-create the color I originally
> saw.

You just apply the srgb keyword to tell POV-Ray that the following value 
is not linear but a sRGB value.

> But the initial <104,230,75>/255 color vector is itself linear

Just to repeat myself a final time: no it is not.


As I think you did mention that you have IC. It's histogram window 
(simply toggle it on/off with the H-key) shows you the gamma encoded 
sRGB value in byte range and the linear scRGB value at the same time 
when you hoover your mouse pointer over the image.


-Ive

Post a reply to this message