For creating and viewing a POV scene, on any platform, a correct "composite
gamma," of all the elements of the computer setup and in POV, is the
CORE--the bottom line-- for seeing the scene's brightness levels and colors
"correctly" on screen. Meaning, having them reproduced in a way that best
matches how our eyes see them in the real world.  Simply put, gamma
correction is the overall mechanism by which tonal values on a monitor
screen are "massaged" in order for them to match what our eyes want to see.
(Gamma correction does NOT affect pure white or pure black, only the
intermediate grays.) As part of this, the gamma settings in POV need to be
such as to "trick" the eye into PERCEIVING the correct changes in
brightness levels. A POV scene's assumed_gamma value has a great deal to do
with this.

Should assumed_gamma be set to 1.0?  My own short answer is...no. At least
for Mac and PC users. I realize I'm treading on thin ice here, since
assumed_gamma of 1 has so MANY adherents in the POV community....and POV
itself suggests using it for all newly-created scenes. My reasoning is not
easily described, but here goes...

(BTW, this discussion isn't concerned with setting up POV scenes to render
correctly on others' systems. It's simply for figuring out what the user's
own system should be. Nor does it deal with the gamma-embedding .png file
type.)

As I've mentioned elsewhere, I have both a PC and an older Mac, though I run
POV 3.5.1 strictly in Windows.  I also have versions of Photoshop on both
systems, for comparing images.

