Hi Kenneth - this is something that I was concerned about, tried to address, and
IIRC, did it backwards.

Maybe you can take a look, and see what you think.

http://news.povray.org/povray.text.scene-files/thread/%3Cweb.58cc101945a951b1c437ac910%40news.povray.org%3E/

Apparently there's something with the linear interpolation of the color map that
needs to be addressed as well.

I'm accumulating one of those "infinite to-do lists..."   ;)

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Hi Kenneth - this is something that I was concerned about, tried to
> address, and IIRC, did it backwards.
>
> Maybe you can take a look, and see what you think.
>
>
http://news.povray.org/povray.text.scene-files/thread/%3Cweb.58cc101945a951b1c437ac910%40news.povray.org%3E/
>

I'm genuinely sorry to say that I didn't take note of your color-conversion
macros at the time (March 2017.) That is some NICE work.

I just spent a couple of enjoyable and challenging hours, going through your
macros' code there, and comparing it to the Wikipedia 'conversion' formulae (at
Wikipedia's "srgb" entry). Your math looks to be spot-on-- but of course you're
better at math than I am. ;-) Thanks for the opportunity for the mathematical
'brain boost'.

And you are correct-- your two macros are *reversed* as to their respective
operations! Through no fault of your own: the Wikipedia formulae themselves are
REVERSED. Which may mean that Wikipedia's source for those formulae is also
wrong. I'm amazed that no one has yet corrected the Wikipedia article.

'Fixing' your two macros is a simple matter-- just rename RGB2SRGB(C_linear) as
SRGB2RGB(C_exponential), ha. And vice-versa.

Having done so myself, I converted rgb <.75,.75,.75> to its srgb equivalent.
Result: <0.522522,0.522522,0.522522>

Compare that to:
#declare MY_PIG = pigment{srgb .75}
#debug concat(
"\n","srgb color = <",vstr(3,eval_pigment(MY_PIG, <.2,.2,.2>),",
",0,6),">","\n")
// Result: <0.522522,0.522522,0.522522>

A perfect match. Congrats!

As I experimented with your macros, three things pointed me to the conclusion
that the macro operations were reversed:
1) Your own hint ;-)
2) My *original* <.75,.75,.75> rgb-to-srgb result was 0.880825 -- which was
clearly wrong.
3) In the (mis-named) RGB2SRGB macro, at the near-ending line of
       #local C_srgb = ...
I changed that on a whim to
       #local C_srgb = srgb ....
and the #debug result was... <.75,.75,.75> -- the same as the original color! In
other words, it was first converting the color to (rgb) 0.880825 by the formula,
then #re*-converting it back to (srgb) 0.75. So *something* was amiss somewhere!

Btw, it may not be clear that to *use* your macros, the macro call in a scene
should include  srgb (or rgb, as the case may be). Like so:

box{0,1
pigment{srgb RGB2SRGB(<.75,.75,.75>)}
....
}

If it is left out, POV-ray apparently assumes the color to be 'linear' RGB by
default.

I would humbly suggest that you make a few changes to your March 2017 post. ;-)

Post a reply to this message

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

>
> 'Fixing' your two macros is a simple matter-- just
> rename RGB2SRGB(C_linear) as SRGB2RGB(C_exponential), ha. And vice-versa.

Well, I guess the macros do need a bit more than that in their code... only to
have consistency among the names of their internal variables. Minor work.

>
> Btw, it may not be clear that to *use* your macros, the macro call in a scene
> should include  srgb (or rgb, as the case may be). Like so:

Sorry, I didn't notice that you already gave examples of use, within the macros'
comments.

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
>
> >
> > 'Fixing' your two macros is a simple matter-- just
> > rename RGB2SRGB(C_linear) as SRGB2RGB(C_exponential), ha. And vice-versa.
>
> Well, I guess the macros do need a bit more than that in their code... only to
> have consistency among the names of their internal variables. Minor work.
>

I had some free time, so I 're-packaged' the macros for you, with all the
(minor) changes, and the switch of the macro names. All should work well, but
re-test them for any last-minute typos I may have made.

Post a reply to this message

Attachments:
Download 'color_conversion_macros_redone.txt' (3 KB)

Cousin Ricky <ric### [at] yahoocom> wrote:
>
> So I wrote a scene to render some of the grays with different gamma
> configurations under different POV-Ray versions, then sampled the output
> images and created montages with the sampled values...

Getting back to your original post here, about the slight discrepancies in color
values among the various versions of POV-ray:

I did some *basic* tests, solely in v3.8, using a simple pigment plus the
eval_pigment{...) macro, and I still get slight discrepancies in compared color
values. It somehow comes from the use of  srgb  vs.  rgb  in a color, AND on the
assumed_gamma of the scene.

#declare PIG_C = pigment{rgb <.75,.75,.75>} // CHANGE this from srgb to rgb

#debug concat("\n","PIGMENT_C evaluation = <",vstr(3,eval_pigment(PIG_C,
<.2,.2,.2>),", ",0,6),">","\n\n")

The various results using different assumed_gamma values:
--- With assumed_gamma 1.0:
1) using srgb: eval_pigment = <0.522522,0.522522,0.522522> // correct
2) using rgb:  eval_pigment = <0.750000,0.750000,0.750000> // correct
--- With assumed_gamma 2.2:
// 1) using srgb: eval_pigment = <0.744501,0.744501,0.744501> // ??
// 2) using rgb:  eval_pigment = <0.750000,0.750000,0.750000>
--- with assumed_gamma srgb:
// 1) using srgb: eval_pigment = <0.750000,0.750000,0.750000>
// 2) using rgb:  eval_pigment = <0.750000,0.750000,0.750000>

