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
also a 19" version (HP1902).  saw a 2nd hand for £20 the other day)

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
on an artist's workstation, as long as their actual work product—the film
itself—looks perfect in the theatre."

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

Le 2020-10-20 à 11:01, Kenneth a écrit :

> 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.)
> 
When looking at the Moon, what I see is more like A, but with the dark 
part similar to B.
When the object is MUCH closer, like a close by concrete ball, then, 
it's A all the way.

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> 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.
> ...

I'm afraid that we also need to take into account any changes made by the driver
for the graphic card, the driver for the monitor and perhaps the operating
system.

--
Tor Olav
http://subcube.com
https://github.com/t-o-k

Post a reply to this message

On 2020-10-20 2:32 PM (-4), Alain Martel wrote:
>>
> When looking at the Moon, what I see is more like A, but with the dark 
> part similar to B.
> When the object is MUCH closer, like a close by concrete ball, then, 
> it's A all the way.

That's because there is very little back lighting in outer space, unless 
the Moon is in a crescent phase.

Post a reply to this message

"Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmailcom> wrote:
[Bald Eagle wrote:}
> >
> > 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.
> > ...
>
> I'm afraid that we also need to take into account any changes made by the driver
> for the graphic card, the driver for the monitor and perhaps the operating
> system.
>
Yes-- and I am currently grappling with such changes, on my Win 7 computer
(built-in video card) and my cheap-o 'TV monitor': basically, increased
orange/yellow color-intensity in any 'saved' image file, from any source. And
slightly darkened image files from POV-ray. It is either due to the monitor
itself, or I am using the wrong ICC profile in the computer (currently sRGB,
which I thought would be correct.) In any case, the only *reliable* viewing
environments that I completely trust are 1) the POV-ray preview window, and 2)
Ive's IC/Lilysoft image-viewing app. Everything else is skewed.

A new *real* computer monitor would certainly help...unless the problem is
somewhere in the computer itself.

I miss my old and trustworthy CRT monitor.

Post a reply to this message

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

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

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

I took your advice-- I'm currently working on a complex text scene, taking into
account assumed_gamma, and rgb/srgb colors for both objects AND light sources--
because I personally want to form an opinion about whether or not to use srgb
colors for lights as well, simply to get the color I 'visually' expect as
opposed to 'linear' rgb colors that are intrinsically washed-out in an
assumed_gamma 1.0 environment. I know that Clipka recommended we stick with
'rgb' there, but my test scene will compare the difference.

And I plan to use your excellent conversion functions; it looks like you figured
out how to 'correctly' multiply srgb colors with an M, which is a more complex
situation than multiplying simple rgb colors. Your coding skills are more
sophisticated than mine, so I'll take your word for it ;-)

Can I assume that, if I choose *not* to use the M-multiplier in your functions
(for my simpler test scene), I could just change the function like so? and with
C being a typical 3-part color vector like <.3,.6,.9>)?:

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

The reason being, that I might restrict any color values to between 0.0 and 1.0,
for a better 'basic' test of things. (Although, I might change my mind.)

When my test scene is complete and working properly, I'll post it elsewhere.

Post a reply to this message

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

> I took your advice-- I'm currently working on a complex text scene, taking into
> account assumed_gamma, and rgb/srgb colors for both objects AND light sources--
> because I personally want to form an opinion about whether or not to use srgb
> colors for lights as well, simply to get the color I 'visually' expect as
> opposed to 'linear' rgb colors that are intrinsically washed-out in an
> assumed_gamma 1.0 environment. I know that Clipka recommended we stick with
> 'rgb' there, but my test scene will compare the difference.

Yes, the washed-out thing is very off-putting.
In situations where there is no readily-available and easily-understood
documentation that adequately explains how all of the pieces influence the final
result, I think it's just as important to understand what _doesn't_ work (and
why ) as it is to be aware of what does work.

In the absence of any "proper" way to achieve an end result, the Warp et al
approach of using assumed_gamma 2.2 is both understandable and unavoidable.
However, if there _exists_ a "proper" method by which to achieve the exact same
results, then it's important to people who spend a lot of time using the system
to be proficient with that, even though there may be specific instances where
they purposefully don't.  (In this instance, using the "proper" gamma for all of
the reasons that clipka outlined involving lighting, monitors, highlights and
shadows, etc.)


> Can I assume that, if I choose *not* to use the M-multiplier in your functions
> (for my simpler test scene), I could just change the function like so? and with
> C being a typical 3-part color vector like <.3,.6,.9>)?:




A multiplier of 1 is ... no multiplier at all.   ;)

Post a reply to this message

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

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

[off-topic, sort of...]
Here's some food for thought, which just occured to me-- not about your
functions, but about the conversion formulae themselves (Wikipedia and
elsewhere):

The conversion formulae use a "2.4 gamma" in the computations-- whereas, in
POV-ray, and running antialiasing in a scene, Clipka chose a "2.5 gamma" for the
antialiasing gamma (this in v3.8xx). Maybe I'm cluelessly 'comparing apples to
oranges', but I wonder why Clipka didn't choose "2.4 gamma" instead? I suppose
there *is* a reason, but... :-O

Just something to keep you and me up at nights, wondering about the
difference... ;-)

Post a reply to this message

Am 10/18/2020 um 23:22 schrieb Bald Eagle:
> 
> 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
 >


Nope. Both functions are wrong far all M <> 1.0!

If you do not already see this by looking at the formulas just check it: 
Use SRGB_Encode for any value of C and then the result for SRGB_Decode. 
This should give the original value of C.


The correct functions would be

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

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


It worries me for this NG that stuff like this stays uncorrected for 
over 10 days.

-Ive

Post a reply to this message

Ive <ive### [at] lilysoftorg> wrote:

