"Kenneth" <kdw### [at] gmailcom> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> > Hi Kenneth - this is something that I was concerned about, tried to
> > address, and IIRC, did it backwards.
> >
>
> 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...
>
Well, I never like to base my ideas on a single source of information, so I
looked at other web sources that have these 'color conversion' equations-- and
ALL the sources I've seen match the order of the equations in Wikipedia.  So I'm
obviously wrong about the two equations being 'backward' there. I gave this a
lot of thought, and realized that it's our *use* of those equations **in
POV-ray** that makes them seem so. To really explain why would take paragraphs,
and I'm still wrapping my brain around it. And I might put Ash to sleep... :-P

But the re-edited macros are still correct for their use in POV-ray... a
consequence of this 'new thinking'.

This NVIDIA article really opened my eyes to the correct way of visualizing the
situation, although it may not be immediately obvious...

https://developer.nvidia.com/gpugems/gpugems3/part-iv-image-effects/chapter-24-importance-being-linear

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

The Wikipedia page about "sRGB" has two nasty-looking math equations for
converting 'linear' RGB colors (like in colors.inc) into SRGB colors, and vice
versa. But Bald Eagle and I thought that the equations were 'reversed' there--
because the math *results* of each equation had the opposite effect of what we
wanted them to do in POV-ray. But the equations ARE correct-- it's just that
their intended use *in POV-ray* was the opposite of what the wiki article is
actually describing. That's hard to explain without a lengthy essay on the
subject ;-)

Post a reply to this message

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

> But the equations ARE correct-- it's just that
> their intended use *in POV-ray* was the opposite of what the wiki article is
> actually describing. That's hard to explain without a lengthy essay on the
> subject ;-)

The POV-Ray Essay Commission will now come to order.
{reverberating gavel sound, muffled coughing and shuffling}

Kenneth Walker has been nominated to author The Essay on sRGB conversion
formulas.

Do I hear a second?
"Second!"

All those in favor of Kenneth writing a lengthy essay say Aye...
"Aye!"     "Aye!"     "Aye!"     "Aye!"     "Aye!"     "Aye!"     "Aye!"

The Aye's have it.

Kenneth Walker is now appointed as the Maintainer of the Gamma, and The
Commission anxiously awaits his proffered essay....

:P

Post a reply to this message

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

>
> Kenneth Walker is now appointed as the Maintainer of the Gamma, and The
> Commission anxiously awaits his proffered essay....
>
> :P

Hmm, a dubious distinction :-0

OK, you asked for it. But gamma is such a tricky and complex subject that I may
come across as either sounding like a genius, or sounding  like an idiot. :P
There are aspects of this business that still puzzle me, and I have left out a
lot of extraneous details; but this is how I see it so far. (And this is the
SHORT-version, ha.) I await judgement ;-)

I'll concentrate on the RGB-to-SRGB conversion formula. I 'borrowed' a diagram
from the NVIDIA article and posted it here, to help explain things (it should be
on the Wikipedia page too, which would go a long way to explain the actual
intended use of the equations there.)

In a nutshell:

Our computers/monitors have an intrinsic built-in  'gamma' of generally around
2.2. That computer gamma is the curved "CRT gamma line" in the diagram. The
straight line represents color values fed to the display.

When we save an image in POV-ray (i.e., the rendered image), it contains
*linear* image data, but with a gamma chunk to tell the computer what to do with
it-- either 2.2 (automatic for older versions) or, for v3.7xx-3.8xx, either 2.2
or srgb by way of the newer File_Gamma keyword in our .ini file.  (These gamma
chunks are possibly the 'inverse' of the values, but that's too much technical
detail for this discussion.)

The RGB-to-SRGB conversion equation as-is on the Wikipedia page (and elsewhere)
refers to this image-ENCODING gamma-- the gamma chunk-- when an image is finally
sent to the computer/monitor for display. The surprise (as regards POV-ray's use
of the SRGB keyword for colors) is that the equation actually 'brightens'  the
image values, to prepare them for the counter- 'gamma-bending' by the computer's
intrinsic 2.2 gamma-- so that their final perceptual appearance is once again
along  the straight line. These gamma-encoded values are represented by the
dashed line in the diagram.

