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

On 2020-10-17 9:20 PM (-4), Kenneth wrote:
> 
> My understanding is that 6500K is the 'standard' color temperature for a
> monitor; take a look here...

My monitor is set to sRGB with a white point of D65 (6504 K), but I also 
have an app that lowers the color temperature to 3500 K at night.  Aside 
from the greens appearing more vivid and green shades less easy to tell 
apart, I barely notice the change; my eyes adjust, and my sleep is 
probably better for it.  Of course, if the app abruptly quits (like when 
I accidentally shut it off just now while checking the settings), the 
difference is shockingly.  It's like the whole computer turns bright blue!

Prior to my current computer, which has a backlit LCD with an sRGB 
preset, I had manually set the gamma curves using clipka's gamma 
checking scene and a few test patterns of my own as benchmarks.

> 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.

As I see it, assumed_gamma srgb is useful for updating legacy scenes 
that did not have an assumed_gamma, so they would run without warnings 
in POV-Ray 3.7, or at least render predictably in any POV-Ray version. 
(assumed_gamma has been available since 3.0, if not earlier, but 3.7 was 
the first version to fuss about it.)  With all the tweaks necessary to 
get the lighting right in the original scene, inserting assumed_gamma 1 
into a legacy scene and slapping srgb on all of the pigments is unlikely 
to end well.  Short of a rewrite of the entire scene (which some POVers 
have done), it's best to just make explicit in the code the sort of 
monitor it was developed under.

At least that's my take as someone who has used assumed_gamma 1 from the 
beginning.  Some POVers (I can name a couple) prefer an unrealistic 
gamma for artistic reasons.

But assumed_gamma 2.2 (or 1.8 or whatever) would be used for the same 
reasons.  I guess assumed_gamma srgb was added for the sake of ungamma'd 
scenes that were developed with an sRGB monitor.  Or maybe it's just for 
completeness.  I don't know.  Maybe Chris Cason knows?

Post a reply to this message

"hi,

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

you probably don't.  :-)  the monitor is years old and, by today's standards,
quite small (1280x1024).  (it's a 17" Hewlett Packard, model HP1702.  there's


and thanks for the Eizo link.  apparently, "movies" == 6500K.

> ... I wish I could be more helpful.

you were!  (as was Cousin Ricky's post)


regards, jr.

Post a reply to this message

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

> 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 hadn't ever really understood functions - I'm not sure why - probably some
frustrating syntactical thing - until I worked on my pattern value scenes and
jr's moving media.  W. Pokorny truly helped clarify what was going on, and from
time to time I just find the functions easier to implement than a macro.
You also can't make a pigment pattern with a macro - it _has_ to be done with a
function, so that the global <x,y,z> coordinates are what control the pattern
values.
"Each of the various pattern types available is in fact a mathematical function
that takes any x, y, z location and turns it into a number between 0.0 and 1.0
inclusive. That number is used to specify what mix of colors to use from the
color map."
http://wiki.povray.org/content/Reference:Color_Map
It's a giant headache, but I just keep practicing.  30 error messages later, I
come up with something that works...   :D


> 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:

We do a lot of speculating here, and what I've found is that (for me, anyway) a
diagram of what's happening really helps me follow the text.  Especially when
there's a way that works correctly and a way that doesn't.

The next step that really cements the concept in my head is to sit down and code
it out.  If I want to show how POV-Ray does something, then I should be able to
scribble out some SDL that actually does what I'm talking about.  Say, take some
sphere with a mid-range color and convert the colors to sRGB for comparison.
Then convert the colors back to RGB and make sure the spheres are exactly the
same color.  Compare any user-defined formulas to the internal conversion done
with the srgb keyword by listing the eval_pigment results of both spheres...

It's really only when I start doing the above that I really start to understand
the concepts, the limitations, and the problems.  And of course, there's some
unexpected bug that's been lurking in there...   ;)
It's really a slow and painful thing to do, but the parser is like the military
school, and I'm the remedial student.  And I just keep running the gauntlet
until I get it right, or at least I get something that runs with no errors.  ;)

So, my "coding skill" is really just the result of 8 years of parser (and
clipka) enforced aversion therapy.  :D

Maybe reading some of these discussions will help.

http://wiki.povray.org/content/User:Clipka/Gamma
http://www.povray.org/documentation/view/3.8.0/260/
http://wiki.povray.org/content/HowTo:Migrate_old_scenes_to_work_with_the_new_gamma_system
http://news.povray.org/581b1660%40news.povray.org

http://news.povray.org/povray.binaries.images/thread/%3C585abdb8%40news.povray.org%3E/

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
>
> I hadn't ever really understood functions - I'm not sure why - probably some
> frustrating syntactical thing - until I worked on my pattern value scenes and
> jr's moving media.  W. Pokorny truly helped clarify what was going on...

Yeah, functions are still somewhat of a mysterious 'black box' for me; I'm
probably where you were 8 years ago! But I try to s*l*o*w*l*y keep learning
(ouch).

> It's really a slow and painful thing to do, but the parser is like the military
> school, and I'm the remedial student.  And I just keep running the gauntlet
> until I get it right...

Ha, a perfect analogy. LOL!
>
> So, my "coding skill" is really just the result of 8 years of parser (and
> clipka) enforced aversion therapy.  :D

Funny!
>
> Maybe reading some of these discussions will help.
>

THANKS for the "gamma/Clipka" link-- I don't think I've ever seen that specific
explanation in the wiki(!)

Post a reply to this message