>
> The correct functions would be
>
> #declare SRGB_Encode = function (C, M) {
>   select (C*M-0.0031308, C*12.92*M, C*12.92*M, (1.055 * pow (C*M, 1/2.4)
> - 0.055))
> }
>
> #declare SRGB_Decode = function (C, M) {
>   select (C-0.040449936, C/12.92, pow ((C+0.055)/1.055, 2.4))*M
> }
>
> It worries me for this NG that stuff like this stays uncorrected for
> over 10 days.
>

Well, see? It did get corrected :-) (Not that I would know which is which,
mathematically speaking; functions are sometimes a 'black box' to me.) I like to
think that the newsgroups are *eventually* self-correcting, like after-the-fact
letters to a scientific publication.

I hate to admit that I have not yet tried Bald Eagle's functions; perhaps a
purely visual test would have shown that something might be amiss. [Sorry, B.E.,
I've been busy with other coding.]

He did say, ..."Perhaps it's not "right", but it's the way I envisioned its
usage."

In any case, thanks for the update.

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
> Ive <ive### [at] lilysoftorg> wrote:
>
> >
> > The correct functions would be
> > [snip]

Just to clarify, in my own mind, some things about the use of these functions
(because I'm currently working on an all-inclusive test scene about this stuff):

When using assumed_gamma 1.0, and in POV-ray's preview render:

If I want to *multiply* an RGB color,  rgb 0.7*<.3,.5,.7> would be OK to do.

But if I want to multiply an SRGB color,  srgb 0.7*<.3,.5,.7> would NOT be the
correct way to do it, to get the 'expected' color result (if I understand some
of Clipka's older remarks); I would instead need to use a somewhat different
multiplication scheme. Is that what these 'multiplication functions' are for--
the way to properly 'multiply' an SRGB color?

Or is   srgb 0.7*<.3,.5,.7>  perfectly OK by itself?

Or am I way off base as to what the functions themselves are meant for?

Post a reply to this message

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

> > > The correct functions would be
> > > [snip]

I don't have my initial experiments on hand, and I may have coded something
equivalent, but I will have to graph what you have to see for sure.

> If I want to *multiply* an RGB color,  rgb 0.7*<.3,.5,.7> would be OK to do.

Yes.  I do this all the time, and is what clipka mentioned was fine.

> But if I want to multiply an SRGB color,  srgb 0.7*<.3,.5,.7> would NOT be the
> correct way to do it,

Right, which is what he was telling me at the time.

> to get the 'expected' color result (if I understand some
> of Clipka's older remarks); I would instead need to use a somewhat different
> multiplication scheme. Is that what these 'multiplication functions' are for--
> the way to properly 'multiply' an SRGB color?

Well, let's say that's the _goal_.  My functions are wrong, I'm assuming I've's
are correct.
I _should_ have done what I normally do to self-check, which is convert an rgb
color to srgb, and then use the srgb to rgb conversion to convert it back, and
get the original value.

> Or is   srgb 0.7*<.3,.5,.7>  perfectly OK by itself?

it is not.  When you invoke the srgb keyword, it "moves" you from a linear
interpolation to a non-linear interpolation.  And you have to "do the
multiplication" _inside_ of that nonlinear "space".  I guess maybe you can see
it as moving by a factor M along the curve, rather than along the line.

> Or am I way off base as to what the functions themselves are meant for?

I think you get the general gist of it, if not the explicit details.
I can't remember what time I worked this out - but It may have been a bit late
and it seemed to be what I was shooting for rather than the technically correct
rgb to srgb conversion and multiplication.   But I probably should have stated
that AND provided a proper way for comparison as well.



And to be fair - we've had formula errors lurking in the source for ~25 years
without anyone noticing.... so...

;)


Thanks, Ive, for catching this and pointing it out.
I'll have to go back to it again and not be so lax in double-triple checking,
back-checking, and graphing the results.

I of course would love to hear any commentary you might have on mapping the
lighting and image and pigment curves to each other....

Post a reply to this message

Am 10/28/2020 um 2:03 schrieb Kenneth:
> 
> When using assumed_gamma 1.0, and in POV-ray's preview render:
> 

When using anything but assumed_gamma 1.0 it makes no sense to use the 
srgb keyword anyway.

> If I want to *multiply* an RGB color,  rgb 0.7*<.3,.5,.7> would be OK to do.
> 
Sure.

> But if I want to multiply an SRGB color,  srgb 0.7*<.3,.5,.7> would NOT be the
> correct way to do it, to get the 'expected' color result (if I understand some
> of Clipka's older remarks); I would instead need to use a somewhat different
> multiplication scheme. Is that what these 'multiplication functions' are for--
> the way to properly 'multiply' an SRGB color?
> 
> Or is   srgb 0.7*<.3,.5,.7>  perfectly OK by itself?
> 
No it isn't. When using the keyword "srgb" you just tell POV-Ray that 
the following color term is "sRGB gamma encoded".
Multiplying any non linear color value does not only change the 
brightness but also the hue - and is therefor plain wrong.

I haven't used POV-Ray in years and never used the srgb keyword in my 
whole live (I switched to Adobe RGB a long time ago) so I'm not sure if 
it will swallow this syntax but at least you should get the idea...

#declare C = (srgb <.3,.5,.7>) * 0.7;

> Or am I way off base as to what the functions themselves are meant for?
> 

Yes, I guess this is what BE meant it for even if he called it 
"tone-adjusting" while in fact it is a brightness or intensity adjusting.



...and BTW I just stumbeled over your bold statement

[quote]
simply to get the color I 'visually' expect as
opposed to 'linear' rgb colors that are intrinsically washed-out in an
assumed_gamma 1.0 environment.
[/quote]

I used from the very start (more then 2 decades ago, I guess 3.0 at the 
time) assumed_gamma 1.0 (I already had some experience in the field of 
image processing) and no image I ever created suffered from a washed-out 
look. Some early images of mine did look ugly because my own bad choice 
of colors or bad arrangement of objects but these are no gamma related 
problems ;)


BTW during the early phase of POV-Ray 3.7 alpha development I had this
on my webpage:

https://www.lilysoft.org/Stuff/gamma.html

thankfully Christoph did make all the described workarounds obsolete as 
he improved the image file handling and also implemented an image file 
related gamma keyword as I did suggest there, so after the 3.7 release I 
removed any direct link from my side.

And BTW-2 your cityscape looks phantastic and things like this are still 
the strength of POV-Ray even when it has sadly fallen far behind as a 
render engine.


-Ive

Post a reply to this message

Am 10/28/2020 um 2:43 schrieb Bald Eagle:
> 
> And to be fair - we've had formula errors lurking in the source for ~25 years
> without anyone noticing.... so...
> 
> ;)
> 

I hope you did not get me wrong. I was not criticizing you - having been 
a programmer once I know very well how easily it happens, but I think in 
former times, mistakes here were quickly spotted. But maybe I'm just 
idealizing the past, like old men often do...

To me it was obvious by just looking at the formula that the linear part 
of the function is no longer the tangent to the exponential part for any 
M <> 1. This did surprise me because you already did switch away from 
the official sRGB gamma correction formula that also has a very small 
gap and makes no perfect tangent. Something that did annoy me since the 
very first draft for sRGB by HP and Microsoft.

> 
> Thanks, Ive, for catching this and pointing it out.
> I'll have to go back to it again and not be so lax in double-triple checking,
> back-checking, and graphing the results.

No problem, take your time.

> 
> I of course would love to hear any commentary you might have on mapping the
> lighting and image and pigment curves to each other....
> 

Well, now I have read through the whole thread. What a mess. There are 
so many false statements, combined with completely correct statements 
and - as usually - the worst ones: almost true statements.
And then are the things that are simply not relevant anymore (like the 
whole discussion with Warp - Clipka expanded the color_map syntax so 
that none of the complains is still valid).
So frankly, looking back at the whole thread, I really don't know where 
to begin. But if you have any concrete questions, just ask away...

-Ive


-

Post a reply to this message

Op 28/10/2020 om 05:03 schreef Ive:
> Am 10/28/2020 um 2:03 schrieb Kenneth:
>>
>> Or is   srgb 0.7*<.3,.5,.7>  perfectly OK by itself?
>>
> No it isn't. When using the keyword "srgb" you just tell POV-Ray that 
> the following color term is "sRGB gamma encoded".
> Multiplying any non linear color value does not only change the 
> brightness but also the hue - and is therefor plain wrong.
> 
> I haven't used POV-Ray in years and never used the srgb keyword in my 
> whole live (I switched to Adobe RGB a long time ago) so I'm not sure if 
> it will swallow this syntax but at least you should get the idea...
> 
> #declare C = (srgb <.3,.5,.7>) * 0.7;
> 

Maybe you remember the Bald Eagle / Clipka discussion in 
http://news.povray.org/povray.advanced-users/thread/%3C57894ece%241%40news.povray.org%3E/

I digested that at the time in the attached macro. I think (?) this is 
(part of) this answer...


-- 
Thomas

Post a reply to this message

Attachments:
Download 'utf-8' (8 KB)

Am 10/28/2020 um 8:54 schrieb Thomas de Groot:
> 
> Maybe you remember the Bald Eagle / Clipka discussion in 
>
http://news.povray.org/povray.advanced-users/thread/%3C57894ece%241%40news.povray.org%3E/

> 
I admire your memory. Especially not just remembering it - but also *where*.

But no I don't think I did read this thread, otherwise I would have been 
tempted to remark that my silly demo scene "cyndi cubes" demonstrates 
the usage of the macros from my file CIE_tools (both part of the 
Lightsys package) and these would be much more powerful (e.g. would also
be able to compensate for whitepoint errors) than Clipka's suggestions.

Which reminds me, these files were written back in 2003, long before 
Christoph even joint the POV-Ray community and meanwhile he already left 
- people come and go and doesn't time fly by?

-Ive

Post a reply to this message

Ive <ive### [at] lilysoftorg> wrote:

> I hope you did not get me wrong. I was not criticizing you - having been
> a programmer once I know very well how easily it happens, but I think in
> former times, mistakes here were quickly spotted. But maybe I'm just
> idealizing the past, like old men often do...

Nope - it's a simple matter of traffic x expertise.
Traffic here is down, and some of us are not yet at the expertise level in some
of the fields where we can just glance at something and the errors and
misconceptions are painfully obvious.
But some of us old men are stubborn, as we often are, and just keep on throwing
ourselves at that learning curve.   :)

> To me it was obvious by just looking at the formula that the linear part
> of the function is no longer the tangent to the exponential part for any
> M <> 1. This did surprise me because you already did switch away from
> the official sRGB gamma correction formula that also has a very small
> gap and makes no perfect tangent. Something that did annoy me since the
> very first draft for sRGB by HP and Microsoft.

Excellent.  A recondite man of great experience.
(You should drop in more often to watch the sht show  ;) )

