Kenneth, thanks for stirring this up again (seriously).  The previous
discussion about this died early.  In case you're feeling patronised
by the other responses, I did read your entire post and I understand
your argument.  I used to agree with you, but now I'm going to try to
convince you to change your ways.

First, two points that are away from your topic.  Thanks for the link
to Norman Koren's test images.  They are the best I have seen and they
allowed me to tweak my apparent gamma down to 2.2.

Second, your test scene demonstrates our eyes' edge-enhancement very
well: the right sides of the 50% bands appear much darker than the
left.  I had to run a colour picker over them to make sure I *was*
seeing things.

Regarding gamma abuse: I feel your pain.  Until this year I did not
have assumed_gamma in my scenes, which led to the behaviour you're
choosing.  I started the scenes before POV (DKB) knew of it.
pigment{Orange} looked orange, shadows looked good, gray10 was very
dark, and my happy little universe was properly lit.

Before we go further you should take a mathematical look at what POV
does to a 0.5 pixel.  It will save you making more test scenes and
examining them in PS.  As pointed out elsewhere in this thread,
section 3.3.3.3 tells what you need to know: with assumed_gamma
omitted or set to display_gamma, your output pixel will be exactly as
set in the pigment.  With display_gamma/assumed_gamma at 2.0, every
pixel value is raised to the power of 1/2.0.  0.5 grey will be raised
above 0.70.

Worse, 0.05 grey is taken to 0.22, which is why the difference between
the darkest two bands in your test seems ridiculous.  To get a
near-black in my scenes that will react to diffuse light but still
look dark, I have to play with input values around 0.03.  I see your
point: it seems daft.  It's just the way it is.

You have illustrated a mind-set very well.  You expect 50% to look
half way between black and white.  I felt the same way about orange.
I felt it shouldn't be yellow.  But that was naivete:  I know now that
trusting the names in colors.inc is foolishness.  I don't think you're
misunderstanding anything, and you certainly didn't deserve to be
spoken down to.  As someone who has recently taken the blue pill, been
assimilated, clicked Start, I feel qualified to respond.

Here is a summary of a summary I have put in a blog entry, which I
won't link here because it is below this NG's audience and will only
draw lofty criticism.  Tek begged us to use {assumed_gamma 1}
elsewhere in these groups after spending a chunk of his life learning
the lesson, and I will do the same:

- Set your assumed_gamma to 1.0.  It will save you pain when you move
  to 3.7.

- Grapple all your colour values down so the fully-lit pigments look
  right again.  Squaring them does the trick.  Try out your colour
  picker: your fully-lit pixels will be as they were with
  assumed_gamma 2.

- That left my half-lit faces too bright, so I reduced their roughness
  and phong_size.  I've switched to the first person here because YMMV.

Leave your display_gamma at 2.0.  Then, if you send us a PNG, our
systems will brighten it slightly so that our displays, which darken
images more than yours does, show us exactly what you see.

Sorry if this sounds preachy but, basically, deep down we're all
trying to save you pain.  Well no, USENET posters being like 4WD
drivers, some of us are showing off, making up for small tackle
(that's a different blue pill, by the way), and taking advantage of
anonymity to behave in ways that would see us beaten to a geeky white
pulp if we tried it at the pub.

But perhaps there is something worthwhile in it.

Post a reply to this message

"Ard" <ard### [at] waikatoacnz> wrote:
> Kenneth, thanks for stirring this up again (seriously).

Thanks for your very well-considered response.  Believe me, I donned a very
thick suit of armor before deciding to post my discussion! I figured I'd be
seen as either the new Einstein of POV-dom, or else a lowly protozoa ;-)
But I LIKE a lively dicussion!

Let me apologize to everyone for originally posting such a long discourse;
it's just that I wanted to cover things thoroughly.  It DID start out even
longer!

Something you said (and which Christian Walther also discussed) is probably
at the CORE of my basic misunderstanding of the topic.  As I mentioned in
my post...

"We all assume --don't we?--that POV's
color/brightness values, as used in a typical PIGMENT block, are meant to
reproduce brightness levels such that <.5,.5,.5> represents "half as
perceptually bright as" <1,1,1>."

