POV-Ray : Newsgroups : povray.general : strange problem with srgb color in light_source : Re: strange problem with srgb color in light_source Server Time
21 Jun 2021 12:57:17 EDT (-0400)
  Re: strange problem with srgb color in light_source  
From: Kenneth
Date: 1 Apr 2021 22:25:00
Message: <web.60668015a9b7c959d98418916e066e29@news.povray.org>
Ive <ive### [at] lilysoftorg> wrote:
> Am 4/1/2021 um 16:53 schrieb William F Pokorny:
> >
> > --- Some code with which to play
> > #version 3.8;
> > global_settings { assumed_gamma 1 }
> > #declare GreyBckGnd = srgb <0.5,0.5,0.5>;
> > // background { color GreyBckGnd } // Found it too bright
> > // background { GreyBckGnd * 0.2 } // Adjustment linear space
> >    background { srgb <0.5,0.5,0.5>*0.2 } // Adjustment srgb space
> >
> The un-commented third version is a dangerous one:
> first reason: it will happen easily that you leave the defined range for
> the transfer function (see above).
> second reason: for any non gray value it will not just change the
> brightness but also the hue, something that usually nobody wants.

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

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

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?)

Sorry to rehash this old chestnut, but it's the one remaining/nagging question
for me.

Post a reply to this message

Copyright 2003-2021 Persistence of Vision Raytracer Pty. Ltd.