The intense friction between the theoreticians and empirical experimentalists
and engineers is likely to be eternal  ;)


> Well, now I have read through the whole thread. What a mess. There are
> so many false statements, combined with completely correct statements
> and - as usually - the worst ones: almost true statements.

Oh yes - those are especially naughty.
If you ever wonder why the world we live in is the way it is....


> But if you have any concrete questions, just ask away...

I'll try, but I might just be providing examples of my present level of
[mis]understanding.
(And I'm ok with spreadsheets or graphs or papers to set me on the right path.)

Hmmm.
Conversion formulas aside, what at any given moment are we working with?

When everything is expressed in pigment {rgb <r, g, b,>} at assumed_gammma 1.0,
everything seems pretty straightforward.

But let's say someone borrows a nice texture that has srgb keywords sprinkled
throughout its declaration.  The color that pigment color values that get
"exposed" to the other elements in the scene are still just - rgb, correct?

Two things which seem pretty unclear are the effect of assumed_gamma srgb,
and/or a light source defined as srgb.  I can conceive the light source as just
being the rgb end result of the srgb conversion formula, like the texture
example, but just checking.
But assumed gamma must affect the whole scene - presumably by doing all of the
color calculations in "srgb color space".  Which with my present understanding,
and peeks into the source code, lead me to speculate that multiplying a pigment
color by a light source color gets a whole lot more complicated.

And reflections.   Metallic reflections.

Does one use srgb for all colors in assumed_gamma srgb scenes or rgb?

What's the proper way to instantiate image_maps that may be encoded by libraries
with in-built gamma handling precorrections?

I guess the concern here with many of my examples / implied questions is the
user trying to do something with srgb, and the software then doing a second
conversion - or the user NOT doing a conversion where needed and winding up not
using the color values needed for consistency with the rest of the scene, or
something getting corrected by the software in the opposite direction because a
user wasn't aware of a required precorrection.

If ANY of that makes any sense.

Post a reply to this message

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

>
> Does one use srgb for all colors in assumed_gamma srgb scenes or rgb?
>

Ah! That's *one* thing that I can answer, from my test scene so far: With
assumed_gamma srgb, the color types don't matter. Both rgb and srgb produce the
exact same result-- srgb colors. Exactly exact, not like srgb colors in
2.2-gamma space, with that *slight* difference we saw. I think Cousin Ricky(?)
or JR (?)mentioned it previously, somewhere in this messy thread, which I didn't
'process' at the time.  ;-)

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> ...Exactly exact, not like srgb colors in
> 2.2-gamma space, with that *slight* difference we saw.

