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