"Bald Eagle" <cre### [at] netscapenet> wrote:

> In the same way that the graph shows arrows representing conversions between
> the different curves, I'd like it if we could have a collection macros that
> do the same thing - with a switch to turn on some text output to the debug
> stream describing the inputs and results.  "Converting linear rgb <r, g, b>
> to sRGB <sr, sg, sb>..."   or some such thing.
....

> I would also like to have a way to do what clipka was cautioning me
> about - where a palette of srgb colors could be lightened or darkened using
> a multiplier, and the math would be correct to do it in the proper color
> space.
>
> The new tone-adjusting formulas are:
>
> #declare SRGB_Encode = function (C, M) {
>  select (C-0.0031308, C*12.92*M, C*12.92*M, (1.055 * pow (C, 1/2.4) - 0.055)*M)
> }
>
> #declare SRGB_Decode = function (C, M) {
>  select (C-0.040449936, C/12.92, pow ((C+0.055)/1.055, 2.4)*M)
> }
>
> using M as a multiplier.  Looks like it works correctly, even with  M > 1.
> Perhaps it's not "right", but it's the way I envisioned its usage.
>

I took your advice-- I'm currently working on a complex text scene, taking into
account assumed_gamma, and rgb/srgb colors for both objects AND light sources--
because I personally want to form an opinion about whether or not to use srgb
colors for lights as well, simply to get the color I 'visually' expect as
opposed to 'linear' rgb colors that are intrinsically washed-out in an
assumed_gamma 1.0 environment. I know that Clipka recommended we stick with
'rgb' there, but my test scene will compare the difference.

And I plan to use your excellent conversion functions; it looks like you figured
out how to 'correctly' multiply srgb colors with an M, which is a more complex
situation than multiplying simple rgb colors. Your coding skills are more
sophisticated than mine, so I'll take your word for it ;-)

Can I assume that, if I choose *not* to use the M-multiplier in your functions
(for my simpler test scene), I could just change the function like so? and with
C being a typical 3-part color vector like <.3,.6,.9>)?:

#declare SRGB_Encode = function (C) {
 select (C-0.0031308, C*12.92, C*12.92, (1.055 * pow (C, 1/2.4) - 0.055))

The reason being, that I might restrict any color values to between 0.0 and 1.0,
for a better 'basic' test of things. (Although, I might change my mind.)

When my test scene is complete and working properly, I'll post it elsewhere.

Post a reply to this message

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

> I took your advice-- I'm currently working on a complex text scene, taking into
> account assumed_gamma, and rgb/srgb colors for both objects AND light sources--
> because I personally want to form an opinion about whether or not to use srgb
> colors for lights as well, simply to get the color I 'visually' expect as
> opposed to 'linear' rgb colors that are intrinsically washed-out in an
> assumed_gamma 1.0 environment. I know that Clipka recommended we stick with
> 'rgb' there, but my test scene will compare the difference.

Yes, the washed-out thing is very off-putting.
In situations where there is no readily-available and easily-understood
documentation that adequately explains how all of the pieces influence the final
result, I think it's just as important to understand what _doesn't_ work (and
why ) as it is to be aware of what does work.

In the absence of any "proper" way to achieve an end result, the Warp et al
approach of using assumed_gamma 2.2 is both understandable and unavoidable.
However, if there _exists_ a "proper" method by which to achieve the exact same
results, then it's important to people who spend a lot of time using the system
to be proficient with that, even though there may be specific instances where
they purposefully don't.  (In this instance, using the "proper" gamma for all of
the reasons that clipka outlined involving lighting, monitors, highlights and
shadows, etc.)


> Can I assume that, if I choose *not* to use the M-multiplier in your functions
> (for my simpler test scene), I could just change the function like so? and with
> C being a typical 3-part color vector like <.3,.6,.9>)?:




A multiplier of 1 is ... no multiplier at all.   ;)

Post a reply to this message

