On 2021-04-01 10:23 PM (-4), Kenneth wrote:
> 
> This made me re-think one of my old questions regarding basic rgb-to-srgb color
> conversions in a POV-ray scene, that's still a bit of a mystery: Do I understand
> correctly now that *any* srgb conversion of a *multiplied* rgb color has the
> same kind of hue distortion-- even when the multiplier is <= 1.0? I assume so,
> but I want to clearly understand it. For example, given rgb <.7,.8,.9>*.4, the
> *wrong* way to do the conversion would be  srgb <.7,.8,.9>*.4 ... and the
> correct way (one way) would be to #declare TEMP = srgb <.7,.8,.9> and *then*
> multiply TEMP*.4

That is correct.

> Long ago, either you or Clipka had given a different kind of example of this,
> but used an rgb value of something like
>            rgb <104,230,75>/255
> and then warned about naively converting that to srgb with a simple
>           srgb <104,230,75>/255

Actually, this is exactly how I handle Web colors from official sources,
for example, for AndroidRobot or the Olympic spheres I posted a year
ago.  This is exactly the sort of thing the srgb keyword was intended
for.  Dividing by 255 is a special case because colors are often
specified as byte values.  Hue distortion is not an issue here because
we are not actually changing the luminance of the color; we are merely
changing its representation.

> But as far as I could tell, there wasn't a clear solution given. Or maybe I just
> didn't grasp the whole concept well enough.
> 
> So even though the *result* of the three divisions above is < 1.0 for each
> vector component, the division operation itself still causes problems with the
> new srgb hue? (With the correct solution again being to pre-#declare it as
>       srgb <.7,.8,.9>
> and *then* to divide that by 255?)

No, in this case dividing by 255 is unnecessary.  The point of dividing
by 255 is to get byte values into the domain 0...1.  If you aren't
starting with byte values, then there is no cause to divide by 255.

Post a reply to this message