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

No worries.
Copy/paste error.
Just forgot to delete the "1.055 * " preceding the pow() formula.

I also think that 0.04045 should be replaced by the true value of
0.0031308 * 12.92 = 0.040449936



#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, pow ((C+0.055)/1.055, 2.4))
}

#declare SRGB_Decode = function (C) {
 select (C-0.040449936, C/12.92, 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'

On 2020-10-15 1:05 PM (-4), Kenneth wrote:
> "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

Indeed, the very reason I didn't chime in on this matter is that I 
sometimes get my directions mixed up on this, and didn't feel the 
confidence to take a hard look.  It can be brain busting.  Sometimes I 
get lazy (or frustrated) and just run a formula, and if the result turns 
out backwards, I know I need to use the other formula.

Post a reply to this message

Cousin Ricky <ric### [at] yahoocom> wrote:

> ...Sometimes I
> get lazy (or frustrated) and just run a formula, and if the result turns
> out backwards, I know I need to use the other formula.

Same here, ha. But this gamma business has *always* been a thorny subject to me,
and any chance to get a better understanding of it-- as painful as it can be--
is worth some turtured brain cells. Seems that it's a never-ending quest. And I
*still* have nagging questions about my analysis, which will hopefully become
clear with more thought.

Post a reply to this message

hi,

"Kenneth" <kdw### [at] gmailcom> wrote:
> ...
> 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.

monitors tend to have an OSD where colour "profiles" can be selected; eg I can
choose from 9300K, 6500K, custom, and srgb.  so should I (continue to) go with
'srgb' and use 'assumed_gamma 1' in all my scenes, or...?


regards, jr.

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> "Kenneth" <kdw### [at] gmailcom> wrote:
> > ...
> > 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.
>
> monitors tend to have an OSD where colour "profiles" can be selected; eg I can
> choose from 9300K, 6500K, custom, and srgb.  so should I (continue to) go with
> 'srgb' and use 'assumed_gamma 1' in all my scenes, or...?
>
>
I wish I had a monitor like yours, with more sophisticated controls; mine is
currently a cheap LED-backlit LCD 'TV'. It doesn't have choices like 6500K etc,
just the dumb 'consumer' choices like 'sports', 'movies', 'baseball'(!), etc.,
along with manual custom settings.  (I'm researching new monitors at the moment,
looking for something that has spot-on color accuracy re: sRGB. It's turning
into a lengthy search!)

My understanding is that 6500K is the 'standard' color temperature for a
monitor; take a look here...

https://www.eizo.com/library/basics/color_temperature_on_an_LCD_monitor/

I assumed color temperature was a different 'thing' than  'srgb'; it's a
surprise to me that your monitor gives you that particular choice, but I could
be wrong (or  ill-informed at present.) I wish I could be more helpful.

In POV-ray, I presently use assumed_gamma 1.0, the long-recommended value (along
with srgb colors rather than linear rgb.) But one of the new nagging questions
that I currently have is about the use of the newer assumed_gamma srgb, and what
effect *it* may have on a rendered scene. The documentation isn't clear as to
why it's an alternative. Since it is nearly a 2.2 gamma, it is bound to have a
rather profound effect, at least in the render preview. I've never used it
before, but I plan to run some tests.

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> No worries.
> Copy/paste error.
> Just forgot to delete the "1.055 * " preceding the pow() formula.
>
> I also think that 0.04045 should be replaced by the true value of
> 0.0031308 * 12.92 = 0.040449936
> [code...]

That is some ingenious coding! I haven't run your SDL code yet, but will do so
ASAP-- just to see the graphing results on MY computer screen ;-) Your coding
skills continue to amaze me.

I'm still assessing the 'totality' of how and what those Wikipedia equations +
POV-ray do as a combo, to get a nice and correct image file. It seems to me that
it follows these steps:

1) We work on a POV-ray scene in an assumed_gamma 1.0 'world', which is a linear
world (except for the use of more-pleasing srgb colors, which are NOT linear, at
least in the visual preview). Everything else in the scene is (or should be)
'linear'--lighting, radiosity effects, etc. (Well, as a simplification).

2) For the rendered output file, the scene is encoded as srgb (assuming that
POV-ray's File_Gamma is set that way.) This essentially 'brightens' the scene by
way of the *actual* RGB-to-SRGB formula, before sending it to the video
card/monitor. (My previous assessment, anyway.)

3) The 2.2-gamma monitor then 're-darkens' the scene, to be what we saw in
POV-ray's preview.

What that means (to my thinking) is that the saved image file's on-screen
appearance, as viewed on the 2.2-gamma monitor, is actually a 'linear image'
again, so to speak-- just like in POV-ray's preview-- the scene's lighting, etc,
etc. EXCEPT for the colors that we used, which were 'srgb darkened' when we
worked on the scene. (I know that when we use such colors, POV-ray actually
works with their 'linear' values internally-- so I guess that, for example, srgb
0.50 becomes 'linear 0.22' behind the scene; that's the only way it makes sense
to me, in order for the saved file to properly show 0.22 later.)

Some of this may be conjecture, of course. I know that Clipka spent a good deal
of time in the past, attempting to explain this pipeline and its many arcane
details. My explanations and understanding may differ from his; he knew a LOT
more about this stuff than I currently do.

Post a reply to this message