Let me reiterate something, in order to drive the point home.
The first place to start with the system's overall (and necessary) gamma
correction is to set the MONITOR's gamma to what it should be.  Since the
world's PCs and the web itself are standardized around a gamma of 2.2, yet
older Macs are standardized around 1.8 (and SGIs at 1.7, so I'm told), I've
chosen 2.0 as the best way to bring my own PC's monitor/operating system
into near-accordance with most everything out there...to view others'
images more or less the way they were intended to be seen, and to produce
images in POV and elsewhere that are likewise. To configure this, I use the
Adobe Gamma control panel app, in conjunction with POV's gamma setup chart.

Once my monitor gamma is set, the next phase is setting POV's display_gamma
in the QUICKRES.INI file. From all I understand in the POV docs, this
should be the same as the monitor (2.0 in my case.)  The POV docs seem
clear about this.

So the only hurdle left is to choose the scene's assumed_gamma.  I've been
using 2.0 so far, as it just seems to reproduce colors, brightness levels
and shadows in a visually pleasing way. But many others choose 1.0, for
various reasons..mostly having to do with working in an "ideal",
undistorted linear color space. But such a render just doesn't LOOK right
to me, and in fact looks distorted, for want of a better word.  (I would be
most interested in knowing which values of monitor gamma and POV's
display_gamma are chosen in order to make that work, as well as which OS
it's being rendered on.)

To do some gamma experiments, I wrote a simple POV scene to display 21 gray
bands, from pure black to pure white, with a "mathematically linear" 5%
change between each band. (That is, the equivalent in POV of increasing the
gray by <.05,.05,.05> each time.) 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>.  That's how I write my own scenes, anyway.
(And who wants or needs to deal with picking non-linear values in POV??)
"Half as percepually bright" is subjective, I know.  But rendering a scene
using assumed_gamma of 1 just doesn't LOOK perceptually correct. 50% gray
looks too bright. If the tonal differences in the POV render were subtle,
my concerns wouldn't be important.  But the effect isn't subtle, and I kept
scratching my head about this, wondering what the grays are SUPPOSED to
look like from one step to the next, as it IS a somewhat subjective thing.
I thought of downloading some kind of gray-scale test chart to view
alongside the rendered scene, but discovered two interesting websites
instead, with some very good, possibly definitive gamma info...

http://www.poynton.com

http://www.normankoren.com/makingfineprints1A.html#gammachart

Though complex reading, these sites knowledgeably and thoroughly describe
linear vs. non-linear reproduction of brightness levels, and how our eyes
(and computer monitors) relate to them. Which got me to thinking that
assumed_gamma of 1 may be causing POV to render simple "linear" brightness
changes in a way that "defeats" some (or all) of the necessary
NON-linearity (i.e., gamma correction) that the overall system is trying to
impose (in order to render brightness levels the way the human eye responds
to them--and why, in the first place, Macs and PCs impose their own gamma
corrections on top of the monitor's "raw" gamma of 2.5)

But back to my own case. IF using assumed_gamma of 1 (along with
display_gamma of 2 and monitor gamma of 2) does in fact render a simple
"linear" reproduction of brightness levels, then my system's 2.0 gamma is
not reproducing them correctly, and the "use assumed_gamma of 1" theory
seems...flawed...at least as it's described in the POV docs. The
assumed_gamma value needs to be chosen to force POV's simple, linear values
to render more perceptually correct...creating tonal values that visually
"match" what we're all used to seeing in the real world.

Here's my "linear" gray-bar test scene, applied to a plane and a box...

// POV ver. 3.5.1

global_settings{assumed_gamma 1.0}

camera {
  perspective
  location  <.9, 6, -10>
  look_at   <.9, 0, 0>
  right     x*image_width/image_height
  angle 25
            }


#declare grey_bands =
                color_map{
                        [0.0 rgb 0]
                        [0.0476 rgb 0]
                        [0.0476 rgb .05]
                        [0.0952 rgb .05]
                        [0.0952 rgb .1]
                        [0.1429 rgb .1]
                        [0.1429 rgb .15]
                        [0.1905 rgb .15]
                        [0.1905 rgb .2]
                        [0.2381 rgb .2]
                        [0.2381 rgb .25]
                        [0.2857 rgb .25]
                        [0.2857 rgb .3]
                        [0.3333 rgb .3]
                        [0.3333 rgb .35]
                        [0.3810 rgb .35]
                        [0.3810 rgb .4]
                        [0.4286 rgb .4]
                        [0.4286 rgb .45]
                        [0.4762 rgb .45]
                        [0.4762 rgb .5]
                        [0.5238 rgb .5]
                        [0.5238 rgb .55]
                        [0.5714 rgb .55]
                        [0.5714 rgb .6]
                        [0.6190 rgb .6]
                        [0.6190 rgb .65]
                        [0.6666 rgb .65]
                        [0.6666 rgb .7]
                        [0.7143 rgb .7]
                        [0.7143 rgb .75]
                        [0.7619 rgb .75]
                        [0.7619 rgb .8]
                        [0.8095 rgb .8]
                        [0.8095 rgb .85]
                        [0.8571 rgb .85]
                        [0.8571 rgb .9]
                        [0.9048 rgb .9]
                        [0.9048 rgb .95]
                        [0.9524 rgb .95]
                        [0.9524 rgb 1.0]
                        [1.0 rgb 1.0]
                                    }

// ---------------

plane {y, 0
        texture{
                pigment{
                        gradient x
                        color_map{grey_bands}
                        scale <4.5,1,1>
                        translate -1.4*x
                            }
                finish{
                        ambient 1
                        diffuse 0
                        }
                   }
        }



// cube
object{
     box{0,1
        texture{
                pigment{
                        gradient x
                        color_map{grey_bands}
                            }
        finish{
                ambient 1
                diffuse 0
                }
                   }
            }
           scale 1.4
           translate <.2,.5,-3>
         }


I would be interested in knowing what other POV users see, running this
test.  On my own system, using assumed_gamma of 1, the brighter grays
appear to have too many levels (i.e., small visual differences between
values, and with more bands, spread further across the chart.) The dark
gray bands, especially near black, have too few levels (i.e., greater
differences between values, and "compressed" into a smaller space).
Basically, a much more abrupt perceptual change from black up to the first
dark gray, than from white down to the first bright gray. Lowering
assumed_gamma even further, in small increments, exaggerates this effect.
Norman Koren's website has a similar gray-band chart and describes in more
detail what happens. Simply put: Across all 256 (8-bit) gray steps that POV
can typically produce--a continuous gray scale--the darker grays are
"compressed" and the lighter grays "expanded."  The overall system is thus
giving "unequal visual weight" to the lighter grays. When looking extremely
close-up at such a continuous spread, where you can see the individual
steps in brightness, the light gray steps are actually wider, the dark gray
steps narrower. Ideally--from a visual standpoint-- the steps should be
"equal" in size across the entire spectrum. This isn't the case when using
assumed_gamma of 1.  So in a typical POV scene, the brighter colors and
grays will appear somewhat washed-out.

A Kodak "photographic gray card" -- neutral gray, in other words-- has an
actual reflectance of only 18% (not 50% as would be assumed.) This
corresponds to a PERCEPTUAL brightness of "half as bright as white,"
whether viewed with the eye or by photographic film.  As Poynton says in
his gamma discussion, "A source having a luminance of 18% of a reference
luminance will appear half as bright." This is the human eye's PERCEPTUAL
response to luminance....which isn't linear.  A POV-generated gray value of
<.5,.5,.5>, applied to an object with finish{ambient 1 diffuse 0}, should,
it seems to me, reproduce on screen in the same way...half as PERCEPTUALLY
bright as (POV) white.  "Raw" monitor gamma/OS
gamma/display_gamma/assumed_gamma all contribute to make that a reality, of
course. So POV's assumed_gamma must be chosen to take that POV <.5,.5,.5>
gray and place it squarely in the "middle" of our PERCEPTION of
black-to-white.

SO...what should assumed_gamma be, for POV to produce--and the eye to
perceive -- "equally weighted" brightness changes in a rendered POV scene?
On my own system, with both monitor gamma and display_gamma set at 2.0, a
value of from 1.8 to 2.0 *seems* to be the right choice...confirming what I
had always been using. Although I have no absolute, foolproof way of
knowing if what I'm seeing is correct, a numerically identical gray-band
chart I created in Photoshop on my PC, and viewed there, EXACTLY matches my
POV render using assumed_gamma of 2.0 (Is the Photoshop test itself
displaying "perceptually equal" grays? Can't say that I really know for
sure, short of attempting to compare the screen image to an accurate
physical gray-scale test chart. But this is the same Photoshop that always
displays digital photos and all other images "correctly" to my eyes.)

The only other test I could think of was this: I rendered two versions of my
POV gray-band scene (both with display_gamma set at 2.0.)--- one with
assumed_gamma of 2.0 and one with 1.0  Both were output as .bmp files so as
not to include any embedded gamma correction, and brought up in Photoshop
(on BOTH of my computer systems.) PS's eyedropper tool was used to measure
the brightness levels of each gray band in both images. The values in the
assumed_gamma 2.0 image EXACTLY match their counterparts in the Photoshop
test (that is, exact 5% increments.) The values in the assumed_gamma 1.0
image are definitely "distorted." (In fact, between pure black and the next
lighter band, there is a 19% difference instead of 5%!)

Interestingly, my PS test chart image, viewed in PS on the PC but with the
middle LEVELS slider changed from 1.0 to 2.0 (which is actually a gamma
adjuster), forces it into almost EXACT numerical and visual accordance with
the "distorted," assumed_gamma 1.0  POV render! Doing the reverse--bringing
the distorted POV image up in PS and adjusting the LEVELS to .5 (.5 being
the inverse of 2.0) brings that image into PERFECTLY exact accordance with
the "correct" PS test image!

Another important point: Leaving my monitor gamma at 2.0 and making POV's
display_gamma and assumed_gamma BOTH 1.0, does display the POV-generated
gray bands in a "perceptually equal" way (in PS as well.) Which also shows
that monitor gamma and display_gamma don't have to match. The POV docs make
no mention of these little tidbits, AFAIK... and I wish they did!! Perhaps
this is what the POV docs meant all along??

A little aside: POV's gamma test chart simply shows what your monitor gamma
is...and usually agrees fairly well with it. But setting your monitor's
"black level" (using it's BRIGHTNESS control) is important for getting the
monitor to display a truly correct gamma. This is touched on in the POV
docs but doesn't explain it well. By adjusting brightness, you can "tweak"
the gamma of the monitor to EXACTLY match the chart.

Post a reply to this message

Note that the way gamma correction is handled will change with the
next version of POV-Ray (ie. 3.7).

-- 
                                                          - Warp

Post a reply to this message

Kenneth wrote:
> [...]
> 
> Should assumed_gamma be set to 1.0?  My own short answer is...no. At least
> for Mac and PC users. I realize I'm treading on thin ice here,

Not on thin ice, you are already deep in the water...

What you wrote is full of errors and misconceptions - i could make a 
long list.  But i won't do.  Color handling in computers and color 
perception is a complicated issue.  So you are in good company when not 
fully understanding it.  The POV-Ray docs chapter on gamma correction is 
meant to give a quick insight into what's necessary to set up the gamma 
correction in POV-Ray correctly.  It is not meant as an introducetion 
into color processing at all, it just deals with gamma correction:

http://en.wikipedia.org/wiki/Gamma_correction

nothing more.  It does not say that the results you get when following 
these instructions will be in any way pleasing or appear more 
'realistic' to you than any other settings.

And finally it should be noted that using any value for assumed_gamma 
other than 1.0 or no value at all could lead to trouble with future 
versions of POV-Ray since abuse of gamma correction for tone mapping 
purposes might not be supported any more (you can still set whatever 
gamma factor you want in command line/ini options of course).

Christoph

-- 
POV-Ray tutorials, include files, Landscape of the week:
http://www.imagico.de/ (Last updated 31 Oct. 2005)
MegaPOV with mechanics simulation: http://megapov.inetart.net/

Post a reply to this message

I've never really understood why POV-Ray should do gamma-correction.  
Isn't that up to the display-drivers?  Wouldn't it be more logical if 
POV-Ray just assumed that 50% of the RGB-values give 50% of the 
brightness ?

Now, as I understand it, that *is* the default behaviour of POV-Ray, but 
then why do some image_maps look a lot darker than they should?  What 
are the correct settings to completely turn off any gamma-correction ?

tnx in advance,

-- 
#macro G(b,e)b+(e-b)*C/50#end#macro _(b,e,k,l)#local C=0;#while(C<50)
sphere{G(b,e)+3*z.1pigment{rgb G(k,l)}finish{ambient 1}}#local C=C+1;
#end#end _(y-x,y,x,x+y)_(y,-x-y,x+y,y)_(-x-y,-y,y,y+z)_(-y,y,y+z,x+y)
_(0x+y.5+y/2x)_(0x-y.5+y/2x)            // ZK http://www.povplace.com

Post a reply to this message

AFAIK: There are two parts: the assumed_gamma and the display_gamma.
Assumed_gamma is used internally during the raytracing, which is the reason
why it should be set to 1.0: so that the internal calculations are done in
the correct, linear colorspace.
Display_gamma is applied *after* the raytracing, and is meant to ensure that
when *rendering* the image on different PCs with different gamma, the output
*looks* the same.

To get no gamma-correction whatsoever, use the same assumed_gamma as
display_gamma.

Curiously, I checked what happens with PNG, as they have
"inbuilt"-gamma-values. When using assumed_gamma of 1 and display_gamma of
2.2, the image looks the same *for most parts*, but some darker areas get
color-banding. If I use assumed_gamma=display_gamma=2.2, the input-image
looks like the output image. I assume that's due to the internal PNG-gamma
correction and the usual floating-point accuracy (which I often would rather
call "floating-point inaccuracy" ;-P).

Now, as for making use of image-maps in assumed_gamma=1 and
display_gamma=2.2 scenes, I'm wondering if it shouldn't be possible somehow
to use functions to add an inverse gamma-correction to the image-map, so
that even though POV-Ray gamma-corrects, the image-maps will look the same.
I would have use for this for my next short, so maybe I'll have to tackle
that problem some time in the future. Again, this would only take care to
look proper on a certain system with specified gamma, but then again,
everyone is working with *his* system as reference and just wants it to look
the same on other's systems.

Anyways, I'm not 100% sure if I'm correct or make sense, so if any of the
more insightful people wants to correct me, I'm all ears. :-)

Regards,
Tim

-- 
aka "Tim Nikias v2.0"
Homepage: <http://www.nolights.de>

Post a reply to this message

Zeger Knaepen wrote:
> I've never really understood why POV-Ray should do gamma-correction.  Isn't that up
to the display-drivers?  Wouldn't it be more logical if POV-Ray just assumed that 50%
of the RGB-values give 50% of the brightness ?

That might be good but in reality it isn't.  In fact these days it would 
probably make sense to have all display devices perform gamma correction 
internally.  Instead there is the sRGB standard which uses a gamma of 
2.2.  Some (usually more expensive) monitors have an sRGB setting where 
they act as an sRGB device and transform the signals to their own 
characteristics internally.

Note current implementations of the X-Window system support adjusting 
gamma correction for the graphics display globally (might be subject to 
support by the display driver):

http://wiki.x.org/X11R6.8.0/doc/xorg.conf.5.html#sect9

but it hardly makes sense to use this to get a linear characteristic of 
the display since all colors (on websites, in images or elsewhere) will 
be displayed incorrectly (unless *all* the programs you use can render 
into linear color space).  What makes sense is to use this feature to 
adjust for the difference between your monitor and sRGB (either by 
estimation or using an actual calibration device).

> Now, as I understand it, that *is* the default behaviour of POV-Ray, but then why do
some image_maps look a lot darker than they should?  What are the correct settings to
completely turn off any gamma-correction ?

If you don't specify any assumed_gamma in the scene file the render is 
done without any gamma correction.

Christoph

-- 
POV-Ray tutorials, include files, Landscape of the week:
http://www.imagico.de/ (Last updated 31 Oct. 2005)
MegaPOV with mechanics simulation: http://megapov.inetart.net/

Post a reply to this message

Tim Nikias wrote:
> AFAIK: There are two parts: the assumed_gamma and the display_gamma.
> Assumed_gamma is used internally during the raytracing, which is the reason
> why it should be set to 1.0: so that the internal calculations are done in
> the correct, linear colorspace.
> Display_gamma is applied *after* the raytracing, and is meant to ensure that
> when *rendering* the image on different PCs with different gamma, the output
> *looks* the same.

That's not correct, the gamma correction is performed exactly as 
described in the docs, section 3.3.3.3.

> Now, as for making use of image-maps in assumed_gamma=1 and
> display_gamma=2.2 scenes, I'm wondering if it shouldn't be possible somehow
> to use functions to add an inverse gamma-correction to the image-map, so
> that even though POV-Ray gamma-corrects, the image-maps will look the same.
> I would have use for this for my next short, so maybe I'll have to tackle
> that problem some time in the future. Again, this would only take care to
> look proper on a certain system with specified gamma, but then again,
> everyone is working with *his* system as reference and just wants it to look
> the same on other's systems.

It's not quite as simple.  Applying a gamma modification to the color 
values when reading from the image will result in information loss (and 
possibly color banding etc.).  Applying them when evaluating the 
image_map will result in performance loss.  This does not mean an 
internal pre-processing feature for images could not be useful but it is 
not as straight away as it might seem.

And if such a feature is introduced in some way you will have to specify 
the gamma factor for the image in the scene.  It will not use the 
display_gamma settings for reading images (this would be completely mad 
since the gamma correction of the image has nothing to do with the 
target gamma of the render).

Christoph

-- 
POV-Ray tutorials, include files, Landscape of the week:
http://www.imagico.de/ (Last updated 31 Oct. 2005)
MegaPOV with mechanics simulation: http://megapov.inetart.net/

Post a reply to this message

First of all, your post is so long that I only skimmed over it, so I 
apologize if I misunderstood something. But I still think I have to 
comment on some points.

> older Macs are standardized around 1.8

Not just older Macs. I've never seen it documented anywhere, but 
according to what Apple's display calibration utility does, that number 
is still valid.

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

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.

For me, from the point of view of the POV-Ray scene, <.5, .5, .5> means 
"that surface's diffuse reflectivity is half that of the other one" with 
  <1, 1, 1>. From the point of view of the rendered image displayed on a 
computer screen, it means "the physically measurable light intensity 
(W/m^2) emanating from these pixels is half the one emitted by those 
pixels".

Of course that means that you and I are starting from different 
premises, so there's probably no point in any further discussion about 
the fact that I think assumed_gamma 1.0 is correct. That's why I allowed 
myself to answer before having thoroughly read your whole argument.

  -Christian

Post a reply to this message

> > AFAIK: There are two parts: the assumed_gamma and the display_gamma.
> > Assumed_gamma is used internally during the raytracing, which is the
reason
> > why it should be set to 1.0: so that the internal calculations are done
in
> > the correct, linear colorspace.
> > Display_gamma is applied *after* the raytracing, and is meant to ensure
that
> > when *rendering* the image on different PCs with different gamma, the
output
> > *looks* the same.
>
> That's not correct, the gamma correction is performed exactly as
> described in the docs, section 3.3.3.3.

Hm. Correct me if I'm wrong again, but I find the description a little
confusing. If I use assumed_gamma in my scene, THEN some sort of
gamma-correction will be applied to the final saved image, otherwise, no
gamma-correction.
The gamma-correction itself is dependant on the values for assumed_gamma and
display_gamma, and this also gets saved to disk. Unless you use PNG, the
file won't know its gamma, and thus, will probably end up looking different
on different monitors.

Why then should we use assumed_gamma of 1.0?

I've also just tested using display_gamma 1.0 and assumed_gamma 1.0, and
then, the image gets *really* dark. I assumed (probably wrong, though) that
both at 1.0 should result in no change from raytracing input to file-output.

And if I leave out assumed_gamma (hence no gamma-correction, I'd think), the
image gets even darker (this should be expected if display_gamma is really
2.2 but only set to 1.0, I guess). Display_gamma 2.2 and no assumed_gamma,
again, image is darker than original.
This stuff is all pretty confusing, I don't get what I expect. Which is
probably due to some misunderstanding on my part...

How about someone explains (without that much mathematical stuff as in the
docs) how assumed_gamma, display_gamma and file-saving works? Default
settings, gamma-correction (when and how it is applied)...

-- 
aka "Tim Nikias v2.0"
Homepage: <http://www.nolights.de>

Post a reply to this message

Tim Nikias wrote:
> 
> Why then should we use assumed_gamma of 1.0?

Because that is what's recommended in the docs. When the gamma 
correction options are changed it will be considered what's written in 
the docs and if you follow the recommendation it is more likely that 
scenes will work without changes than if you don't.

Christoph

-- 
POV-Ray tutorials, include files, Landscape of the week:
http://www.imagico.de/ (Last updated 31 Oct. 2005)
MegaPOV with mechanics simulation: http://megapov.inetart.net/

Post a reply to this message