|
 |
Am 10/30/2020 um 23:29 schrieb Kenneth:
> Ive <ive### [at] lilysoft org> wrote:
>>>
>> As long one is aware that rgb has to be followed by an linear color
>> expression everything is fine while on the other hand an expression like
>> rgb <220, 32, 80>/255 together with assumed_gammma 1.0 cries out to
>> produce an unwanted result.
>
> Sorry, I was just re-reading the posts here. Did you mean to say
> srgb <220, 32, 80>/255 there?
>
> I assume from what's been said that rgb <220, 32, 80>/255 is the same as
> rgb <0.8627,0.1255,0.3137> -- simple division in 'linear' rgb space.
>
> Whereas SRGB <220, 32, 80>/255 would be the one that "cries out to produce an
> unwanted result".
>
> Correct?
>
Err, no!
My point is when somebody uses byte values to express a color he usually
got them from a color picker, from the Windows build in color selector,
from an image processing program or somehow directly from an image file.
In all cases these byte values are gamma encoded.
And even he didn't use any of theses apps I'm sure he *thinks* in an
gamma encoded space as otherwise there is no reason to use byte values
instead of floating points.
Therefor srgb <220, 32, 80>/255 is what he actually wants.
And yes, in this case, the the division by 255 is valid (even when it is
within an non-linear space) because it is NOT a brightness adjustment
(causing hue shifts) but simply converts the byte values to floating
point making them fit into the 0.0 to 1.0 range.
-Ive
Post a reply to this message
|
|
