Warp wrote:
> 
>   Then why do all other image formats look the same with the viewer
> programs as how povray shows them? Why is PNG the only format that
> makes a difference? Why can't povray create the PNG in the same way
> as it creates the other, non-problematic image formats (IOW. without
> gamma info stored in it)?
> 
>   Why does the PNG need the gamma info? The other formats don't, and
> they work just ok. PNG is the only one which presents problems when
> the gamma info *is* included. How about not including it at all?
> 

After reading a fair bit about gamma on the web during the years I think 
I have a good grasp of it and can answer some questions.

First answering Warp:

If you create an image in windows (gamma 2.2) and save it as JPEG and 
PNG and send whose to your friend who owns a mac (gamma 1.8) the JPEG 
will look wrong while the PNG will look exactly as you intended (thanks 
to the stored gamma info). This assumes that both systems use programs 
that use gamma information as they should and that both system are 
configured correctly.

More general discussion about gamma:

Gamma is a way to compensate for the non-linearity of the monitor (due 
to the properties of the phosphor and electron gun). To get black you 
output the value 0.0 (0) and to get white you output 1.0 (255), so far 
so good. But to get something which look like 50% gray you don't output 
0.5 (128), you output 0.73 (187) which is 0.5^(1/2.2), that is the gamma 
correction. The non-linear transfer function of the monitor is
  brightness = value ^ 2.2
and that takes the value 0.73 back to 50% gray as expected.
The above paragraph assumes gamma 2.2.

To make the whole thing more complicated, calculations on color values 
(such as ray-tracing, filtering, image transformation with 
anti-aliasing) should be done in linear color space (gamma 1.0) or 
errors such as hue shifts will occur. That is why povray uses gamma 1.0 
in all calculation and does the correction when it saves the image to a 
file (or rather, I hope that's what 3.7 does, I does right?).

To see why calculations should be done in gamma 1.0 consider the task of 
averaging two pixels, one black and one white, in a gamma 2.2 color space:
  (0.0 + 1.0) / 2 = 0.5
If you just send this to the monitor you get a pixel that looks 22% gray 
(0.5^2.2) and not 50% gray as you would expect. If the pixels are 
colored it gets even worse, say one medium red (50% red) and one yellow 
(100% red and green):
  50% red in gamma 2.2 is 0.73
  red:   (0.73 + 1.0) / 2 = 0.86
  green: (0.0 + 1.0) / 2 = 0.5
  blue:  (0.0 + 0.0) / 2 = 0.0
If you send that to the monitor it will look like 73% red, 22% green, 0% 
blue. The expected values are 75% red, 50% green, 0% blue. The gamma 2.2 
calculation yields a too dark color with a hue that is too much red.

In short:
For correctly configured systems, do calculation in gamma 1.0 and save 
with any gamma in a file format that store the gamma (such as PNG). This 
will always look as intended as long as the viewing program uses the 
gamma information (this is how it should be in a perfect world).
For systems that may have programs that don't do gamma right, do 
calculation in gamma 1.0 and save with the gamma of your target audience 
in a format that *don't* store gamma. This will look right only if the 
user viewing the image has a system with the gamma you used else it will 
look wrong.

I hope this was understandable and that it answered a few question 
people have about gamma.

-- 
Daniel Nilsson

Post a reply to this message