POV-Ray : Newsgroups : povray.beta-test : Gamma tutorial for the 3.7 documentation? : Re: Gamma tutorial for the 3.7 documentation? Server Time
5 Oct 2024 00:50:30 EDT (-0400)
  Re: Gamma tutorial for the 3.7 documentation?  
From: Warp
Date: 4 Nov 2009 17:39:20
Message: <4af20298@news.povray.org>
Sven Geier <.sven.at.sgeier.dot.net.nospamplease> wrote:
> >Gamma correction is about how your *input* values are mapped to the
> >output values. In other words, when in the *input* you say "I want 50%
> >gray", gamma correction tells the program what it should write to the
> >output image in order to get 50% gray.
> >
> > Gamma correction is also about telling in the image data that "this
> >should be interpreted as 50% gray" so that if you view the image in a
> >different system with a different display hardware with different gamma,
> >that color will look like 50% gray there as well, and not eg. 40% or 60%
> >gray.

> I think these two paragraphs sum up a bit of a conflict: is gamma about the
> input or the output?

  It's related to mapping input values to output values. Input values are
abstract, for example "50% gray", while output values are concrete pixel
values which will show up on your screen. What the gamma value does is to
tell the hardware how to convert the input values so that they will show
up on screen correctly. This is needed because different hardwares have
different mappings between input and output.

  Most programs don't care about this mapping and skip gamma correction
altogether. In these programs if you specify, for example "50% gray", what
you will get is a pixel with color components which are exactly in the
middle of the color component range (eg. on a 24 bits-per-pixel display
it will result in a pixel with values 127,127,127). That will not produce
a 50% gray with most monitors. However, people are so used to this that
they don't even notice that the mapping is incorrect.

  POV-Ray 3.6 is, basically, such a program. POV-Ray 3.7 wants to change
that and abstract the meaning of color definitions so that "rgb 0.5" really
means "50% gray" and not "whatever your monitor will show when you use a
pixel value of 127,127,127". A proper gamma setting is the tool for that.

> If you say that it specifies how I want a pixel to appear
> on the screen, then it sure looks like it is a post-processing step after the
> color of the pixel has already been computed in the linear rgb space.

  "Post-processing" is a change done to the pixel after it has been rendered
and before it's written to the image file (or previewed on screen). Gamma
correction goes beyond that (at least for image file formats which support
gamma information): It also writes to the file information which an image
viewing program can use to correct the pixels properly before showing them
on a different hardware with a different gamma than the computer where the
image was created. This means that in different computers, with different
gamma correction settings, what ends up being sent to the display hardware
may be different pixel values, with the goal that what you see on screen
will end up looking the same (rather than darker or lighter than in the
original computer).

> An
> afterthought, if you will, to take care of the different output devices this
> pixel might be displayed on. Which is in conflict with the claim that it is
> about input conversion.

  It is about input conversion in the sense that the original data (eg. in
this case an SDL scene file) had for example "50% gray", and the gamma value
is used during the entire process of rendering and displaying in order to
make sure that it will look like "50% gray" on the screen as well. Without
this gamma correction it won't look like that.

> From this perspective, your question up there doesn't make much sense: a
> specification of "rgb 0.5" in my scene file is about the reality of a given
> object, namely that it emits half as many watts per area into some solid angle
> (given by things like specularity) as it received. This specification is
> completely unrelated to any kind of output device - an object specified as "50%
> grey" can appear on any one monitor as any one color, depending on the
> illumination of that surface by light sources and other surfaces and by the
> angle to and distance from the camera.

  Of course lighting will affect how the color ends up on the final image.
However, gamma correction makes sure that the end result will be proper,
according to the math. For example if a 50% gray color is dimmed by lighting
by half, then you want a 25% gray to show up on screen, not something else.
And gamma correction is the tool for that. Without gamma correction you won't
get 25% gray.

> The other perspective I have on POV-Ray is about art. A tool to make pretty
> images. Here I care about composition, lighting, shapes, structure, texture etc.
> The physical background goes away entirely.

> I might look at a scene and say: "That thing there looks too dark compared to
> what I am trying to achieve. I'd like to make it a little lighter". In this
> context, I could not care less what *number* there is attached to any one
> specification - like the "rgb ..." value in some pigment. If I want it lighter,
> I might increase it. Until it looks right. Or do something completely different
> like increase "ambient" or such.

  Wouldn't you want for the image to look the same in someone else's computer
as it does in yours?

  Improper (or lack of) gamma correction will not only change the brightness
of the colors, but also their hue (because if different color components have
different values, they will be affected non-linearly by the display hardware;
this means that a pixel value of eg. 192,128,64 will have a slightly different
hue with different display hardwares).

  So gamma correction *does* make a difference even from an artistic point
of view.

-- 
                                                          - Warp


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.