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

Op 10-4-2021 om 15:07 schreef Kenneth:
> 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
> 
> 

Kenneth, I am entirely with you. I have learned a lot from this 
discussion. Understanding fully needs time for me too.

-- 
Thomas

Post a reply to this message

Thomas de Groot <tho### [at] degrootorg> wrote:
>
> Kenneth, I am entirely with you. I have learned a lot from this
> discussion. Understanding fully needs time for me too.
>

Thanks. It's at least nice to know that someone else was perhaps puzzling over
this entire crazy topic too.

For me, it's such a fundamental paradigm shift in my conception of things that
it's like I awoke one day to find that the sky is actually green, not blue like
I always thought. :-P

Just about the only thing I'm sure of at the moment is that I can take a color
from Photoshop, slap the 'srgb' keyword on it in POV-ray, and it looks like what
I expect to see! All the rest of this stuff keeps me awake at nights, wondering
where I went wrong...

But it's a good exercise for the ol' brain cells-- it keeps them active, ha.

Post a reply to this message