Oops, I meant "not like RGB colors in the 'old' 2.2-gamma space..."

But using assumed_gamma srgb is kind of like a more exacting way to get the
old-style assumed_gamma 2.2 look like some of us used to use (and which was
incorrect at the time). Because the effects of *lighting* also change, across
the board. The lighting is no longer 'linear' in the render... which is what
assumed_gamma 1.0 is all about.

Post a reply to this message

Ive <ive### [at] lilysoftorg> wrote:
> Am 10/28/2020 um 2:03 schrieb Kenneth:
> >
> > Or is   srgb 0.7*<.3,.5,.7>  perfectly OK by itself?
> >
> No it isn't. When using the keyword "srgb" you just tell POV-Ray that
> the following color term is "sRGB gamma encoded".
> Multiplying any non linear color value does not only change the
> brightness but also the hue - and is therefor plain wrong.
>
> ...I'm not sure if
> it will swallow this syntax but at least you should get the idea...
>
> #declare C = (srgb <.3,.5,.7>) * 0.7;

Yes, that's very similar to my rather fuzzy understanding of one of Clipka's
older discussions. I should try that (or similar syntax), and compare it to the
function's use.

Thanks to both you and Bald Eagle for clarifying things. Much appreciated.
>
> ...and BTW I just stumbeled over your bold statement
>
> [quote]
> simply to get the color I 'visually' expect as
> opposed to 'linear' rgb colors that are intrinsically washed-out in an
> assumed_gamma 1.0 environment.
> [/quote]
>
> I used from the very start (more then 2 decades ago, I guess 3.0 at the
> time) assumed_gamma 1.0 (I already had some experience in the field of
> image processing) and no image I ever created suffered from a washed-out
> look. Some early images of mine did look ugly because my own bad choice
> of colors or bad arrangement of objects but these are no gamma related
> problems ;)
>

That was my MAJOR misunderstanding in the old days-- using assumed_gamma 2.2
simply because the rgb colors I chose didn't look like what I expected...Uh,
washed out from using the values that I *thought* were correct. (I was never any
good at trying to 'massage' linear rgb colors to look right in assumed_gamma 1.0
back then; it seemed so counter-intuitive. So assumed_gamma 2.2 seemed like an
'easy fix', ha.) But I had no clue or worry as to how that affected the
lighting; it looked OK to me at the time. Duh. Once srgb colors came along, I
finally had a long-awaited 'eureka' moment about what I had done wrong, and
finally switched to assumed_gamma 1.0. Better late than never! ;-)
>
>
> And BTW-2 your cityscape looks phantastic and things like this are still
> the strength of POV-Ray even when it has sadly fallen far behind as a
> render engine.
>
Thanks! I truly appreciate the comments.

Post a reply to this message

Thomas de Groot <tho### [at] degrootorg> wrote:

> >
> > I haven't used POV-Ray in years and never used the srgb keyword in my
> > whole live (I switched to Adobe RGB a long time ago) so I'm not sure if
> > it will swallow this syntax but at least you should get the idea...
> >
> > #declare C = (srgb <.3,.5,.7>) * 0.7;
> >
>
> Maybe you remember the Bald Eagle / Clipka discussion in
>
http://news.povray.org/povray.advanced-users/thread/%3C57894ece%241%40news.povray.org%3E/
>
> I digested that at the time in the attached macro. I think (?) this is
> (part of) this answer...
>

Thanks for that! It's probably another discussion that I didn't pay attention to
at the time. :-(

Post a reply to this message

Am 10/28/2020 um 12:05 schrieb Bald Eagle:
> 
> The intense friction between the theoreticians and empirical experimentalists
> and engineers is likely to be eternal  ;)
> 
Having been on both sides during my career did work quite well for me ;)