> "Bald Eagle" <cre### [at] netscapenet> wrote:

> >
> > The new tone-adjusting formulas are:
> >
> > #declare SRGB_Encode = function (C, M) {
> >  select (C-0.0031308, C*12.92*M, C*12.92*M, (1.055 * pow (C, 1/2.4) - 0.055)*M)
> > }
> >
> > #declare SRGB_Decode = function (C, M) {
> >  select (C-0.040449936, C/12.92, pow ((C+0.055)/1.055, 2.4)*M)
> > }
> >
> > using M as a multiplier.  Looks like it works correctly, even with  M > 1.
> > Perhaps it's not "right", but it's the way I envisioned its usage.
> >
>

[off-topic, sort of...]
Here's some food for thought, which just occured to me-- not about your
functions, but about the conversion formulae themselves (Wikipedia and
elsewhere):

The conversion formulae use a "2.4 gamma" in the computations-- whereas, in
POV-ray, and running antialiasing in a scene, Clipka chose a "2.5 gamma" for the
antialiasing gamma (this in v3.8xx). Maybe I'm cluelessly 'comparing apples to
oranges', but I wonder why Clipka didn't choose "2.4 gamma" instead? I suppose
there *is* a reason, but... :-O

Just something to keep you and me up at nights, wondering about the
difference... ;-)

Post a reply to this message

Am 10/18/2020 um 23:22 schrieb Bald Eagle:
> 
> The new tone-adjusting formulas are:
> 
> #declare SRGB_Encode = function (C, M) {
>   select (C-0.0031308, C*12.92*M, C*12.92*M, (1.055 * pow (C, 1/2.4) - 0.055)*M)
> }
> 
> #declare SRGB_Decode = function (C, M) {
>   select (C-0.040449936, C/12.92, pow ((C+0.055)/1.055, 2.4)*M)
> }
> 
> using M as a multiplier.  Looks like it works correctly
 >


Nope. Both functions are wrong far all M <> 1.0!

If you do not already see this by looking at the formulas just check it: 
Use SRGB_Encode for any value of C and then the result for SRGB_Decode. 
This should give the original value of C.


The correct functions would be

#declare SRGB_Encode = function (C, M) {
  select (C*M-0.0031308, C*12.92*M, C*12.92*M, (1.055 * pow (C*M, 1/2.4) 
- 0.055))
}

#declare SRGB_Decode = function (C, M) {
  select (C-0.040449936, C/12.92, pow ((C+0.055)/1.055, 2.4))*M
}


It worries me for this NG that stuff like this stays uncorrected for 
over 10 days.

-Ive

Post a reply to this message

Ive <ive### [at] lilysoftorg> wrote:

>
> The correct functions would be
>
> #declare SRGB_Encode = function (C, M) {
>   select (C*M-0.0031308, C*12.92*M, C*12.92*M, (1.055 * pow (C*M, 1/2.4)
> - 0.055))
> }
>
> #declare SRGB_Decode = function (C, M) {
>   select (C-0.040449936, C/12.92, pow ((C+0.055)/1.055, 2.4))*M
> }
>
> It worries me for this NG that stuff like this stays uncorrected for
> over 10 days.
>

Well, see? It did get corrected :-) (Not that I would know which is which,
mathematically speaking; functions are sometimes a 'black box' to me.) I like to
think that the newsgroups are *eventually* self-correcting, like after-the-fact
letters to a scientific publication.

