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

On 2021-04-07 8:20 AM (-4), Kenneth wrote:
> Cousin Ricky <ric### [at] yahoocom> wrote:
>>
>> 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.

That makes sense.  I haven't had to do that, because I started using
assumed_gamma 1 from literally my second day using POV-Ray.  I never had
to make any transition.  But if you're converting old scenes, by all
means use srgb <.7,.8,.9>.

I had been wrestling with gamma long before I downloaded POV-Ray, so I
was onto assumed_gamma in version 3.5, before most POVers realized that
this was an issue.

Post a reply to this message

Cousin Ricky <ric### [at] yahoocom> wrote:

> Wrong, wrong, wrong!

Post a reply to this message

Attachments:
Download '54oodi.jpg' (82 KB)

Preview of image '54oodi.jpg'

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

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

The numeric values of the color components are “what they are”; the
light intensities on the screen, and hence the actual color you see,
have changed, because you have changed the relationship between them and
the numeric values of the color components.

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

Neither numbers nor light intensities can by themselves be linear or
otherwise; only the relationship between the former and the latter can.

> The visual result is the same as in Photoshop in it's *gamma 1.0
> environment*.

If the numeric values and the relationship between them and light
intensities are the same, the light intensities are the same.

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

The initial <128, 128, 128> values are just numbers.  By themselves,
they don’t contain any information on whether they’re supposed to be
interpreted as light intensities encoded linearly or in any other
fashion, such as sRGB.  As you said, you can choose different ways to
interpret those values as light intensities—you do it by choosing the
working gamma space.

There’s nothing special about the linear relationship in this regard: if
you choose an arbitrary working gamma space in Photoshop, and use that
gamma value also as POV-Ray’s ‘assumed_gamma’, the visual result will be
the same, too.

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

Therefore, the relationship between numeric color values and light
intensities meant in that IC app is indeed linear—the assumed
gamma is 1.

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

Exactly as it should be: the linear color components, in the 0–1 range,
are <0.5, 0.5, 0.5>; the sRGB components are <187, 187, 187>/255.
Now you’re considering one color and two different relationships between
it and the numeric values used to represent it, so those values are
different in each case.

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

You’ve already answered that yourself: Photoshop reports as <128, 128,
128> the gray you perceptually describe as 50% only when the chosen
working gamma space is the one that roughly matches your perception of
brightness; i.e., gamma 2.2.  Therefore, if you choose that working
gamma space, <128, 128, 128> are roughly the sRGB (similar to gamma 2.2)
values of the gray you see.  If you choose another working gamma space,
you’ll need numeric values different from <128, 128, 128> to get the
same gray, and those new values won’t be the gray’s sRGB values
any more.

> while IC reports <187,187,187> instead.

That’s a different gray.  Those were the sRGB components of the gray
which is half as bright as white physically (linear relationship), not
perceptually.

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Cousin Ricky <ric### [at] yahoocom> wrote:
>
> > Wrong, wrong, wrong!

+10 for the Liam Neeson meme, nice one!

Post a reply to this message

I had to let all of the information here 'sink in' for a few days. Thanks for
all the patience and detailed breakdowns.  It's not easy to change my long-held
basic misconception, going back not just a week or month but for at least 10
years(!) I'm having flashes of insight about all of this... but then I sleep on
it and it disappears :-( I still have a few nagging questions-- but at this
point I might be perceived as the Devil come from Hell, to purposely sow discord
and confusion amongst the populace :-P

Well, it's always good to question one's beliefs, as painful as it can be. I'm
still putting all of the pieces together, to hopefully form a coherent and
crystal-clear understanding of the situation.

I repent!! I've seen the light!! (Sort of.) Please don't kill me :-O

Post a reply to this message