This is what the equation itself is meant to do-- it's for gamma-ENCODING an
image.  But that's the *opposite* of what we want it to do **within POV-ray**;
we want to take a too-bright linear RGB color there -- say, 50% gray, which
*appears* too bright in our assumed_gamma 1.0 world-- and *darken* it to look
perceptually correct in our preview render.

So, the 'opposite' SRGB-to-RGB equation on the page is the one to use, even
though that seems counter-intuitive.

Using POV-ray's assumed_gamma 1.0 in a scene is like having a self-contained
'box' in the computer with its own 'linear gamma atmosphere' of 1.0, sealed off
from the computer's gamma 2.2  environment. We work within that box, visually
and computationally.  Now, because *linear* RGB color values in such an
environment look kind of washed-out to our own eyes, we need a way within
POV-ray to mimic the surrounding gamma-2.2 world-- not by using assumed_gamma
2.2 there (for subtle computational reasons), but with SRGB colors. Of course,
you *could* use linear colors along with assumed_gamma 1.0, and simply tweak the
visual results to your liking in the preview-- using 22% gray instead of 50% so
that it 'looks' correct as middle-gray-- but most if not all other image-making
programs don't operate in a gamma 1.0 environment like that; we are simply used
to the visual preview results of, say, 50% linear gray automatically looking
like 22%. Working with colors is just easier this way-- we can specify srgb and
'get' 22%, which is perceptually midway between black and white.

For older versions of POV-ray without the srgb color keyword, setting
assumed_gamma to 2.2 was an expedient way around this, but with its own mess of
subtle problems as to internal computations.

Post a reply to this message

Attachments:
Download 'gamma_slopes_image.jpg' (56 KB)

Preview of image 'gamma_slopes_image.jpg'

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

> Hmm, a dubious distinction :-0
>
> OK, you asked for it. But gamma is such a tricky and complex subject that I may
> come across as either sounding like a genius, or sounding  like an idiot.

I think gamma is one of things that _seems_ complex simply because there's no
visual and interactive roadmap.

I've had to memorize things, and use or teach subjects that people's popular
perception is that they are "lofty" or "complicated" - yet these same people
know THOUSANDS of song lyrics, driving directions, and play very layered,
conditional video and other games all the time.

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.

and if everything were expressed as function{}s, then it would be easy to have a
macro that creates a graph like you attached.

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.

Because we've all been around the block enough times to _know_ that this kind of
thing is going to crop up again and again and again.

I think you invested a few well-spent hours familiarizing yourself with the
topic, and now it's time to "write it down" in a way that exactly matches how
POV-Ray handles the conversion, and is accessible in a way that users don't have
to reinvent the wheel in order to ascend that learning curve.

I have the POV-planet project, the Bezier stuff, the quilted pattern all
swirling around - but I can help out with getting the function {} structure and
syntax right, and maybe dig up POV-Ray's source code to see exactly what's going
on there.

Good work, Sir.
It's a pleasure to have you back   :)

Post a reply to this message

It seems to me that the color conversion code is in
source/base/image/colourspace.cpp

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> It seems to me that the color conversion code is in
> source/base/image/colourspace.cpp

This is what was in the source code, which seems to be exactly what you have.
Maybe it has something to do with the way POV-Ray does math through SDL vs
through compiled code (float vs double, etc)

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

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

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> > It seems to me that the color conversion code is in
> > source/base/image/colourspace.cpp
>
> This is what was in the source code, which seems to be exactly what you have.
> Maybe it has something to do with the way POV-Ray does math through SDL vs
> through compiled code (float vs double, etc)
>
> #declare SRGB_Encode = function (C) {
>  select (0.0031308-C, C*12.92, C*12.92, 1.055 * pow (C, 1/2.4) - 0.055)
> }
>
> #declare SRGB_Decode = function (C) {
>  select (0.04045-C, C/12.92, 1.055 * pow ((C+0.055)/1.055, 2.4))

Now, hearkening back to clipka's point,
http://news.povray.org/povray.advanced-users/message/%3C58cb2917%241%40news.povray.org%3E/#%3C58cb2917%241%40news.povra
y.org%3E

All we would need to do is include a multiplier m as a second argument, and
multiply the result by that.

