I've finally posted two renders of my original gray-band test scene, over at
p.b.i.  (Should have done so much earlier, sorry.) One rendered with
assumed_gamma at 1.0, the other at 2.0.

Ken

Post a reply to this message

I've been going over this entire discussion in my mind in great detail,
which is leading me to some odd conclusions.  But before posting those, I'd
like to ask a question about how POV operates internally:  If my monitor/OS
gamma is set to 2.0 (or even 2.2), and I use assumed_gamma of 1.0 as
recommended, what happens to POV's lighting calculations if I set
display_gamma to 1.0 as well? Such a set-up actually produces the visual
results I like to see. But if I do this, is POV still able to calculate
things the way it's designed to (since assumed_gamma is 1.0)? Or am I still
introducing "gamma abuse" into those calculations? It would *seem* not,
since as I understand matters, display_gamma is only concerned with the
"output" end of POV. But I could be wrong.

Ken

Post a reply to this message

Kenneth wrote:
> If my monitor/OS
> gamma is set to 2.0 (or even 2.2), and I use assumed_gamma of 1.0 as
> recommended, what happens to POV's lighting calculations if I set
> display_gamma to 1.0 as well?

Nothing happens to the lighting calculations (they're done with the 
numbers you specify in the scene file, which are assumed to be 
linear-to-intensity, as always). What changes is that you end up with an 
output file that's encoded with a gamma of 1.0 (i.e. stores 
linear-to-intensity values). There are two problems with that if you are 
interested in physically faithful reproduction (which, as far as I 
understand, you *aren't*):

o 8-bit sampling (256 different intensity values) is too coarse for 
linear samples, you'll clearly see color banding in the dark areas if 
you display such a file correctly (as follows).

o you need to use a file format that stores the gamma value (only PNG at 
this time) and a viewer application that honors this value and 
transforms the values read from the file from gamma-1.0-encoded to 
gamma-2.0-encoded before sending them to video memory. (Unfortunately 
most applications don't do that.)

> Such a set-up actually produces the visual results I like to see.

I presume it produces these results when you're *not* following the 
second point above. What happens in that case is that you darken the 
midtones of the image by encoding the image with a gamma of 1.0, then 
interpreting it as if it was encoded with a gamma of 2.0. Whether that 
qualifies as "abuse" is debatable. I'd say yes, but it has one advantage 
over the "non-abusive" way, rendering the image correctly and then 
darkening it in Photoshop: less rounding error because rounding is only 
done once, not twice.

If you're only publishing the final image and not the scene file, it 
doesn't matter anyway.

> But if I do this, is POV still able to calculate
> things the way it's designed to (since assumed_gamma is 1.0)? Or am I still
> introducing "gamma abuse" into those calculations? It would *seem* not,
> since as I understand matters, display_gamma is only concerned with the
> "output" end of POV. But I could be wrong.

assumed_gamma only affects the output end, too. In fact, unless you're 
using an output file format that stores display_gamma (i.e. PNG), 
there's no difference at all between changing assumed_gamma and changing 
display_gamma, as the only place they're ever used is in their quotient 
(someone correct me if I'm wrong). That's why (assumed_gamma = 2.0, 
display_gamma = 2.0) and (assumed_gamma = 1.0, display_gamma = 1.0) 
produce the same images (that are physically too dark but seem visually 
right to you).

What's bad ("bad" in the sense of "bad if a physically accurate lighting 
simulation is desired") about a display_gamma/assumed_gamma quotient 
different from your real display gamma is that it tempts you to specify 
non-linear-to-intensity numbers in the scene file (by producing 
seemingly normal images with them). That's not what the lighting 
calculations expect, and there's no way in the current POV-Ray to change 
that. (As I already mentioned, I believe assumed_gamma was originally 
intended as such a way, but it just doesn't work that way.)

If both of the conditions "display_gamma/assumed_gamma = actual display 
gamma" (to make you input linear-to-intensity numbers, which leads to 
correct lighting) and "display_gamma = actual display gamma" (to store 
the correct value in PNG files) are to be satisfied, the only solution 
is "assumed_gamma = 1, display_gamma = actual display gamma".


But I'm already talking way too much again. :) It's clear that what you 
are aiming for is not physically correct lighting, and you just have to 
accept the fact that there's no "non-abusive" way of achieving that in 
the current POV-Ray. There are actually many features in POV-Ray that 
are specifically meant for non-physically-motivated artistic purposes, 
but there is none for what you want (there may be one in MegaPOV, I 
haven't followed recent developments there). The assumed_gamma / 
display_gamma features may do what you want, but it's not what they're 
intended for.

  -Christian

Post a reply to this message

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

>
> 8-bit sampling (256 different intensity values) is too coarse for
> linear samples, you'll clearly see color banding in the dark areas if
> you display such a file correctly...

Yes, I've been reading about that on other websites. Anywhere from 12-bit up
to 14-bit seems to be required. BTW, If you haven't already done so, I
would strongly recommend taking a look at the following (more or less
definitive) website about this, and the gamma question in general...

http://www.poynton.com/notes/Timo/Concerning_Timo.html
and fish around for Poynton's other pages as well, especially his GAMMA FAQ.
 A very knowledgable fellow.
>
> o you need to use a file format that stores the gamma value (only PNG at
> this time) and a viewer application that honors this value and
> transforms the values read from the file from gamma-1.0-encoded to
> gamma-2.0-encoded before sending them to video memory. (Unfortunately
> most applications don't do that.)

Right. That's why  I don't use the .png file format for my output files.  On
both of my relatively older computers (a PowerMac and  Pentium II) I don't
seem to have ANY applications (other than POV itself) that recognizes the
gamma info embedded into it, not even the two different versions of
Photoshop I have (v4 and v5). So I use the standard PC .bmp format--not
only out of necessity, but also because the more I read about applications
treating .png "oddly," the less inclined I am to use it.

Before commenting further, a quick question: What computer
system are you running POV on?  Seems like an arcane question, I know. I'm
running v3.6.1 on 32-bit Windows.

Ken

Post a reply to this message

Kenneth wrote:
> BTW, If you haven't already done so, I
> would strongly recommend taking a look at the following (more or less
> definitive) website about this, and the gamma question in general...
> 
> http://www.poynton.com/notes/Timo/Concerning_Timo.html
> and fish around for Poynton's other pages as well, especially his GAMMA FAQ.
>  A very knowledgable fellow.

I didn't know about that Timo incident, but I do know Poynton's Gamma 
FAQ, Color FAQ etc. They're among the primary sources of my knowledge in 
this area, actually.

I just followed some links from there and ended up at an interesting 
article that seems to contradict what I said about the moon: 
<http://www.optics.arizona.edu/Palmer/moon/lunacy.htm> (Caution: his GIF 
images of a lambertian sphere are encoded with a gamma of 1 and don't 
appear correctly on usual displays! In fact, I wouldn't be too surprised 
if they were made using POV-Ray without an assumed_gamma statement.)

> Before commenting further, a quick question: What computer
> system are you running POV on?

Mac OS X on PPC G4, mostly. Occasionally, Linux or Windows on x86. Why?

  -Christian

Post a reply to this message

Kenneth wrote:

> the "darK" part of the moon

Funny it should come to this Ken.  The project that I reworked to suit POV's
gamma correction is a Pink Floyd tour stage.

P.S: oddly, it does not use the "brick" pattern.

Post a reply to this message

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

>
> I just followed some links from there and ended up at an interesting
> article that seems to contradict what I said about the moon:
> <http://www.optics.arizona.edu/Palmer/moon/lunacy.htm> (Caution: his GIF
> images of a lambertian sphere are encoded with a gamma of 1 and don't
> appear correctly on usual displays! In fact, I wouldn't be too surprised
> if they were made using POV-Ray without an assumed_gamma statement.)

That's a really fascinating, in-depth look at what is happening to light as
it reflects off the moon. Lots of "ingredients" go into it, apparently.
Thanks for posting the url; it's a question that has puzzled me long before
I picked up POV.

My own take on his CGI-rendered lambertian image is that it's pretty
spot-on! (But then, you probably expected that, eh? ;-)  )  But if that
image was created incorrectly (or displays incorrectly), wouldn't his
entire argument fall flat? He's using it as the core of his discussion, so
I expect that he went to some pains to reproduce true lambertian
characteristics. Yes, it would be interesting to know what program he
created that image on. Thought of e-mailing him; may still do so.
>
> > Before commenting further, a quick question: What computer
> > system are you running POV on?
>
> Mac OS X on PPC G4, mostly. Occasionally, Linux or Windows on x86. Why?

Well, I had begun to think that different versions of POV (on different
platforms) might be producing images differently, gamma-wise--leading to
wildly opposite viewpoints such as we have.  Although there may be
something to that (don't really know, but I'm guessing not), I've put aside
that line of thought for the time being.

But while we're on the subject--would you mind telling me what overall gamma
your various monitor/OS systems are set to? If they're "largely" different
from mine, that might explain part of our disagreement.

But I've been doing my homework--lots of gamma research--and there's just
something *wrong* with this entire POV picture. Not absolutely SURE yet what
that something is, but I'm methodically tracking it down.  Stay tuned!

Ken Walker,
bloodhound

Post a reply to this message

I need a definitive, short answer to a core question, to understand
something basic about POV behavior: When running a scene the recommended
way--using an assumed_gamma of 1, and with POV display_gamma equal to
system gamma (2.2)--should an object with a pigment of rgb <.5,.5,.5> and
finish {ambient 1 diffuse 0} ultimately end up in the preview render
glowing at 50% of total possible phosphor intensity or "brightness"?
Assuming that <1,1,1> produces the total brightness that the monitor is set
up to produce, and <0,0,0> produces the proper black level.  Leaving out a
discussion of all the intermediate steps. No light sources either.

Please, don't refer me back to other parts of this discussion, or the POV
docs. I'm looking for a concise answer. It would clarify a lot of things.

I'd especially appreciate an official response from a POV team member.

Ken Walker

Post a reply to this message

Kenneth wrote:
> Christian Walther <cwa### [at] gmxch> wrote:
>><http://www.optics.arizona.edu/Palmer/moon/lunacy.htm> (Caution: his GIF
>>images of a lambertian sphere are encoded with a gamma of 1 and don't
>>appear correctly on usual displays! In fact, I wouldn't be too surprised
>>if they were made using POV-Ray without an assumed_gamma statement.)
>
> But if that image was created incorrectly (or displays incorrectly),
> wouldn't his entire argument fall flat? He's using it as the core of
> his discussion, so I expect that he went to some pains to reproduce
> true lambertian characteristics.

My impression is that he bases the discussion on a hand-calculated 
result, not on these images. He calculated that the intensity ratio 
between quarter and full moon should be pi (that calculation is correct, 
unless I made a mistake when I did it myself), while he measured it to 
be about 10.

It's possible that he didn't know about gamma encoding, had his display 
calibrated to gamma 1, or just trusted his software to do the right thing.

> Well, I had begun to think that different versions of POV (on different
> platforms) might be producing images differently, gamma-wise--leading to
> wildly opposite viewpoints such as we have.  Although there may be
> something to that (don't really know, but I'm guessing not), I've put aside
> that line of thought for the time being.

There's no reason for such an assumption - the versions for different 
platforms are compiled from one and the same source code. To the best of 
my knowledge, the only difference between platforms is the default 
display_gamma setting. IIRC you have both a Mac and a PC, so why not try 
it yourself?

> But while we're on the subject--would you mind telling me what overall gamma
> your various monitor/OS systems are set to? If they're "largely" different
> from mine, that might explain part of our disagreement.

My Mac (my main day-to-day machine) is calibrated to gamma 1.8 because 
that's what the user interface elements of Mac OS X are made for. I 
never calibrated the PC, as I seldom use it, but I guess it's around 2.2 
as PCs usually are - if it's a power function at all, and not just 
uncorrected LCD response.

I don't think that explains our disagreement - if your statement that 
your displays are calibrated to gamma 2.0 is correct, I know how the 
images look there.

  -Christian

Post a reply to this message

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

>
> > Well, I had begun to think that different versions of POV (on different
> > platforms) might be producing images differently, gamma-wise--leading to
> > wildly opposite viewpoints such as we have.  Although there may be
> > something to that (don't really know, but I'm guessing not), I've put aside
> > that line of thought for the time being.
>
> There's no reason for such an assumption - the versions for different
> platforms are compiled from one and the same source code. To the best of
> my knowledge, the only difference between platforms is the default
> display_gamma setting. IIRC you have both a Mac and a PC, so why not try
> it yourself?

I thought about doing so, but unfortunately my "old" PowerMac will run no
POV version later than 3.1...so say the POV docs, anyway...so it wouldn't be
a true, representative test.
(Well, to be honest, I haven't actually tried downloading the 3.6 Mac
version to see if it WOULD work.  Might give it a try anyway; thanks for
the push!)

So from what you said, I can safely assume that  "porting" the POV source
code to different platforms doesn't introduce any "changes." Good to know.

Ken

Post a reply to this message