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

Cousin Ricky <ric### [at] yahoocom> wrote:
> On 2020-10-17 9:20 PM (-4), Kenneth wrote:
>
> > But one of [my] new nagging questions...is about the use of the newer
> > assumed_gamma srgb, and whateffect *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.
>
[Ricky wrote:]
> 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.
> ...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...

Yep, that was the conclusion I was coming to as well: using assumed_gamma srgb
along with linear RGB colors in the scene, as in the 'old days'-- to get the
previous image results we expected when some of us used assumed_gamma 2.2 then
(against the recommendation of assumed_gamma 1.0). Admittedly, I was one of
those folks :-O
Thanks for the concurring opinion; I see now that I don't necessarily need to
re-write some of my old and complex scenes, IF I want to reproduce them in
v3.7xx/3.xx *as they were* in the v3.6 days. But I also see that they DO need
updating for my current assumed_gamma 1.0 use (at least updated with sgrb
colors, if not lighting tweaks etc) if I want them to look as realistic as they
*should*.
>
> 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.

I agree. (I have no real clue or memory as to whether my old PC computers and
monitors worked in 'gamma 2.2' space as opposed to 'gamma srgb' space. That was
before I even understood what it was all about. I think is was just 'plain' 2.2
then, but who knows.)

Post a reply to this message

I just came across a discussion by Clipka (in answer to a question by Mike
Horwath in 2015) about LIGHT use in v3.7xx-3.8xx, when using assumed_gamma 1.0:
"Should we use rgb or srgb colors in light sources?"

http://news.povray.org/povray.binaries.images/attachment/%3Cweb.5dc98ba0982994b4e0c1802f0%40news.povray.org%3E/clipkas%
20gamma%20tutorial.pdf

It is definitely worth reading, as it covers other gamma-related color topics as
well.

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
> I just came across a discussion by Clipka (in answer to a question by Mike
> Horwath in 2015) about LIGHT use in v3.7xx-3.8xx, when using assumed_gamma 1.0:
> "Should we use rgb or srgb colors in light sources?"
>
>
http://news.povray.org/povray.binaries.images/attachment/%3Cweb.5dc98ba0982994b4e0c1802f0%40news.povray.org%3E/clipka
s%
> 20gamma%20tutorial.pdf
>
> It is definitely worth reading, as it covers other gamma-related color topics as
> well.

[Bald Eagle wrote earlier:]
> 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.

Here's a link from 2010(!) that Warp posted, which I think was the initial
'seed' for the Clipka/Horwath discussion-- although it was specifically about
color-map interpolation post-v3.6xx. I made few comments there as well, but
that was at a time when I was rather dogmatic about using assumed_gamma 2.2 in a
scene. Sorry! :-O

Between Clipka and Warp with their differing viewpoints, it was a battle of epic
proportions! ;-)

http://news.povray.org/povray.beta-test/thread/%3C4d0e666b@news.povray.org%3E/

Post a reply to this message

So, I'm tired, and my eyeballs hurt, so I sought out some
isobutylphenylpropionic acid and a gin & tonic.

Warp and clipka always went at it with gusto!   :D
We should email Warp and drag him back in....

I think, if we're going to play with these things, and be able to reliably and
usefully understand WTH is going on, then some sort of visual correspondence
roadmap ought to be made.

Consider:

A box has a pigment with 2 image_maps, blended in a pigment_map, illuminated by
a light source, rendered by POV-Ray, displayed on a monitor, and seen by you.

Each of those things has a gamma associated with it.

My idea is to start with a point on the light source graph, draw a line to the
object graph, then the monitor, then the observer.

I'm almost over here crying with laughter, because I can just hear my girlfriend
now:
"And this....   ***THIS*** is what you do ..... for "fun" ???!"

Let the games begin.

=================================================================

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.


The gradients are made with the following syntax:
Note the gray in the interpolation across the 0 saturation region.
This is what Jerome was pointing out in that thread.

 box {<0, 0, 0> <1, 0.25, 0.01>
  pigment {gradient x
   pigment_map {
    blend_gamma 1
    blend_mode 2
    [0 rgb <1, 0, 1>]
    [1 rgb <0, 1, 0>]
   }
  }
  scale <6.5, 1, 1>
 }

Post a reply to this message

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

Preview of image 'colorconversionformulas_fromsource.png'