> 
> When everything is expressed in pigment {rgb <r, g, b,>} at assumed_gammma 1.0,
> everything seems pretty straightforward.
> 
Sure.

> But let's say someone borrows a nice texture that has srgb keywords sprinkled
> throughout its declaration.  The color that pigment color values that get
> "exposed" to the other elements in the scene are still just - rgb, correct?
> 
Absolutely. The srgb keyword just tells POV-Ray to consider this color 
as beeing encoded with the sRGB gamma transfer function and converts it 
immediately to its linear equivalent.
As long one is aware that rgb has to be followed by an linear color 
expression everything is fine while on the other hand an expression like 
rgb <220, 32, 80>/255 together with assumed_gammma 1.0 cries out to 
produce an unwanted result.
In the times before 3.7 it was very hard to work with any kind of image 
map with assumed_gammma 1.0 but Christoph did a really great job in 
fixing all these issues - and IMHO quite underrate as this was an 
endeavor of epic proportions.


> Two things which seem pretty unclear are the effect of assumed_gamma srgb,
> and/or a light source defined as srgb.  I can conceive the light source as just
> being the rgb end result of the srgb conversion formula, like the texture
> example, but just checking.
> But assumed gamma must affect the whole scene - presumably by doing all of the
> color calculations in "srgb color space".  Which with my present understanding,
> and peeks into the source code, lead me to speculate that multiplying a pigment
> color by a light source color gets a whole lot more complicated.
> 
assumed_gamma srgb is close to assumed_gamma 2.2 with all its well known 
drawbacks: POV-Ray will work internally not in a linear color space 
resulting in hue-shifts all over the place.
assumed_gamma srgb is useful when using POV-Ray only as a 
"painting-tool" for drawing graphs or the like...


> Does one use srgb for all colors in assumed_gamma srgb scenes or rgb?

This doesn't matter as rgb just takes the value as is and srgb converts 
into the target space which means in this case no conversion at all 
resulting in the same thing.

> 
> What's the proper way to instantiate image_maps that may be encoded by libraries
> with in-built gamma handling precorrections?
> 
While I have no idea what exactly you do mean by this let me tell you 
this: as long those libraries follow the appropriate image file format 
specifications POV-Ray shouldn't have any problems and otherwise these 
libraries are crap anyway.


> I guess the concern here with many of my examples / implied questions is the
> user trying to do something with srgb, and the software then doing a second
> conversion - or the user NOT doing a conversion where needed and winding up not
> using the color values needed for consistency with the rest of the scene, or
> something getting corrected by the software in the opposite direction because a
> user wasn't aware of a required precorrection.
> 

My point of view here is quite simple: If you aim at any degree for 
realism in your renders you'll have to use assumed_gamma 1.0 and make 
sure that everything that follows the expression rgb is encoded with a 
linear gamma.
This is not my personal opinion, this isn't even an opinion this is a fact.
On the other hand you may not aim for any photo-realism at all then 
POV-Ray allows you to do whatever fits your needs.
This great range of freedom also allows you to mess up things in any 
wanted or unwanted way - this is the price you have to pay for your freedom.


-Ive

Post a reply to this message

Ive <ive### [at] lilysoftorg> wrote:
>
> Well, now I have read through the whole thread. What a mess. There are
> so many false statements, combined with completely correct statements
> and - as usually - the worst ones: almost true statements.
> And then are the things that are simply not relevant anymore (like the
> whole discussion with Warp - Clipka expanded the color_map syntax so
> that none of the complains is still valid).

"Science advances by taking two steps forward and one step back."
Or here, maybe it was 1 step forward and two steps back :-P

I sometimes think of the newsgroups as a kind of 'community sketch pad, where
someone starts out by drawing a few basic shapes or blobs (the "idea"), then
others start adding their own doodles, then erasures, then recapitulations of
the 'history of art', then more doodles... until, hopefully at the end, there is
a 'nice final picture' of the original idea. But sometimes its a real mess
getting there, I agree. (And I'm certainly to blame, here.) But the final result
can be... awesome! Too bad that we can't clean up the mess, by deleting all the
extraneous stuff and dead ends. ;-) Ah, but that's the interesting (and messy)
history of how we got to the end result... to be kept in the archives for all
time, ha. :-O
>
> My point of view here is quite simple: If you aim at any degree for
> realism in your renders you'll have to use assumed_gamma 1.0 and make
> sure that everything that follows the expression rgb is encoded with a
> linear gamma.

I'm genuinely curious about image_map use in that context, and how it is handled
by POV-ray internally. You mentioned, I think, that the *linear* contents of the
image's colors/brightness are used for internal computations(?), regardless of
what we 'see' in the render. If I'm correct about that, do you know if radiosity
from an image_map uses the *linear* values to 'shed its light' into the scene?
In other words, are the radiosity patches' 'colors' based on the linear-color
values of the image? Or does radiosity 'radiate' the 2.2-gamma colors, the image
colors that we 'see' in the render? It would seem that there would be a wide
color difference between the two schemes... with perhaps different visual
results than we might imagine or expect, depending on the scheme used. (A rough
analogy would be, using rgb colors vs. srgb colors for an object's pigment.)

Post a reply to this message

Op 28/10/2020 om 10:33 schreef Ive:
> Am 10/28/2020 um 8:54 schrieb Thomas de Groot:
>>
>> Maybe you remember the Bald Eagle / Clipka discussion in 
>>
http://news.povray.org/povray.advanced-users/thread/%3C57894ece%241%40news.povray.org%3E/

>>
> I admire your memory. Especially not just remembering it - but also 
> *where*.
> 
> But no I don't think I did read this thread, otherwise I would have been 
> tempted to remark that my silly demo scene "cyndi cubes" demonstrates 
> the usage of the macros from my file CIE_tools (both part of the 
> Lightsys package) and these would be much more powerful (e.g. would also
> be able to compensate for whitepoint errors) than Clipka's suggestions.
> 
> Which reminds me, these files were written back in 2003, long before 
> Christoph even joint the POV-Ray community and meanwhile he already left 
> - people come and go and doesn't time fly by?
> 

My memory was from something Christoph said and which I noted down as 
the words of the oracle. So I just had to look for the oracle and there 
it was, with reference et al. ;-)

