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

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

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

The 18 % refers to the amount of light that is reflected from the grey card
in relation to the light that hits it. 100 % reflection is a rare thing in
the real world, a white sheet of paper will reflect about four times as
much as the grey reference, and a black sheet of paper will reflect about a
quarter as much as grey. This corresponds to two 'stops' to either side of
gray, in photographic terms.

This middle gray on a grey card is produced, I think, by mixing equal
amounts of black and white paint (assuming they are of equal strength), so
it is a 50 % gray in 'paint' terms. I have compared the tone of a grey card
to that of a grayscale chart that you can get in a paint store, and it
matches that 50 % tone exactly. So the paint industry and the photo
industry uses the same scale, it seems.

Perception is a difficult matter, but as far as I know our senses are
logarithmic in nature; doubling the amount of light is perceived as the
same change, no matter where you are on the scale (sorry if my english is
unclear).

H

Post a reply to this message