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