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

On 2021-04-06 10:53 AM (-4), Kenneth wrote:
> 
> 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]?)"

Wrong, wrong, wrong!  <104,230,75> is outside the sRGB domain, so you
must divide it by 255 before applying the srgb keyword.  The expression
  srgb <104,230,75> / 255
accomplishes this because, as previously discussed, the numeric
expression is evaluated before the sRGB to linear conversion is applied.

Again, the reason you have such triplets in the first place is that
color values are usually specified in byte triplets; but POV-Ray does
not work with byte triplets; it works with floating point vectors.  This
is the reason why dividing by 255 is the exception to the rule.

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

Here is the general sequence:

1. An sRGB triplet that comes from a color picker, eyedropper tool, or
   published Web source is typically in the range <0,0,0> ...
   <255,255,255>.  Divide this by 255 to bring it into the range
   <0,0,0> ... <1,1,1>.  This /must/ be done first thing, and is the
   only math that should ever be done at this stage, though it may be
   combined with step 2.

2. #declare the color with the srgb keyword.  The resulting identifier
   contains a linear color.

3. Now, do whatever additional math you need on the identifier.  You may
   do this in a pigment or light_source or wherever.

If your color is from colors.inc, then you /must/ skip step 1, because
these colors are already within <0,0,0> ... <1,1,1>.  For these colors,
you should use the srgbft keyword in step 2, because they are already
declared with filter and transmit components.

If your color comes from function eval_pigment(), you must skip steps 1
/and/ 2.  Such colors are already within POV-Ray's working space, and
starting with POV-Ray 3.7, this includes image maps.

If you are starting with a fractional literal such as <.7,.8,.9>, then
I'm with Ive: I don't know why you'd want to mess with non-linear
encoding at all.  Just start with a literal triplet that looks correct
with the rgb keyword.

Post a reply to this message

Ive <ive### [at] lilysoftorg> wrote:
> Am 4/6/2021 um 17:48 schrieb Kenneth:
>
> > 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.
>

Well! Now we're getting somewhere. There *is* a major misunderstanding, although
I'm not yet sure where. Here's my own breakdown and logic:

I run my old version of Photoshop in it's gamma 2.2 'working gamma space', as
most people do (unless newer versions run in 'srgb'-- but that's a minor
quibble.)

When I want to specify "50% gray" there, I use r-g-b values of <128,128,128> in
the 0-255 range. And the HSB indicators there give B or 'brightness' as 50.  I
have always understood the  visual result there (under 2.2 gamma) to be the
*perceptual* version of 50% gray-- what we would 'expect' to see as pleasing
half black/half white.

But Photoshop allows me to change the working gamma space to 1.0-- in which case
the 50% gray now looks too bright 'perceptually.' However, the <128,128,128>
values there have NOT changed, nor has the B of 50. In effect, all I have done
is to change the working gamma space that the 50%-gray appears in-- the values
themselves are 'what they are.' At least in Photoshop.

Now, in  POV-ray, working in it's assumed_gamma 1.0 universe, I bring in
<128,128,128>/255 and use it as simple RGB, at 'ambient 1.0'-- as a raw 'linear'
color, in other words. (That's what I currently undertstand 'rgb' to mean.) The
visual result is the same as in Photoshop in it's *gamma 1.0 environment*. So it
seems logical to me that the initial <128,128,128> values in PS are 'linear'
values, not sRGB values-- because using them as rgb in POV-ray (divided by 255)
reproduces the identical visual result  in BOTH  gamma-1.0 environments... the
'linear' environments.

Yet it seems that my entire conception is completely wrong-- that PS's
<128,128,128> is *already* SRGB <128,128,128>/255.

So going into in your IC app, and using the OPTIONS/BACKGROUND feature, I see
the r-g-b sliders at '0.5' (by default.) I take that to mean "50% gray" in
whatever sense or gamma environment is meant there...maybe gamma 1.0? So I
compare the appearance of IC's generated 0.5 gray background with PS's 'gamma
1.0' appearance of <128,128,128>, and with POV-ray's   rgb <128,128,128>/255 at
assumed_gamma 1.0. All three *look* identical to me, in their own environments.

Yet IC reports its own '0.5' gray as being  'sRGB 187'. Not 128, as in
Photoshop.  A calculation shows that 187/255  is approximately 128/255 to the
power of 1/2.2. (I'm aware that  2.2 should actually be replaced with the more
complex 'srgb' math equation.) It's not clear to me yet what the discrepancy is
as to why Photoshop reports 50% gray as <128,128,128>-- and *if* indeed those
are supposed to be 'srgb' values rather than 'linear' like I thought--  while
IC reports <187,187,187> instead. And I would guess that other color-picker apps
adhere to PS's way of representing the values.

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

"Patience is a virtue." (so said Confucius... or someone...)  ;-)

Post a reply to this message

Cousin Ricky <ric### [at] yahoocom> wrote:
> On 2021-04-06 10:53 AM (-4), Kenneth wrote:
> >
> > ...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]?)"
>
> Wrong, wrong, wrong!  <104,230,75> is outside the sRGB domain, so you
> must divide it by 255 before applying the srgb keyword.  The expression
>   srgb <104,230,75> / 255
> accomplishes this because, as previously discussed, the numeric
> expression is evaluated before the sRGB to linear conversion is applied.

Ah, yes. I understand now. The sRGB domain needs to be 0.0-1.0. Thanks!
>
> If your color comes from function eval_pigment(), you must skip steps 1
> /and/ 2.  Such colors are already within POV-Ray's working space, and
> starting with POV-Ray 3.7, this includes image maps.

Yep, I already understood that to be the case. As the docs say, "When
interpreting such values as a vector or accessing individual components, you
will get the linear values..."
>
> If you are starting with a fractional literal such as <.7,.8,.9>, then
> I'm with Ive: I don't know why you'd want to mess with non-linear
> encoding at all.  Just start with a literal triplet that looks correct
> with the rgb keyword.

You're correct, of course. In my case, I was pulling in RGB colors from an *old*
scene-- circa v3.5 or 3.6-- that I used to mistakenly run with an assumed_gamma
of 2.2(!), just to get the rgb colors there to 'look' the way I thought they
should. Some were of the form <.7,.8,.9>, some as like <104,230,75>/255. That
was way before the 'srgb' keyword was introduced, and before I started correctly
using assumed_gamma 1.0. So I'm updating the old colors to srgb now, to try and
reproduce some semblance of what I saw in the old days.

Post a reply to this message