On 2021-04-01 8:55 AM (-4), Kenneth wrote:
> 
> But there's one aspect of my example that is still mysterious to me:
> By pre-#declaring  TEMP_COLOR=srgb <.5,.3,.7> and then plugging that into the
> light as
>          color TEMP_COLOR*50000
> it would *appear* that the syntax result is again simply  srgb <.5,.3,.7>*50000
> -- or maybe a segregated   (srgb <.5,.3,.7>)*50000 ?  I'm not seeing the
> essential difference that the #declare produces. So it looks like the parser
> *is* making some kind of mathematical distinction, whatever that is.

It's not mathematical; it's procedural.  Once the srgb keyword does its
job, it goes home for the day.  So in your color TEMP_COLOR*50000, there
is no srgb calculation.

Try thinking of TEMP_COLOR as having been permanently converted to
linear rgb; once the srgb keyword conversion is applied, it has no
memory of having ever been non-linear.

Post a reply to this message

Cousin Ricky <ric### [at] yahoocom> wrote:
> On 2021-04-01 8:55 AM (-4), Kenneth wrote:

> > ...So it looks like the parser
> > *is* making some kind of mathematical distinction, whatever that is.
>
> It's not mathematical; it's procedural.  Once the srgb keyword does its
> job, it goes home for the day.  So in your color TEMP_COLOR*50000, there
> is no srgb calculation.
>
> Try thinking of TEMP_COLOR as having been permanently converted to
> linear rgb; once the srgb keyword conversion is applied, it has no
> memory of having ever been non-linear.

Ah!! My "light bulb of understanding" has finally turned on. That's fascinating,
and extremely helpful. Thanks.

