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