Your own response has given me MUCH to think about...
>
> Before we go further you should take a mathematical look at what POV
> does to a 0.5 pixel.... with assumed_gamma
> omitted or set to display_gamma, your output pixel will be exactly as
> set in the pigment.  With display_gamma/assumed_gamma at 2.0, every
> pixel value is raised to the power of 1/2.0.  0.5 grey will be raised
> above 0.70. Worse, 0.05 grey is taken to 0.22, which is why the difference between
> the darkest two bands in your test seems ridiculous.  To get a
> near-black in my scenes that will react to diffuse light but still
> look dark, I have to play with input values around 0.03.  I see your
> point: it seems daft.  It's just the way it is.
>

and Christian Walther responded...

      >No. At least I don't assume that, and I think most other people with
      >some background in physically-based color theory and computer
      >graphics don't either....Of course that means that you and I are
      >starting from different premises...

That really does open my eyes, and explain a lot. Essentially, I've been
writing POV scenes using the wrong assumption! I confess it never occured
to me that I should be choosing "non-linear" color and brightness values in
my POV scenes...which would make perfect sense when using an assumed_gamma
of 1.0.  And would make my grey-band test incorrect. (Am I putting the facts
together correctly?) If so,
then...WOW...that's a big conceptual change for me.

Of course, the question that immediately comes to my mind is, "Gee, why NOT
simple linear POV values?" But I need to assimilate this paradigm shift
before posting further...

Thanks again (everyone!)

Ken

Post a reply to this message

"Zeger Knaepen" <zeg### [at] povplacecom> wrote:


> but then why do some image_maps look a lot darker than they should?
>

Tim Nikias discusses this same question in a different post, in more detail,
and it raises some interesting points...

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

Ken

Post a reply to this message

"Ard" <ard### [at] waikatoacnz> wrote:

>
> - Grapple all your colour values down so the fully-lit pigments look
>   right again.  Squaring them does the trick.  Try out your colour
>   picker: your fully-lit pixels will be as they were with
>   assumed_gamma 2.
>
YES INDEED, this does work!  I went back to my "linear" POV grey-band test
scene, squared all the RGB values (in effect, making them non-linear), and
the resulting POV render, using assumed_gamma of 1.0, looks exactly the way
it should.

FASCINATING!

So...if I had chosen 2.2 as my overall system gamma (rather than 2.0), then
I would have had to alter each of  my "linear" grey-band values by raising
them to the power of 2.2, rather than just squaring them...to get the same
pleasing visual result.  Correct?

Ken

Post a reply to this message

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

> So...if I had chosen 2.2 as my overall system gamma (rather than 2.0), then
> I would have had to alter each of  my "linear" grey-band values by raising
> them to the power of 2.2, rather than just squaring them...to get the same
> pleasing visual result.  Correct?

Yep.  When you start messing with gamma, particularly investigating the GAMA
chunks in PNGs, the number 0.45455 comes up a lot because it is 1/2.2.  POV
essentially raises every pixel value to the power of 0.45455 before writing
it to disk and placing it it in the preview.

To test all this I produced a scene of four coloured boxes and rendered it
into a 2x2 PPM.  That is human-readable, so I didn't need to load it into
an editor to run a colour picker over it, risking another application
applying gamma to the values.

You can go around raising things to the power of other things but when it
comes down to it, I think accepted POV practice is to munge numbers until
it looks right.

Post a reply to this message

if (! horse->dead)
 flog(it)
else
 flog(it)

So tweaking RGB values in pigments brings them back into line, if they are
fully lit.  But adding {assumed_gamma 1} makes the edges of soft shadows
and spotlights sharper and faces oblique to incident light brighter.  This
is why I have had to tweak surface highlights and spotlight radii to
compensate for adding gamma to old scenes.

Demonstrated in p.b.i at
http://news.povray.org/povray.binaries.images/thread/%3Cweb.43a0a486c3c8eadaed802ab30%40news.povray.org%3E/

Post a reply to this message