This whole rgb/srgb business has been a difficult one for me and I just 
try to follow the advices of my learned friends. Breaking the rules more 
often than not I am afraid.

I am sad about all those people who have left and who had something 
tangible to contribute, if only for their amazing scenes. But that is 
life I guess...

-- 
Thomas

Post a reply to this message

Am 10/29/2020 um 0:40 schrieb Kenneth:
> 
> "Science advances by taking two steps forward and one step back."
> Or here, maybe it was 1 step forward and two steps back :-P
> 
Well, even in science - at some point - findings turn into knowledge and 
facts. No astronomer or cosmologist has any doubt about Newtons laws of 
gravity and no - general relativity didn't proof them wrong, it still 
includes Newtons laws. By accepting them and using them we are even able 
to send probes to the border of the solar system by accelerating them 
with sling-shots around Jupiter.


> I sometimes think of the newsgroups as a kind of 'community sketch pad, where
> someone starts out by drawing a few basic shapes or blobs (the "idea"), then
> others start adding their own doodles, then erasures, then recapitulations of
> the 'history of art', then more doodles... until, hopefully at the end, there is
> a 'nice final picture' of the original idea. But sometimes its a real mess
> getting there, I agree. (And I'm certainly to blame, here.) But the final result
> can be... awesome! Too bad that we can't clean up the mess, by deleting all the
> extraneous stuff and dead ends. ;-) Ah, but that's the interesting (and messy)
> history of how we got to the end result... to be kept in the archives for all
> time, ha. :-O

Sure. But then someone (was it you? If so, I'm sorry I do not mean it 
personal) turns up with a link to some past discussion that is meanwhile 
(since 3.7) completely obsolete and frankly, complaining about a minor 
detail that could already be solved within 3.6 (poly_wave as I did 
suggest there) appears to me not like an epic battle, more like a boring 
minor battle of retreat.
So this NG is like the rest of the net. One has to learn how to assess 
and classify the threads written here in the past.

> 
> I'm genuinely curious about image_map use in that context, and how it is handled
> by POV-ray internally. You mentioned, I think, that the *linear* contents of the
> image's colors/brightness are used for internal computations(?), regardless of
> what we 'see' in the render. If I'm correct about that, do you know if radiosity
> from an image_map uses the *linear* values to 'shed its light' into the scene?

Since 3.7 (and assumed_gamma 1.0 of course):

Every image that is loaded via image_map is internally converted 
automagical into a linear representation. POV follows the rules of image 
file format specification and does everything right. In case you KNOW 
that the image you intent to load is different you can use the gamma 
modifier for image maps and tell POV-Ray what it should assume.
Like e.g. image_map {jpeg "my_image" gamma 1.8} for a jpeg file that was 
produced 30 years ago on a Mac.

Every image that is loaded via bump_map is assumed to be already a 
linear representation of the bumpiness (as it should be) and will 
internally be represented as is. In case you KNOW that your map is gamma 
encoded (for whatever reason) you should tell POV-Ray like e.g.
bump_map {jpeg "my_bump" gamma 2.2}.

As POV-Ray has no native support for transparency maps, specularity 
maps, roughness maps, metallicity maps (all of them are pretty much 
standard in professional PBR rendering and as such are always considered 
to be in linear color space as a de facto standard) but can use them 
with the help of the pigment_pattern statement one should always add 
gamma 1.0 to the image_map expression when the image is *NOT* meant to 
be an "image" but a map of some kind.

And radiosity? There is a reason that file file formats like OpenEXR and 
Radiance HDR are already per definition encoded in linear color space.
So, to answer your question, of course uses the radiosity calculation 
linear values.


A final remark: not using assumed_gamma 1.0 causes hue-shifts that 
become more dramatic the more complex the lighting situation is AND it 
violates the very basic low of energy conservation. There is no brick 
wall that reflects more light than shines on it.
If one has no problem with this two issues I'm absolutely fine with this 
but please do not complain about unexpected results.
And if somebody uses assumed_gamma 2.2 and produces a brilliant image 
I'm glad for him but this proofs nothing and is no reason to start this 
discussion again.


-Ive

Post a reply to this message

On 10/29/20 5:20 AM, Ive wrote:
<snip>
> A final remark: not using assumed_gamma 1.0 causes hue-shifts that 
> become more dramatic the more complex the lighting situation is AND it 
> violates the very basic low of energy conservation. There is no brick 
> wall that reflects more light than shines on it.
> If one has no problem with this two issues I'm absolutely fine with this 
> but please do not complain about unexpected results.
> And if somebody uses assumed_gamma 2.2 and produces a brilliant image 
> I'm glad for him but this proofs nothing and is no reason to start this 
> discussion again.

lol...thud (thanks btw)

Post a reply to this message

Ive <ive### [at] lilysoftorg> wrote:

> So, to answer your question, of course uses the radiosity calculation
> linear values.

Thanks; that was one of the 'missing links' in my conception of radiosity use.
>
>
> A final remark: not using assumed_gamma 1.0 causes hue-shifts that
> become more dramatic the more complex the lighting situation is AND it
> violates the very basic low of energy conservation.

Yes, that is how I now understand any *non*-assumed_gamma 1.0 to operate. (And
of course, visual results bear it out.)


> ... And if somebody uses assumed_gamma 2.2 and produces a brilliant image
> I'm glad for him but this proofs nothing and is no reason to start this
> discussion again.
>