"Bald Eagle" <cre### [at] netscapenet> wrote:
>
> I'm almost over here crying with laughter, because I can just hear my girlfriend
> now:
> "And this....   ***THIS*** is what you do ..... for "fun" ???!"
>
Ha! I know the feeling; *everything* takes a back seat when I'm hunkerd down
with POV-ray. As I keep explaining to friends, it's the only way to *learn*!
>

> 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.
>
That's...brilliant. As are your graphing results. Congrats on the hard work!

I've been re-reading that NVIDIA article that I mentioned; it has some really
astute observations to make. I'm paraphrasing quite a lot here, to try and make
it applicable to POV-ray; and I borrowed another illustration from there (posted
below):

"If the linear lighting values as seen in POV-ray's assumed_gamma 1.0
environment are properly encoded for the saved file, when you view the final
image file it should again look like a real object with those reflective
properties." In other words, by using the true RGB to SRGB conversion formula to
'encode'  the file to preliminarily 'brighten' the image even more, before
sending it to the 'reverse' 2.2-gamma monitor, the end result will be linear
lighting again. Absolute realism (but only as good as it can be, of course, when
perceived on a typical non-HDR monitor.)
As in Image A, with its sharp shadow-terminator line.

"But if you were to display the assumed_gamma 1.0 image file on a gamma 2.2
monitor *without* pre-encoding the file with the formula,  the image will
actually look darker." Or rather, with incorrect gamma interpretation.
As in Image B.
(And as *I* used to do in a different way in v3.6xx days-- using 'plain' RGB
colors and assumed_gamma 2.2; essentially the same result.)

"With more 'advanced' lighting techniques that you use (such as HDR, global
illumination of any kind, and subsurface scattering), the more critical it will
become to stick to a linear color space to match the linear calculations of your
sophisticated lighting."

Apparently, Image A *is* how we see things in the real world, with our eyes.
Which is of course combined with real-world 'radiosity' and fill light, so we
probably don't perceive things *exactly* that way, but close to it. Whereas,
Image B is what many of us *think* we should see-- probably based on how photos
and films of the real world look, at least with older film technology. I think
that was part of Warp's fundamental argument with Clipka, back in 2010 (and my
own argument then too.)

But digressing a bit, and getting back to fundamentals:
It seems to me that there are two 'schools of thought' when rendering in
POV-ray: the *absolute lighting realism* of the assumed_gamma 1.0 way-- Image
A-- and the 'photographically pleasing or expected' look of the assumed_gamma
2.2 (or gamma srgb) way, Image B...even with its 'incorrect' lighting
computations and gamma. (Incorrect as to absolute realism.) Such images
generally have higher contrast and richer colors. Did old photos and films
reproduce absolute 'linear light' realism? No. But they looked nice anyway. ;-)
I wouldn't call this an artistic choice; it's more of a visual expectation.

Personally, I'm *still* straddling the fence as to which scheme I personally
like, visually speaking; but I'll stick to assumed_gamma 1.0 and
'realistic/correct' lighting for now.

Btw, this is interesting:
In professional CGI environments, artists apparently work in a 'complete' and
rather austere  assumed_gamma 1.0 world-- even when using image_maps and the
like:
"Any input textures that are already gamma-corrected [like JPEGs] need to be
brought back to a linear color space before they can be used for shading or
compositing. Ordinary JPEG files viewed with Web browsers and the like will look
washed out. Film studios don't care if random images on the Internet look wrong



Wow.

Post a reply to this message

Attachments:
Download 'gamma_moon_images.jpg' (18 KB)

Preview of image 'gamma_moon_images.jpg'

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

> Btw, this is interesting:
> In professional CGI environments, artists apparently work in a 'complete' and
> rather austere  assumed_gamma 1.0 world-- even when using image_maps and the
> like:

Yes, and that's the gist of what I'm trying to figure out.
Because with multiple encodings and decodings, it's next to impossible to figure
out where some fundamental thing went wrong or how to fix it.   Therefore you're
forever doing all of that artistic fiddling.

If you get a chance, you should check out Ansel Adams' 3-part series on The
Print, The Negative, and The Camera.  Or just look up a good explanation of the
zone system.  It uses film gamma as an explanation, but it's where I started.


I also forgot to throw assumed_gamma into the mix.

So there are all of those things playing off one another, and they all add up to
a result.  The idea is to 1:1 graph it, or come up with some sort of test suite
that allows one to use an image or pattern and unambiguously verify if what one
is using is in linear color space.   Then if the monitor converts it to sRGB to
display it, who cares - that's the expected end result anyway.

But we should be careful to not "double-convert" one way or the other.

Post a reply to this message