"Ard" <ard### [at] waikatoacnz> wrote:
> Yep.  When you start messing with gamma, particularly investigating the GAMA
> chunks in PNGs, the number 0.45455 comes up a lot because it is 1/2.2.  POV
> essentially raises every pixel value to the power of 0.45455 before writing
> it to disk and placing it it in the preview.

One thing that everybody should keep in mind when looking at gamma-corrected
images such as PNG is that many applications do *not* handle the PNG gAMA
chunk according to the specs.  Two of the main culprits are:
- All versions of Internet Explorer (including the beta version 7.0)
- Old versions of Photoshop (older than 7.0 or CS)

MSIE is known for having very bad support for transparency in PNG images
(this is fixed in MSIE 7.0) but also for its bad support for gamma
correction.  According to the PNG specs, the browser should apply the
correction when displaying a PNG image including a gAMA chunk and should
not apply it when the image does not include it.  Or to be more consistent,
if the browser applies a gamma correction to other colors such as those
from HTML, CSS or other images (JPEG, GIF) then it should do the same
for PNG images that have no gAMA chunk.  MSIE fails to do that consistently.
In addition, MSIE seems to assume that the display gamma is a bit below 2.0.
According to http://www.libpng.org/pub/png/pngapbr.html#msie-win-unix MSIE
uses an implicit display gamma of approximately 1.93.

Other browsers such as Firefox or Opera (version 7 or later) process the PNG
gAMA chunk correctly.  However, they may rely on the operating system for
some display functions so it is possible that a PNG image does not look the
same in Firefox for Windows, for Linux or for OS X.

So given that the most common applications for displaying PNG images do not
handle the gamma information correctly, one should be careful before stating
that POV-Ray handles this in the "right way" or not.

Post a reply to this message

"Ard" <ard### [at] waikatoacnz> wrote:
> if (! horse->dead)
>  flog(it)
> else
>  flog(it)
>
> So tweaking RGB values in pigments brings them back into line, if they are
> fully lit.  But adding {assumed_gamma 1} makes the edges of soft shadows
> and spotlights sharper and faces oblique to incident light brighter...
>
 YES! Very true indeed. (BTW, I did get around to running my grey_band test
scene with an overall system gamma/display_gamma of 2.2, altering the
gray-band values by raising them to the power of 2.2, and the scene did
render just as beautifully and realistically as before.)

