POV-Ray : Newsgroups : povray.general : strange problem with srgb color in light_source : Re: strange problem with srgb color in light_source Server Time
17 May 2024 19:52:14 EDT (-0400)
  Re: strange problem with srgb color in light_source  
From: Ive
Date: 6 Apr 2021 15:05:25
Message: <606cb0f5@news.povray.org>
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

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.