Before reading your post, I did a visual 'difference' test in Photoshop (wildly
exaggerated) of two renders, one using
       color TEMP_COLOR*50000  (with my pre-#declared srgb color)
and the 2nd using the #debug results of that construct...
       rgb <10702.1, 3661.9, 22399.4>

The results are absolutely identical. Maybe that was to be expected, given that
the 2nd is derived from the 1st(?) But I wanted to be certain that the colors
and brightness values agreed, and that it wasn't just 'wishful thinking'.

Post a reply to this message

On 2021-04-01 12:45 PM (-4), Ive wrote:
> Am 4/1/2021 um 16:53 schrieb William F Pokorny:
>>
>> As a habit I've been declaring colors using srgb space and multiplying
>> for adjustment after. The thought being the declared srgb color is a
>> set color in a set color space. Further, I can refer to that 'srgb
>> color' by common web name and always get that color in my render.
>>
>> By coding this way I'm also protecting against 'run away' intensity
>> due multiplications ahead of the srgb adjustment where the multiplied
>> values end up larger than 1.0(a). I only multiply post srgb input; I
>> only multiply the previously defined color name.

This is a good policy.  In fact it would seem the only policy that works.

>> (b) Ponder two. Would it be better to warn or err/fail during parse
>> where the srgb keyword sees channel inputs >1.0? This would force
>> users to deal explicitly with questionable channel input; force them
>> to explicitly set the linear intent.
> 
> IMHO yes.

This sounds like an excellent idea; and for negative values as well.  It
would even have forestalled Kenneth's problem to begin with.

However, it would break some existing scenes, including Norbert Kern's
"Light & Shadows."  I'm not sure how to handle a feature that was
allowed to be used outside its defined domain.  Perhaps a version check
could resolve this, or maybe just stick with a warning?

> I did argue a bit with Christoph at the time he was making the
> suggestion for introducing the srgb keyword.
> I was against it and my arguments where pretty much the problems you are
> mentioning here.
> Christoph's argument was mainly that whole purpose of the srgb keyword
> is to make life easier for people who use a color picker within any
> paint software to select their colors out of pictures.
> Well, reality is that people are using it because they think it somehow
> solves all gamma related problems -  but without actually understanding
> what it does.

I must say I did not foresee all the confusion that the srgb keywords
would cause, perhaps because I understood the general concept of gamma
before I started using POV-Ray.  But I still think the keywords are a
great convenience, given Christoph's rationale--especially considering
that the color definitions in POV-Ray's own colors.inc are gamma
pre-encoded, whether or not the author of that module knew that they were.

However, the Reference Manual does leave the impression that the
keywords are a general gamma solution, even if that wasn't the intent.
While it does mention third party color sources, it doesn't warn against
inappropriate usage.  What constitutes "inappropriate usage" may need to
be fleshed out.

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:

>
> Ah!! My "light bulb of understanding" has finally turned on. That's fascinating,
> and extremely helpful. Thanks.
>
And thanks to Subclick too, for his very similar comments. (I couldn't reply
directly to his message without producing strange syntax problems; seems that
there are still some gremlins hiding in the revamped server/web page
mechanism...)

His idea of a macro is also a very good one, and efficient. It will save me a
lot of effort in not having to first pre-#declare dozens of my old 'multiplied
rgb' colors as  srgb TEMP_____

Post a reply to this message

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

On 2021-04-01 9:06 PM (-4), Kenneth wrote:
> 
> And thanks to Subclick too, for his very similar comments. [SNIP]
> 
> His idea of a macro is also a very good one, and efficient. It will save me a
> lot of effort in not having to first pre-#declare dozens of my old 'multiplied
> rgb' colors as  srgb TEMP_____

As it turns out, I'm working on 2 include files that already have such a
macro, and at least one of them is destined for the Object Collection.
I just tried the macro directly in a light source, and it works!

My next task is to restrict their domains to 0...1.  Currently, the
macros do no range checks.  (Thank you, Ive, for that heads up.)

Post a reply to this message

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

Op 01/04/2021 om 15:28 schreef Kenneth:
> Thomas de Groot <tho### [at] degrootorg> wrote:
>>
>> If I remember correctly, Clipka always hammered on:
>> - NEVER do this: srgb <.5, .3, .7>*50000;
>> - ALWAYS do this: srgb <.5*50000, .3*50000, .7*50000>;
>>
> 
> Unfortunately, that does not work either; the light is still blown-out and super
> bright:
> Using #debug,
> srgb <.5*50000, .3*50000, .7*50000> =
> <31568424960.000, 9264402432.000, 70787989504.000>
> 

Ive, very rightly, called me to order, and I humbly confess my error. In 
my notes I found that for using srgb in light sources, you have to 
pre-declare a light color like Col = srgb <R,G,B>; and in the 
light_source use Col*Brightness for any intensity changes to the light. 
Makes sense, especially as I use this in my own scenes!

[back to the treadmill]


-- 
Thomas

Post a reply to this message

Am 4/2/2021 um 4:23 schrieb Kenneth:
> 
> 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
> 

Just to make it clear - as I have the impression you do misunderstand 
the srgb keyword: it is NOT about rgb-to-srgb conversion, it is the 
other way around. The srgb keyword is for converting a given sRGB color 
value to a linear RGB color.

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

Well, well well... here goes the same as with my response to Thomas. I'm 
certain that Christoph or myself never warned about /this/ particular 
usage. Quite the opposite: this is exactly what the srgb keyword was 
meant for. You have a byte values (either from a color picker or from 
some web color), and the division by 255 transforms this byte value into 
the 0..1 range. The result is still a sRGB value and prefixing this with 
the srgb keyword simply tells POV-Ray to treat it as such and internally 
converts it to a linear RGB value.

-Ive

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:

> 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.


And that is exactly why I'm working on a full, operational code example for
every single keyword.   "THIS works, THIS doesn't.  Here's the render and the
#debug output to prove it and unambiguously show the full range of input and
output."

ONE code example.
not FOUR HUNDRED newsgroup posts that address 99% of the question..... but.....

Post a reply to this message