Under assumed_gamma 1.0, the evaluated values are correct. But under
assumed_gamma 2.2, the result with srgb is *slightly* off from the original
value. I have no idea why. (I would have thought that those two values would be
MUCH different, like under assumed_gamma 1.0).

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
>
> The various results using different assumed_gamma values:
> --- With assumed_gamma 1.0:
> 1) using srgb: eval_pigment = <0.522522,0.522522,0.522522> // correct
> 2) using rgb:  eval_pigment = <0.750000,0.750000,0.750000> // correct
> --- With assumed_gamma 2.2:
> // 1) using srgb: eval_pigment = <0.744501,0.744501,0.744501> // ??
> // 2) using rgb:  eval_pigment = <0.750000,0.750000,0.750000>
> --- with assumed_gamma srgb:
> // 1) using srgb: eval_pigment = <0.750000,0.750000,0.750000>
> // 2) using rgb:  eval_pigment = <0.750000,0.750000,0.750000>
>
> Under assumed_gamma 1.0, the evaluated values are correct. But under
> assumed_gamma 2.2, the result with srgb is *slightly* off from the original
> value. I have no idea why. (I would have thought that those two values would be
> MUCH different, like under assumed_gamma 1.0).

The srgb keyword always returns a color that *looks* the same across all
assumed_gamma settings.  To take your example, srgb 0.75 will *look* the same
whether your scene uses assumed_gamma 1, assumed_gamma 2.2, or assumed_gamma
srgb.  But this implies that, internally, it will evaluate to different rgb
values depending on the assumed_gamma setting.

When you use assumed_gamma srgb, the scene's nonlinearity aligns with the color
definition, which is why rgb and srgb return the same value.  And since sRGB is
close to gamma 2.2, rgb and srgb return close, but not identical, values under
assumed_gamma 2.2.

Post a reply to this message

"Cousin Ricky" <rickysttATyahooDOTcom> wrote:

> When you use assumed_gamma srgb, the scene's nonlinearity aligns with the color
> definition, which is why rgb and srgb return the same value.  And since sRGB is
> close to gamma 2.2, rgb and srgb return close, but not identical, values under
> assumed_gamma 2.2.

"Unlike most other RGB color spaces, the sRGB gamma cannot be expressed as a
single numerical value. The overall gamma is approximately 2.2, consisting of a
linear (gamma 1.0) section near black, and a non-linear section elsewhere
involving a 2.4 exponent and a gamma (slope of log output versus log input)
changing from 1.0 through about 2.3. The purpose of the linear section is so the
curve does not have an infinite slope at zero, which could cause numerical
problems."

https://en.wikipedia.org/wiki/SRGB

So there needs to be a function(_r, _g, _b) {} with a select () statement in it.

Post a reply to this message

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

> So there needs to be a function(_r, _g, _b) {} with a select () statement in it.

Which of course you have, (duh) but what I'm thinking is that the specific way
you implemented the sRGB standard might be one of the slightly different ways
mentioned, compared to how it's actually implemented in POV-Ray.

So, I'd either play with some of the gobbledygook in the wikipedia page, or look
at what Mike Horvath has done
https://github.com/mjhorvath/Mike-Wikipedia-Illustrations
(the whole zip is like 78MB) to see what sorts of color conversion functions he
uses.

because I'm hoping that since he worked closely with clipka on this, that it's
"as-per-POV-Ray"

or we need to dig up the part in the POV-Ray source code where rgb gets
converted to sRGB to see exactly what gets done.

But I got zippo-zero done today, so now I'm going to bed.  :D

Super nice work with the updating - I'm glad you tracked down that Wikipedia was
_wrong_   :O   That's actually been bothering me this whole time, whenever I'd
hearken back to why I wrote them in the first place.   Makes me feel better to
know that I was doing the right thing but with wrong information.  :)

THANK YOU

Strange that neither Mike nor Christoph picked up on it - but maybe they
mentioned it in one of his scene development threads?

Post a reply to this message

On 10/14/20 10:24 PM, Bald Eagle wrote:
> Super nice work with the updating - I'm glad you tracked down that Wikipedia was
> _wrong_   :O   That's actually been bothering me this whole time, whenever I'd
> hearken back to why I wrote them in the first place.   Makes me feel better to
> know that I was doing the right thing but with wrong information.  :)

would one of you guys PLEASE be a little bit more specific about what is 
wrong on wiki... several of you are so darn verbose my eyes have just 
glazed over

Post a reply to this message

Ash Holsenback <no### [at] spamcom> wrote:

> would one of you guys PLEASE be a little bit more specific about what is
> wrong on wiki... several of you are so darn verbose my eyes have just
> glazed over

There once was a man named Jim
My verbosity was getting to him
So instead of Wikipedia
I rendered some media {}
And sent a pretty picture to him

:)   <curtsy>

Don't take this as the final answer, but what I THINK Kenneth found is where it
says

"These linear RGB values are not the final result; gamma correction must still
be applied. The following formula transforms the linear values into sRGB:"

and then immediately following those formulae

The reverse transformation
"Again the sRGB component values Rsrgb, Gsrgb, Bsrgb are in the range 0 to 1.
(Values in the range of 0 to 255 can simply be divided by 255.0)."

should be reversed.


But I haven't re-wrapped my head around the whole gamma thing _again_....

my macros originated from this discussion:

http://news.povray.org/58cb2917%241%40news.povray.org

Post a reply to this message