OK. So here are the facts so far: to make my POV "linear" grey band test
reproduce in POV's preview window with a correct , real-world appearance,
and using the recommended assumed_gamma of 1.0, then my grey values need to
be specified in a NON-linear way--i.e., instead of <.5,.5,.5> being used to
represent "half as perceptually white" as <1,1,1>, the values instead need
to be raised to the power of [whatever system gamma I've chosen.]
Apparently for the sole purpose of letting POV work in its ideal "linear"
gamma-of-1.0 color space

Ugh. Well, it works, and I accept it...I'M NOT HAPPY... but I'll accept it.
For the moment anyway.

Ah, but what about lighting? As you've mentioned, strange things happen. My
test scene made no use of lights.  The gray bands were
"self-illuminated"--{ambient 1 diffuse 0}. When light sources ARE included,
things turn...ugly! Your test images over at p.b.i. show very clearly what
happens.

Funny thing. I was JUST getting ready to post my own example scene to show
these effects (and discuss them), but happened to see your examples first,
and found that your test is EXACTLY the same as mine!!! Even down to the
direction of the light source!   Adventurous minds think similarly. ;-) But
I'd like to explore this little test, as it goes to the very HEART of my
initial "perceptual" argument and discussion.  (For the edification of
others: It's just a white sphere, illuminated by a single white
point-source light placed very far away, and with no ambient lighting to
muddle things.  You can't get much simpler than that!!) But in its very
simplicity, it clearly and "honestly" shows the effect of lighting on an
object...and the fundamental difference in "render realism" between using
assumed_gamma of 1.0 as opposed to my use of 2.0 (or 1.8 or 2.2). And it
duplicates, though in a completely different way, the "distorted"
brightness levels I was seeing in my original "linear" gray band test
scene.

Everyone, take a look at Ard's assumed_gamma of 1 image--that's an order!!--
or just run such a test.  I'd really like to know how each of us perceives
the illumined sphere...how the light reacts with the curving surface. And
what we each do to correct for it...if in fact we DO correct for it. (I
do...by using assumed_gamma of 2.0! Ard uses a different method.) But
others may not do so at all...??? I'm actually going somewhere with this
argument, though it may not seem so right now; kind of like a chess game!

It's important to note that with this test, there is obviously no way within
POV to alter any of the gray values OR the lighting to be "non-linear" (as
I did to my original gray-band test scene per Ard's suggestion.) An absurd
idea anyway.

More later!

Ken

Post a reply to this message

Kenneth wrote:
> OK. So here are the facts so far: to make my POV "linear" grey band test
> reproduce in POV's preview window with a correct , real-world appearance,
> and using the recommended assumed_gamma of 1.0, then my grey values need to
> be specified in a NON-linear way--i.e., instead of <.5,.5,.5> being used to
> represent "half as perceptually white" as <1,1,1>, the values instead need
> to be raised to the power of [whatever system gamma I've chosen.]

Be careful with the word "linear" - what you mean is "linear to 
perceived brightness" (right?), whereas I (and again, I guess most other 
people with some background in the field) say "linear" when I mean 
"linear to physical light intensity". That could lead to 
misunderstandings - a linear relationship is always between two 
quantities, and saying that a quantity is "linear" without specifying to 
what other quantity it is linear only works as long as there's an 
implicit agreement about what that other quantity is. Obviously there's 
no such agreement between us two.

> Ah, but what about lighting?
> [...]
> Everyone, take a look at Ard's assumed_gamma of 1 image--that's an order!!--
> or just run such a test.  I'd really like to know how each of us perceives
> the illumined sphere...how the light reacts with the curving surface.

I just did the math, and if I assume that 1. the sphere is an ideal 
diffuse reflector and that 2. Ard's image is encoded with a gamma of 2.2 
(it is not specified in the PNG), I come to the conclusion that Ard's 
upper image (with assumed_gamma 1) is physically correct, while the 
lower one (without assumed_gamma) isn't.

If the lower image looks more aesthetically pleasing to you, that's 
probably because ideal diffuse reflectors aren't that common in the real 
world, so...

> And what we each do to correct for it...if in fact we DO correct for
> it. (I do...by using assumed_gamma of 2.0! Ard uses a different
> method.) But others may not do so at all...???

...you may change the sphere's reflectivity properties using the 
"brilliance" keyword. With "finish { ambient 0 diffuse 1 brilliance 2 }" 
(and assumed_gamma 1), a similar image to Ard's lower one is achieved. 
(I'm too lazy now to look up what brilliance does exactly, but it may be 
that  "brilliance <display_gamma>" exactly reproduces that image.)

What you're trying to do with your "assumed_gamma 2.0" is changing 
POV-Ray from taking linear-to-intensity numbers to taking 
linear-to-perceived-brightness numbers because these seem more natural 
to work with to you. However, assumed_gamma affects the output end of 
POV-Ray, not the input end, so you're also forcing POV-Ray to do its 
internal calculations with the linear-to-perceived-brightness numbers, 
and that just doesn't lead to physically correct results.

Inputting linear-to-intensity numbers makes POV-Ray do its calculations 
in a physically correct way, and using assumed_gamma 1.0 makes POV-Ray 
encode its results in the output file correctly (with your display_gamma 
value). As Christoph already said, don't misuse assumed_gamma to adjust 
your rendered image's brightness to a visually pleasing value. The 
proper way of doing that is changing the objects and light sources in 
the scene itself.

  -Christian

Post a reply to this message

Christian Walther <cwa### [at] gmxch> wrote:

>
> Be careful with the word "linear" - what you mean is "linear to
> perceived brightness" (right?), whereas I (and again, I guess most other
> people with some background in the field) say "linear" when I mean
> "linear to physical light intensity". That could lead to
> misunderstandings -

I've tried to use the word "linear" solely as a way of describing the
relative differences between my initial grey-band test values. That is,
.....05, .10, .15, .20, etc. changing "linearly" by .05 each time. And
"non-linear" as being deviations from that. I thought I made this clear in
my initial post, but if I've muddled the word usages since then, my
apologies. So "linear to perceived brightness" would be correct, as to my
usage.
>
> ...you may change the sphere's reflectivity properties using the
> "brilliance" keyword. With "finish { ambient 0 diffuse 1 brilliance 2 }"
> (and assumed_gamma 1), a similar image to Ard's lower one is achieved.
> (I'm too lazy now to look up what brilliance does exactly, but it may be
> that  "brilliance <display_gamma>" exactly reproduces that image.)
>
Hey, that's a  brilliant use of brilliance! ;-) But upon re-reading the POV
docs explaining that keyword, no mention is made of your particular use of
it.  Quite an important, basic use!  If brilliance was actually intended
for correcting the lighting of an object, shouldn't that have been covered
in a major way in the POV docs? Such an omission makes me wonder if
"correcting" for lighting anomolies...when using assumed_gamma of 1.0...was
ever even considered!

I'm following your overall logic quite well. Yes, we ARE approaching this
topic from two different standpoints. Yours seems to be that of the
scientist/engineer...and that's fine, of course. Wheras, I think of
POV as an artist's tool, one where <.5,.5,.5> being
"half as perceptully bright as white" has real validity. Let me illustrate
my mind-set this way: I came to POV from having used Photoshop for years.
As a graphics toolset, PS allows me to pick color/brightness values either
visually or by choosing rgb values. Numerically, it's own range is from 0
to 255. But the important thing is that, if I choose 127,127,127...right in
the middle...I do indeed get an on-screen gray that is "half as perceptully
bright as white." (Which is what I thought POV's <.5,.5,.5> should give me
as well.) Photoshop is, in effect, insulating me from the need to worry
about gamma correction. A beautiful, intuitive way of working!!  Yes, I
assumed from the get-go that POV operated like Photoshop...leading me to
use simple and intuitive "linear" color values in all my scenes (and an
assumed_gamma of 2.0 rather than 1.0, to "visually correct" for
that in the POV render preview...against the wishes of the
POV docs.) Believe me, I do now understand
that POV does NOT insulate me from gamma worries!!