Well, in an ideal world, with everyone having perfect recall of all of the
arcane details that make up POV-ray, I would agree. But the trouble with the
newsgroups (and even the highly-detailed reference wiki) is that the true
'nuggets of wisdom' are spread out and not easily referenced. (That's probably
the case with any large collection of facts.) In the newsgroups here, the truly
useful nuggets are contained *somewhere* in x-number of years of posts, and it
sometimes takes real detective work to find them.

I bow down to anyone who can keep *all* of that stuff in memory, for instant
recall!

Thomas here, and Bald Eagle as well AFAIK, have apparently taken the time to
create a compendium of pertinent links to old posts, that they can refer to. I
used to do the same-- until my old Win XP computer failed...and I had stupidly
neglected to back up my years of 'net links. (I've learned my lesson, the hard
way.) For me, it's almost like starting again from ground-zero.

The point is, it's not easy (at least for me) to remember all the do's and
don'ts of POV-ray operation, and especially the 'why'.

One of Clipka's many strengths was that he had infinite patience in answering
the 'same ol' questions' over and over again. Aside from his knowledge and his
willingless to share it, that was the one quality that stood out.

Post a reply to this message

Op 29/10/2020 om 17:22 schreef Kenneth:
> Thomas here, and Bald Eagle as well AFAIK, have apparently taken the time to
> create a compendium of pertinent links to old posts, that they can refer to. I
> used to do the same-- until my old Win XP computer failed...and I had stupidly
> neglected to back up my years of 'net links. (I've learned my lesson, the hard
> way.) For me, it's almost like starting again from ground-zero.
> 
> 
My compendium of pertinent links is small as I did really start that 
quite recently after I lost so much time in tracing back relevant info 
(and/or history) I needed for particular projects. The net (and hence 
POV-Ray) is great for re-inventing the wheel at regular times :-) No 
criticism involved here; it is the nature of the net that stimulates 
this I am afraid, and its volatile way of "remembering" and "forgetting" 
things. The same goes for all those people who were present during those 
early days of POV-Ray and have vanished now, sometimes suddenly, 
sometimes gradually, but knowledge has gone with them, if that knowledge 
had not been secured one way or another.

I suppose prehistoric man experienced the same phenomenon: one tribe 
discovered a novel way of knapping silex tools. They boasted about it in 
the neighbourhood but were wiped out by their version of covid-19 before 
the knowledge was spread. It certainly is true of his spread from 
Africa: it happened several times but only few expansion waves were 
successful.

[and now I shut up]

-- 
Thomas

Post a reply to this message

Let me stick out my neck once again. ;-)

Back in 2014, and following some discussion it appears, I composed this 
test scene, without really understanding the matter. What is wrong?

-- 
Thomas

Post a reply to this message

Attachments:
Download 'utf-8' (6 KB)

Am 10/30/2020 um 9:15 schrieb Thomas de Groot:
> Let me stick out my neck once again. ;-)
> 
> Back in 2014, and following some discussion it appears, I composed this 
> test scene, without really understanding the matter. What is wrong?
> 

I didn't run it as I do not have Ricky's include file anyway but from 
looking at it there is nothing wrong

The first box under "Ive's macros" should be brighter and less saturated 
and the second one should be the same as your 1st reference color.
If this is not what you expect you might want to check your expectations
But in case you want *my* boxes to look the same as *your* reference 
boxes you should obviously also use "MyColor" for the first box and 
sRGB_to_scRGB(MyColor) for the second one as this does exactly the same 
as the POV-Ray keyword srgb.

-Ive

Post a reply to this message

Ive <ive### [at] lilysoftorg> wrote:
>
> I didn't run it as I do not have Ricky's include file anyway but from
> looking at it there is nothing wrong

https://news.povray.org/%3C5513104c%241%40news.povray.org%3E

Post a reply to this message

Ive <ive### [at] lilysoftorg> wrote:
> Am 10/28/2020 um 12:05 schrieb Bald Eagle:
> >
> > But let's say someone borrows a nice texture that has srgb keywords
> > sprinkled throughout its declaration.  The color that pigment color values
> > that get "exposed" to the other elements in the scene are still just - rgb,
> > correct?
> >
> Absolutely...[snip]
> As long one is aware that rgb has to be followed by an linear color
> expression everything is fine while on the other hand an expression like
> rgb <220, 32, 80>/255 together with assumed_gammma 1.0 cries out to
> produce an unwanted result.

Sorry, I was just re-reading the posts here. Did you mean to say
    srgb <220, 32, 80>/255  there?

I assume from what's been said that  rgb <220, 32, 80>/255 is the same as
rgb <0.8627,0.1255,0.3137> -- simple division in 'linear' rgb space.

Whereas SRGB <220, 32, 80>/255 would be the one that "cries out to produce an
unwanted result".

Correct?

(or perhaps I was reading your comment somewhat out-of-context, and that you did
mean  rgb <220, 32, 80>/255 as *turned into*  SRGB <220, 32, 80>/255, with the
warning.)

Just wanted to make sure :-)

Post a reply to this message

Op 30/10/2020 om 10:25 schreef Ive:
> Am 10/30/2020 um 9:15 schrieb Thomas de Groot:
>> Let me stick out my neck once again. ;-)
>>
>> Back in 2014, and following some discussion it appears, I composed 
>> this test scene, without really understanding the matter. What is wrong?
>>
> 
> I didn't run it as I do not have Ricky's include file anyway but from 
> looking at it there is nothing wrong
> 
> The first box under "Ive's macros" should be brighter and less saturated 
> and the second one should be the same as your 1st reference color.
> If this is not what you expect you might want to check your expectations
> But in case you want *my* boxes to look the same as *your* reference 
> boxes you should obviously also use "MyColor" for the first box and 
> sRGB_to_scRGB(MyColor) for the second one as this does exactly the same 
> as the POV-Ray keyword srgb.
> 