I hate to admit that I have not yet tried Bald Eagle's functions; perhaps a
purely visual test would have shown that something might be amiss. [Sorry, B.E.,
I've been busy with other coding.]

He did say, ..."Perhaps it's not "right", but it's the way I envisioned its
usage."

In any case, thanks for the update.

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
> Ive <ive### [at] lilysoftorg> wrote:
>
> >
> > The correct functions would be
> > [snip]

Just to clarify, in my own mind, some things about the use of these functions
(because I'm currently working on an all-inclusive test scene about this stuff):

When using assumed_gamma 1.0, and in POV-ray's preview render:

If I want to *multiply* an RGB color,  rgb 0.7*<.3,.5,.7> would be OK to do.

But if I want to multiply an SRGB color,  srgb 0.7*<.3,.5,.7> would NOT be the
correct way to do it, to get the 'expected' color result (if I understand some
of Clipka's older remarks); I would instead need to use a somewhat different
multiplication scheme. Is that what these 'multiplication functions' are for--
the way to properly 'multiply' an SRGB color?

Or is   srgb 0.7*<.3,.5,.7>  perfectly OK by itself?

Or am I way off base as to what the functions themselves are meant for?

Post a reply to this message

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

> > > The correct functions would be
> > > [snip]

I don't have my initial experiments on hand, and I may have coded something
equivalent, but I will have to graph what you have to see for sure.

> If I want to *multiply* an RGB color,  rgb 0.7*<.3,.5,.7> would be OK to do.

Yes.  I do this all the time, and is what clipka mentioned was fine.

> But if I want to multiply an SRGB color,  srgb 0.7*<.3,.5,.7> would NOT be the
> correct way to do it,

Right, which is what he was telling me at the time.

> to get the 'expected' color result (if I understand some
> of Clipka's older remarks); I would instead need to use a somewhat different
> multiplication scheme. Is that what these 'multiplication functions' are for--
> the way to properly 'multiply' an SRGB color?

Well, let's say that's the _goal_.  My functions are wrong, I'm assuming I've's
are correct.
I _should_ have done what I normally do to self-check, which is convert an rgb
color to srgb, and then use the srgb to rgb conversion to convert it back, and
get the original value.

> Or is   srgb 0.7*<.3,.5,.7>  perfectly OK by itself?

it is not.  When you invoke the srgb keyword, it "moves" you from a linear
interpolation to a non-linear interpolation.  And you have to "do the
multiplication" _inside_ of that nonlinear "space".  I guess maybe you can see
it as moving by a factor M along the curve, rather than along the line.

> Or am I way off base as to what the functions themselves are meant for?

I think you get the general gist of it, if not the explicit details.
I can't remember what time I worked this out - but It may have been a bit late
and it seemed to be what I was shooting for rather than the technically correct
rgb to srgb conversion and multiplication.   But I probably should have stated
that AND provided a proper way for comparison as well.



And to be fair - we've had formula errors lurking in the source for ~25 years
without anyone noticing.... so...

;)


Thanks, Ive, for catching this and pointing it out.
I'll have to go back to it again and not be so lax in double-triple checking,
back-checking, and graphing the results.

I of course would love to hear any commentary you might have on mapping the
lighting and image and pigment curves to each other....

Post a reply to this message

Am 10/28/2020 um 2:03 schrieb Kenneth:
> 
> When using assumed_gamma 1.0, and in POV-ray's preview render:
> 

When using anything but assumed_gamma 1.0 it makes no sense to use the 
srgb keyword anyway.

> If I want to *multiply* an RGB color,  rgb 0.7*<.3,.5,.7> would be OK to do.
> 
Sure.

> But if I want to multiply an SRGB color,  srgb 0.7*<.3,.5,.7> would NOT be the
> correct way to do it, to get the 'expected' color result (if I understand some
> of Clipka's older remarks); I would instead need to use a somewhat different
> multiplication scheme. Is that what these 'multiplication functions' are for--
> the way to properly 'multiply' an SRGB color?
> 
> Or is   srgb 0.7*<.3,.5,.7>  perfectly OK by itself?
> 
No it isn't. When using the keyword "srgb" you just tell POV-Ray that 
the following color term is "sRGB gamma encoded".
Multiplying any non linear color value does not only change the 
brightness but also the hue - and is therefor plain wrong.

I haven't used POV-Ray in years and never used the srgb keyword in my 
whole live (I switched to Adobe RGB a long time ago) so I'm not sure if 
it will swallow this syntax but at least you should get the idea...

#declare C = (srgb <.3,.5,.7>) * 0.7;

> Or am I way off base as to what the functions themselves are meant for?
> 

Yes, I guess this is what BE meant it for even if he called it 
"tone-adjusting" while in fact it is a brightness or intensity adjusting.



...and BTW I just stumbeled over your bold statement

[quote]
simply to get the color I 'visually' expect as
opposed to 'linear' rgb colors that are intrinsically washed-out in an
assumed_gamma 1.0 environment.
[/quote]

I used from the very start (more then 2 decades ago, I guess 3.0 at the 
time) assumed_gamma 1.0 (I already had some experience in the field of 
image processing) and no image I ever created suffered from a washed-out 
look. Some early images of mine did look ugly because my own bad choice 
of colors or bad arrangement of objects but these are no gamma related 
problems ;)


BTW during the early phase of POV-Ray 3.7 alpha development I had this
on my webpage:

https://www.lilysoft.org/Stuff/gamma.html

thankfully Christoph did make all the described workarounds obsolete as 
he improved the image file handling and also implemented an image file 
related gamma keyword as I did suggest there, so after the 3.7 release I 
removed any direct link from my side.

And BTW-2 your cityscape looks phantastic and things like this are still 
the strength of POV-Ray even when it has sadly fallen far behind as a 
render engine.


-Ive

Post a reply to this message

Am 10/28/2020 um 2:43 schrieb Bald Eagle:
> 
> And to be fair - we've had formula errors lurking in the source for ~25 years
> without anyone noticing.... so...
> 
> ;)
> 

I hope you did not get me wrong. I was not criticizing you - having been 
a programmer once I know very well how easily it happens, but I think in 
former times, mistakes here were quickly spotted. But maybe I'm just 
idealizing the past, like old men often do...

To me it was obvious by just looking at the formula that the linear part 
of the function is no longer the tangent to the exponential part for any 
M <> 1. This did surprise me because you already did switch away from 
the official sRGB gamma correction formula that also has a very small 
gap and makes no perfect tangent. Something that did annoy me since the 
very first draft for sRGB by HP and Microsoft.

> 
> Thanks, Ive, for catching this and pointing it out.
> I'll have to go back to it again and not be so lax in double-triple checking,
> back-checking, and graphing the results.

No problem, take your time.

> 
> I of course would love to hear any commentary you might have on mapping the
> lighting and image and pigment curves to each other....
> 

Well, now I have read through the whole thread. What a mess. There are 
so many false statements, combined with completely correct statements 
and - as usually - the worst ones: almost true statements.
And then are the things that are simply not relevant anymore (like the 
whole discussion with Warp - Clipka expanded the color_map syntax so 
that none of the complains is still valid).
So frankly, looking back at the whole thread, I really don't know where 
to begin. But if you have any concrete questions, just ask away...

-Ive


-

Post a reply to this message

Op 28/10/2020 om 05:03 schreef Ive:
> Am 10/28/2020 um 2:03 schrieb Kenneth:
>>

>>
> No it isn't. When using the keyword "srgb" you just tell POV-Ray that 
> the following color term is "sRGB gamma encoded".
> Multiplying any non linear color value does not only change the 
> brightness but also the hue - and is therefor plain wrong.
> 
> I haven't used POV-Ray in years and never used the srgb keyword in my 
> whole live (I switched to Adobe RGB a long time ago) so I'm not sure if 
> it will swallow this syntax but at least you should get the idea...
> 
> #declare C = (srgb <.3,.5,.7>) * 0.7;
> 

Maybe you remember the Bald Eagle / Clipka discussion in 
http://news.povray.org/povray.advanced-users/thread/%3C57894ece%241%40news.povray.org%3E/

I digested that at the time in the attached macro. I think (?) this is 
(part of) this answer...


-- 
Thomas

Post a reply to this message

Attachments:
Download 'utf-8' (8 KB)