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

On 4/1/21 12:45 PM, Ive wrote:
> Am 4/1/2021 um 16:53 schrieb William F Pokorny:
...
>>
>> (a) - Ponder one. Is the srgb adjustment valid outside the [0..1] 
>> range? It works, but you get essentially a pow(>1,2.2) result which 
>> doesn't correspond to any 'display adjustment' or 'web visual color'.
>>
> The sRGB transfer function is /per definition/ only valid in the 
> [0.0..1.0] range. Negative values (i.e. out of gamut values) do make 
> only sense within a linear color space and the same goes for values 
> above 1.0 (i.e. HDR values).
> 
...
> 
...
>>
>> Overall, what I'm thinking is srgb makes sense where we are in fact 
>> defining colors within the srgb visual/display color space. Further, 
>> that the old linear encoding is better where any of the incoming 
>> channels values are larger than 1.0(c). I think it likely better to 
>> have the parser force rgb* use over srgb* where any of the channel 
>> values are outside expected srgb space(d).
>>
>> (c) Or less than 0.0 / negative color channel values.
>> (d) And thinking warnings on filter/transmit values >1.0 or <0 as 
>> there are useful tricks with odd f/t values.
>>
>> Thoughts?
> 
> 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.
> But anyhow, I never did use this keyword myself so frankly I don't care 
> much.
> 

Thanks. I was hoping you'd answer. :-)

I think there is a place for the srgb* keywords. I find them useful.

With your confirmation on the range for the sRGB transfer function, the 
implementation allowing the keywords to 'run' outside of intended srgb 
value range was a mistake. I'll be updating my povr branch's srgb* 
keywords to fail during parse on invalid input channel values.

Rambling... With color vector math, we have long had exposures to misuse 
/ naive use. Have done and continue to do my own share of stupid 
stuff... :-)

Bill P.

Post a reply to this message

in news:6067132e$1@news.povray.org William F Pokorny wrote:

> Rambling... With color vector math, we have long had exposures to
> misuse / naive use. Have done and continue to do my own share of
> stupid stuff... :-)
> 

ehhm, you mean artistic use, I hope?

The linear RGB space beyond <1,1,1> is excellent. The only alternative 
would be CIEXYZ or CIELab, but who can define a color in that as easy as 
with rgb.
The sRGB space is ehm, of very limited use imo for defining colours in 
POV-Ray. You put it on a sphere, add a nice warm light and gone is the 
color you intended. 


Ingo

Post a reply to this message

Ive <ive### [at] lilysoftorg> wrote:
>
>
> 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.

Yes, I could have it backwards, although I think I know what you're saying; it
may simply boil down to my own 'comfortable interpretation' of the general idea,
and how I personally think of srgb's use: essentially darkening a given rgb
color (as a simplistic way of describing the *visual* effect). That to me means
"rgb-to-srgb conversion" (whatever the math actually describes), and is most
likely not a technically accurate way of looking at it. I do know that POV-ray
has to operate on *linear* colors internally.

In a good way, your comments have forced me to re-think the entire gamut of
colors, gamma etc., and what may be some misconceptions I have in an even wider
sense. I need to formulate a more detailed response, once I work it all out. For
me, these gamma-related discussions continue to be a brain-twister.

Regarding srgb itself and its *visual* effect on colors, it seems to me that
POV-ray's section on the topic at 3.3.1.7.2 (at least in the built-in version of
the docs) is more about the technical workings of the srgb process *under the
hood* than a more user-friendly description of its visual effect. Every time I
re-read it, I come away thinking that it means exactly the opposite of what I
'see' in a render. Maybe Clipka's discussion of it there will finally 'click'
with me, at some point. I hope so.
>
> > 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
> >
>
> ...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.
>
Ah! Thanks to you (and Cousin Ricky too) for explaining this. I'm beginning to
finally 'see the light' as to what the difference is between, say, srgb
<.7,.8,.9>*.4 and srgb <104,230,75>/255.  It's a minor 'eureka' moment for me,
and clears up one of my sticky misconceptions.

Btw, I can't presently find the reference to that "different kind of example" I
gave; I know I saw it somewhere, but it seems that I got the meaning completely
wrong.

Post a reply to this message

On 4/2/21 11:45 AM, ingo wrote:
> in news:6067132e$1@news.povray.org William F Pokorny wrote:
> 
>> Rambling... With color vector math, we have long had exposures to
>> misuse / naive use. Have done and continue to do my own share of
>> stupid stuff... :-)
>>
> 
> ehhm, you mean artistic use, I hope?
> 
> The linear RGB space beyond <1,1,1> is excellent. The only alternative
> would be CIEXYZ or CIELab, but who can define a color in that as easy as
> with rgb.
> The sRGB space is ehm, of very limited use imo for defining colours in
> POV-Ray. You put it on a sphere, add a nice warm light and gone is the
> color you intended.
> 

:-) I guess adding an example to my short ramble would have been 
helpful. I was trying to say we have potential pitfalls no matter how 
the linear colors within POV-Ray are initially defined. Whenever we 
start doing math with the color vector, we can slip up.

#declare ThisColor = rgbt <0.4,0.3,0.2,0.5>;
background { ThisColor * 2.0 }

when the intent was:

background { ThisColor * 2.0 transmit 0.5 }

Bill P.

Post a reply to this message

Cousin Ricky <ric### [at] yahoocom> wrote:
> On 2021-04-01 10:23 PM (-4), Kenneth wrote:
>
> > Long ago, either [Ive] 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
>
> ...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.
>
> > 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...

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

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.

Post a reply to this message