"Bald Eagle" <cre### [at] netscapenet> wrote:

>
> Kenneth Walker is now appointed as the Maintainer of the Gamma, and The
> Commission anxiously awaits his proffered essay....
>
> :P

Hmm, a dubious distinction :-0

OK, you asked for it. But gamma is such a tricky and complex subject that I may
come across as either sounding like a genius, or sounding  like an idiot. :P
There are aspects of this business that still puzzle me, and I have left out a
lot of extraneous details; but this is how I see it so far. (And this is the
SHORT-version, ha.) I await judgement ;-)

I'll concentrate on the RGB-to-SRGB conversion formula. I 'borrowed' a diagram
from the NVIDIA article and posted it here, to help explain things (it should be
on the Wikipedia page too, which would go a long way to explain the actual
intended use of the equations there.)

In a nutshell:

Our computers/monitors have an intrinsic built-in  'gamma' of generally around
2.2. That computer gamma is the curved "CRT gamma line" in the diagram. The
straight line represents color values fed to the display.

When we save an image in POV-ray (i.e., the rendered image), it contains
*linear* image data, but with a gamma chunk to tell the computer what to do with
it-- either 2.2 (automatic for older versions) or, for v3.7xx-3.8xx, either 2.2
or srgb by way of the newer File_Gamma keyword in our .ini file.  (These gamma
chunks are possibly the 'inverse' of the values, but that's too much technical
detail for this discussion.)

The RGB-to-SRGB conversion equation as-is on the Wikipedia page (and elsewhere)
refers to this image-ENCODING gamma-- the gamma chunk-- when an image is finally
sent to the computer/monitor for display. The surprise (as regards POV-ray's use
of the SRGB keyword for colors) is that the equation actually 'brightens'  the
image values, to prepare them for the counter- 'gamma-bending' by the computer's
intrinsic 2.2 gamma-- so that their final perceptual appearance is once again
along  the straight line. These gamma-encoded values are represented by the
dashed line in the diagram.

This is what the equation itself is meant to do-- it's for gamma-ENCODING an
image.  But that's the *opposite* of what we want it to do **within POV-ray**;
we want to take a too-bright linear RGB color there -- say, 50% gray, which
*appears* too bright in our assumed_gamma 1.0 world-- and *darken* it to look
perceptually correct in our preview render.

So, the 'opposite' SRGB-to-RGB equation on the page is the one to use, even
though that seems counter-intuitive.

Using POV-ray's assumed_gamma 1.0 in a scene is like having a self-contained
'box' in the computer with its own 'linear gamma atmosphere' of 1.0, sealed off
from the computer's gamma 2.2  environment. We work within that box, visually
and computationally.  Now, because *linear* RGB color values in such an
environment look kind of washed-out to our own eyes, we need a way within
POV-ray to mimic the surrounding gamma-2.2 world-- not by using assumed_gamma
2.2 there (for subtle computational reasons), but with SRGB colors. Of course,
you *could* use linear colors along with assumed_gamma 1.0, and simply tweak the
visual results to your liking in the preview-- using 22% gray instead of 50% so
that it 'looks' correct as middle-gray-- but most if not all other image-making
programs don't operate in a gamma 1.0 environment like that; we are simply used
to the visual preview results of, say, 50% linear gray automatically looking
like 22%. Working with colors is just easier this way-- we can specify srgb and
'get' 22%, which is perceptually midway between black and white.

For older versions of POV-ray without the srgb color keyword, setting
assumed_gamma to 2.2 was an expedient way around this, but with its own mess of
subtle problems as to internal computations.

Post a reply to this message

Attachments:
Download 'gamma_slopes_image.jpg' (56 KB)

Preview of image 'gamma_slopes_image.jpg'