So which philosophy of use is the more correct? I think it depends on the
use to which POV is put, and the mind-set of the user.  Purists and others
may disagree. I'm not trying to be "stubborn" about this. From my own
standpoint, of simply wanting to produce nice, realistic,
perceptually-pleasing images on my own system, then using assumed_gamma of
2.0 is just...easier and more intuitive...while 1.0 creates hurdles and
difficulties that have to be constantly addressed: having to specify
"non-linear" color values; having to add and tweak other POV values (like
brilliance) because of lighting anomolies; having to deal with image_map
images (created in any typical graphics program) that don't render
correctly unless they are in the .png format with an embedded gamma of 1.0.
These are time-consuming and non-intuitive drawbacks...to me, anyway.

If my use of assumed_gamma of 2.0 is robbing POV of its intended way of
working, I honestly won't shed too many tears. Not at the present time,
anyway! ;-) (If doing so created odd PROBLEMS in my scenes, I would think
otherwise; but so far I haven't seen gross manifestations of
that...not even subtle ones, for that matter...or
perhaps I've just figured out my own way around them.) I'm not closing the
door on assumed_gamma of 1.0; but so far, the cons outweigh the pros. And I
guess I'll just have to deal with POV 3.7 when it arrives (in its mature
state.)

My wish, from an artist's standpoint:  WOULDN'T IT BE NICE IF...POV allowed
an alternate way of working, one that allowed the use of "linear" color
values (as in Photoshop, and as in my initial POV gray-band test scene),
CHANGED those values internally to work in its own ideal color space of
assumed_gamma 1.0, and then re-massaged THOSE values before spitting them
back to the monitor, so that they appeared perceptually correct in the
user's chosen gamma environment? This would allow us graphics-oriented
folks to work in a way, and in an environment, that we're used to. It seems
that all the ingredients are there to do so..by a different internal use of
display_gamma and assumed_gamma, perhaps.  (Of course, my own use of
assumed_gamma of 2.0 mimics that behavior! But as has been pointed out,
that's not the correct way of working. A real conundrum.)

Ken

Post a reply to this message