Thanks, yes, I get it. There were a couple of things terribly wrong with 
my assumptions at the time. I need to review this again.

-- 
Thomas

Post a reply to this message

Am 10/31/2020 um 8:40 schrieb Thomas de Groot:
>>
>> The first box under "Ive's macros" should be brighter and less 
>> saturated and the second one should be the same as your 1st reference 
>> color.
>> If this is not what you expect you might want to check your expectations
>> But in case you want *my* boxes to look the same as *your* reference 
>> boxes you should obviously also use "MyColor" for the first box and 
>> sRGB_to_scRGB(MyColor) for the second one as this does exactly the 
>> same as the POV-Ray keyword srgb.
>>
> 
> Thanks, yes, I get it. There were a couple of things terribly wrong with 
> my assumptions at the time. I need to review this again.
> 

Oh, just out of curiosity, do you remember where "Ive's macros" are 
from? At the time I wrote CIE.inc and added a few other function to 
lightsys I did definitely prefer this xyz_2_xyz style. And I think scRGB 
wasn't even defined at this time.

-Ive

Post a reply to this message

Am 10/30/2020 um 23:29 schrieb Kenneth:
> Ive <ive### [at] lilysoftorg> wrote:
>>>
>> As long one is aware that rgb has to be followed by an linear color
>> expression everything is fine while on the other hand an expression like
>> rgb <220, 32, 80>/255 together with assumed_gammma 1.0 cries out to
>> produce an unwanted result.
> 
> Sorry, I was just re-reading the posts here. Did you mean to say
>      srgb <220, 32, 80>/255  there?
> 
> I assume from what's been said that  rgb <220, 32, 80>/255 is the same as
> rgb <0.8627,0.1255,0.3137> -- simple division in 'linear' rgb space.
> 
> Whereas SRGB <220, 32, 80>/255 would be the one that "cries out to produce an
> unwanted result".
> 
> Correct?
> 

Err, no!
My point is when somebody uses byte values to express a color he usually 
got them from a color picker, from the Windows build in color selector, 
from an image processing program or somehow directly from an image file.
In all cases these byte values are gamma encoded.
And even he didn't use any of theses apps I'm sure he *thinks* in an 
gamma encoded space as otherwise there is no reason to use byte values 
instead of floating points.
Therefor  srgb <220, 32, 80>/255  is what he actually wants.
And yes, in this case, the the division by 255 is valid (even when it is 
within an non-linear space) because it is NOT a brightness adjustment 
(causing hue shifts) but simply converts the byte values to floating 
point making them fit into the 0.0 to 1.0 range.

-Ive

Post a reply to this message

Op 31/10/2020 om 11:52 schreef Ive:
> 
> Oh, just out of curiosity, do you remember where "Ive's macros" are 
> from? At the time I wrote CIE.inc and added a few other function to 
> lightsys I did definitely prefer this xyz_2_xyz style. And I think scRGB 
> wasn't even defined at this time.
> 

I am not sure. I wrote this scene in 2014 but I don't remember where I 
got the functions from. It must have been from a discussion at the time 
in these n.g's - I browsed around but I am unable to find a probable 
source; mention is made several times of CIE, so I wonder if I did not 
get it from there. Sorry.

-- 
Thomas

Post a reply to this message

Op 31/10/2020 om 11:52 schreef Ive:
> Oh, just out of curiosity, do you remember where "Ive's macros" are 
> from? At the time I wrote CIE.inc and added a few other function to 
> lightsys I did definitely prefer this xyz_2_xyz style. And I think scRGB 
> wasn't even defined at this time.
> 

Maybe from an "earlier" version of CIE? and/or Lightsys? That seems the 
most logical to me.

In the mean time I reviewed my scene code and added the latest Bald 
Eagle macros to the collection (see image and scene file attached). I 
added all the macros to the scene file. This is what it represents:

(1a) my reference color in linear color space;
(1b) my reference color in standard color space;

(2.1a) Ive's: conversion rgb->srgb of (1a);
(2.1b) idem but with Clipka's saturation/brightness boost added;
(2.2a) Ive's: conversion back srgb->rgb;
(2.2b) idem from the boosted color;
(2.2c) idem but using (1b);

(3.1a) Cousin Ricky's: conversion rgb->srgb of (1a);
(3.1b) idem but with Clipka's saturation/brightness boost added;

(4.1a) Bald Eagle's: conversion rgb->srgb of (1a);
(4.1b) idem but with Clipka's saturation/brightness boost added;
(4.2a) Bald Eagle's: conversion back srgb->rgb;
(4.2b) idem from the boosted color;
(4.2c) idem but using (1b).

These are macros applied indiscriminately. It seems immediately obvious 
that Bald Eagle's macros do not need the saturation/brightness boost, 
except probably where 4.2c is concerned.

I leave it to the experts to judge if this little exercise (which I 
enjoyed doing btw) is of any real use. ;-)

-- 
Thomas

Post a reply to this message

Attachments:
Download 'srgb_test.png' (84 KB) Download 'utf-8' (15 KB)

Preview of image 'srgb_test.png'

Thomas de Groot <tho### [at] degrootorg> wrote:

>
> In the mean time I reviewed my scene code and added the latest Bald
> Eagle macros to the collection (see image and scene file attached). I
> added all the macros to the scene file. This is what it represents:
>

Thanks for making this all-inclusive demonstration scene, and for posting the
code. Now I need to 'digest' all of the various color-conversion methods and
pitfalls, as well as all of the message posts here.

I am still working on my own demo scene ;-)  It will be a different way of
visualizing the color conversions-- to include rgb-vs-srgb colors in lights as
well.

Post a reply to this message