The other issue that was brought up (somewhere, by someone) is trying to use
sRGB values in a color map - because the color_map will interpolate linearly,
whereas the sRGB color space is nonlinear.

I have no idea if we have control over color_map interpolation - a user_function
would be useful....  I have a real problem trying to search and find these
things....

Post a reply to this message

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

> The other issue that was brought up (somewhere, by someone) is trying to use
> sRGB values in a color map - because the color_map will interpolate linearly,
> whereas the sRGB color space is nonlinear.
>
> I have no idea if we have control over color_map interpolation - a user_function
> would be useful....  I have a real problem trying to search and find these
> things....

New in version 3.8 non-linear pigment map interpolation support has been added.
http://wiki.povray.org/content/Reference:Pigment_Map

So, I guess all of the components exist to write some demo scenes to illustrate
how gamma and rgb/srgb work, and how to best use them in scenes with things like
pigment maps...

It seems to me that we have a lot of things like maps and pigment patterns, and
a lot of things like splines and functions, and there should be some way to
cross reference them with each other to take advantage of existing code.

At some point I'll have to start trying to map this out somehow.

Post a reply to this message

OK, so I'm going to get some shut-eye, but figured I'd post this WIP.

Looks like I reversed the select() conditions, so I corrected that, and graphed
linear and both formulas.
The green one looks off.   No idea why right now.   Maybe someone has insights.

Source code follows SDL.


#version 3.8;
global_settings {assumed_gamma 1.0 }


camera {
 location <1/2, 0.5, -1.5>
 //location <0, 10, 3>
 right x*image_width/image_height
 up y
 look_at <1/2, 0.5, 0>
}

light_source {<0, 0, -5> rgb 1} // for documentation illustrations
sky_sphere {pigment {rgb 1}}


// Functions modeled directly from POV-Ray source code
// Bill Walker "Bald Eagle" October 2020

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

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


#declare Line = 0.005;
union {
 cylinder {<0, 0, 0>, <0, 1, 0> Line}
 cylinder {<1, 0, 0>, <1, 1, 0> Line}
 cylinder {<0, 1, 0>, <1, 1, 0> Line}
 cylinder {<0, 0, 0>, <1, 0, 0> Line}
 no_shadow
 pigment {rgb 0}
}

cylinder {<0, 0, 0>, <1, 1, 0> Line pigment {rgb <0.5, 0, 0>}}

union {
 #for (X, 0, 1, 0.01)
  #local Current = <X, SRGB_Encode (X), 0>;
  sphere {Current Line}
  #if (X > 0)
   cylinder {Current, Last Line}
  #end
  #local Last = Current;
 #end
 texture {pigment {rgb <0, 0, 0.5>}}
}

union {
 #for (X, 0, 1, 0.01)
  #local Current = <X, SRGB_Decode (X), 0>;
  sphere {Current Line}
  #if (X > 0)
   cylinder {Current, Last Line}
  #end
  #local Last = Current;
 #end
 texture {pigment {rgb <0, 0.5, 0>}}
}

/*******************************************************************************

SRGBGammaCurve::SRGBGammaCurve() {}
SimpleGammaCurvePtr SRGBGammaCurve::Get()
{
    if (!instance)
        instance.reset(new SRGBGammaCurve());
    return SimpleGammaCurvePtr(instance);
}
float SRGBGammaCurve::Encode(float x) const
{
    // (the threshold of 0.00304 occasionally found on the net was from an older
draft)
    if (x <= 0.0031308f) return x * 12.92f;
    else                 return 1.055f * pow(x, 1.0f/2.4f) - 0.055f;
}
float SRGBGammaCurve::Decode(float x) const
{
    // (the threshold of 0.03928 occasionally found on the net was from an older
draft)
    if (x < 0.04045f) return x / 12.92f;
    else              return pow((x + 0.055f) / 1.055f, 2.4f);
}
float SRGBGammaCurve::ApproximateDecodingGamma() const
{
    return 2.2f;
}
int SRGBGammaCurve::GetTypeId() const
{
    return kPOVList_GammaType_SRGB;
}

*******************************************************************************/

Post a reply to this message

Attachments:
Download 'colorconversionformulas_fromsource.png' (39 KB)

Preview of image 'colorconversionformulas_fromsource.png'