I guess you'll agree there's something wrong with the reflection on the 
left side...

Although artificially constructed, this scene may serve to showcase how 
raytracing computations can go wrong when ignoring gamma issues.

Left side was rendered with POV-Ray 3.6 with default settings (i.e. 
without any gamma handling), right side was rendered with POV-Ray 3.7 
defaults (i.e. full-fledged gamma handling); the only difference between 
the scenes is in the brightness of the truly-grey squares, to roughly 
preserve the percieved contrast to the black-and-white-striped squares 
as seen on the unreflected plane (just as you would have to overhaul a 
legacy scene if you want to render it with full gamma handling).

Post a reply to this message

Attachments:
Download 'gammachecker_comparison.png' (103 KB)

Preview of image 'gammachecker_comparison.png'

Why is gamma-correction correction applied to images in povray, anyway? And 
in 3.7 by default?

As I understand it, gamma correction is correction that has to be applied to 
make pictures look like they "should" - to correct luminance.

However, in order to get the appearance right, you have to gamma-correct 
your monitor and printer, too. So, if we apply gamma-correction in povray, 
we still need additional correction on printer and monitor. So why have a 
correction in povray in the first place, if it is not really neccessary. We 
still need to correct gamma later. Besides, what does look "right" is a very 
subjective matter - it even changes with age.

Is the "raw" povray output correct (in the sense of: does the output follow 
the laws of physics), or isn't it?

Does it >have< to be corrected?

Or, better put, is the left or right side of your image "correct"?

Post a reply to this message

> I guess you'll agree there's something wrong with the reflection on the 
> left side...

Nice one ;-)

Post a reply to this message

> However, in order to get the appearance right, you have to gamma-correct 
> your monitor

All monitors (all consumer ones at least) apply a gamma function to the 
incoming data before displaying it.  This is fixed, you cannot change this, 
it's just how they work (this was how CRTs worked, LCDs just copied them so 
everything looks the same as before).

This is the whole point of why you *must* "gamma correct" data before 
sending it to the monitor (that just means applying the inverse of the 
monitor gamma function, so it cancels out).

So, no, you don't need to "gamma correct" your monitor - that makes no sense 
at all.

I have no idea what printers do, but I imagine the consumer printer drivers 
try to match the print output closely to what is shown on a typical display, 
so you probably should send them a gamma corrected image too.

BTW, all images you see on the web and photos from digital cameras etc are 
already gamma corrected, so they just get sent straight to the monitor.  If 
you goal is to make the output from POV look like a photo (ie 
photorealistic) then you must therefore gamma correct before writing to the 
file.

Post a reply to this message

TC schrieb:

> Why is gamma-correction correction applied to images in povray, anyway? And 
> in 3.7 by default?
> 
> As I understand it, gamma correction is correction that has to be applied to 
> make pictures look like they "should" - to correct luminance.

Yes.

> However, in order to get the appearance right, you have to gamma-correct 
> your monitor and printer, too. So, if we apply gamma-correction in povray, 
> we still need additional correction on printer and monitor. So why have a 
> correction in povray in the first place, if it is not really neccessary. We 
> still need to correct gamma later. Besides, what does look "right" is a very 
> subjective matter - it even changes with age.

No, what looks "right" can be quantified quite well: For instance, a 
50%-intensity-grey should look exactly the same (when you squint your 
eyes a bit, or otherwise "physically blur" what your display shows) as a 
pattern of alternating black (0%) and white (100%) stripes.


> Is the "raw" povray output correct (in the sense of: does the output follow 
> the laws of physics), or isn't it?

Sort of, yes. There are some features in it that don't /exactly/ follow 
physics, but even those are designed to come as close as possible in the 
/linear/ world.

> Does it >have< to be corrected?

Yes.

The 2.2 gamma curve is much closer to the dynamics of human perception 
than linear color space; e.g. the difference between a 10%-intensity 
grey and an 11%-intensity grey is percieved as far greater than between 
a 90%-intensity grey and a 91%-intensity grey. Thus, for efficient 
storage of image data, it makes sense to "compress" brighter colors and 
instead "expand" darker colors, to make the most out of the bit depth. 
This is called "gamma encoding".

For gamma-encoded images, a color depth of 8 bits per pixel is just 
about enough to avoid visible color banding. With linear encoding on the 
other hand, a color depth depth of 12 bits per pixel or more would be 
needed to avoid banding artifacts in dark areas, while for brighter 
regions some 6 bits per pixel would suffice.

Obviously, this is not very efficient, and since high-performace RAM 
suitable for graphics card frame buffers used to be very expensive (and 
still is to some extent), while a few additional lines of software code 
are cheap, graphics hardware almost invariably used gamma encoding for 
the frame buffers. Not to mention that it also fit so well with the 
inherent gamma of CRTs, allowing both the graphics adaptor and CRT 
display electronics to be pretty simple.

Therefore, even today, output devices are /not/ calibrated to achieve 
/linear/ behavior, but to achieve some /standard/ gamma (typically 2.2 
on PC systems, though the sRGB output curve is becoming more frequent), 
which is then made known to (or silently assumed by) the image 
processing software running on the system. Most operating systems have 
either an official or at least a de-facto standard for the gamma 
encoding to be used for data submitted to the display subsystem.

Of course, the same storage efficiency applying to graphics hardware is 
of benefit for image file formats as well; for this reason, and because 
image viewing software has a much easier job if all it needs to do is 
shove the image file data into the display frame buffer, gamma encoding 
(double featuring as pre-correction, and often exclusively interpreted 
as such) has been the de-facto standard for virtually all 8-bit image 
file formats out in the wild, and is explicitly recommended for the most 
common formats nowadays.


Therefore, if POV-Ray would /not/ perform gamma pre-correction for the 
preview display, it would go against operating system conventions; and 
if it would /not/ perform gamma encoding / pre-correction for the output 
file, it would go against de-facto and recommended standards of the 
respective file format.

Note that for some file formats, POV-Ray does /not/ apply gamma 
correction, namely Radiance HDR and OpenEXR, as both formats are defined 
to encode linear light intensity data (which they can do efficiently 
because they use floating-point-like data formats).


> Or, better put, is the left or right side of your image "correct"? 

As you can see (or /should/ see, unless your display an/or your image 
viewing software is /totally/ screwed up), the left side shows a 
checkered plane, but the reflection on the sphere does not. Can this 
possibly be correct?

The right side may or may not look /perfectly/ correct, depending on 
whether your display is perfectly calibrated or not, but if it is 
/anywhere/ close to sanity, it /will/ look "much more correct" than the 
left side (that's a physical fact, not just an assumption about your 
personal visual perception).

The only thing that could mess up this "experiment" would be a system 
that ignores both color profile information and gAMA chunk present in 
the image file, /and/ instead of exhibiting just some typical random 
display gamma would happen to use linear color space. *Very* unlikely, 
unless the person in charge of the system has no clue about color 
management but thinks he/she does.

That, or you may be unable to squint your eyes; in that case, some 
peculiarities about your visual perception might kick in and spoil it 
all, but even that seems rather unlikely to me. As soon as you somehow 
physically blur the image projected by the display (which is what 
squinting your eyes does), the experiment /will/ work on every system 
that is able to display PNG files at least /roughly/ right.

Post a reply to this message

Thank you for the explanation - it surely beats wikipedia.

>> Or, better put, is the left or right side of your image "correct"?
>
> As you can see (or /should/ see, unless your display an/or your image 
> viewing software is /totally/ screwed up), the left side shows a checkered 
> plane, but the reflection on the sphere does not. Can this possibly be 
> correct?

I was referring to luminance, not to the reflection in the sphere. The 
brightness of the sky is very different, too. I meant: what is more correct 
(related to the sky) - luminence on the left or right?

Of course reflection on the left makes more sense than on the right. Is this 
a gamma-related problem or is this an error in povray?

I am having lots of problems with gamma correction on my system. At least 
there are a lot of iffy things.

Contrary to what has been posted here, my video card's driver seems to do 
some gamma correction (Nvidea). At least I can do a some gamma correcting in 
the setup. However, it is a lot of voodoo: I don't know for sure what is 
corrected and when. I really don't see any difference.

Now, I am using Corel quite a lot. Corel has a lot of colour correcting, 
too. I downloaded the proper colour-management system files for my monitor 
and my printer, respectively, but the printed result did not look much like 
the screen. The PDF-file I sent to my printer (I mean the real one, the guy 
who doesn't bother printing anything below 1000 copies ;-) did look like 
neither my printout, nor the screen.

So I did trash all colour-correcting. All set to "ignore" - from video card 
driver to Corel to printer profile and printer driver. And behold: now I get 
on my printer what I see on my TFT and the guys at the printing press 
produce something that comes close enough to what I want.

So I am a bit distrustful of colour correction, especially when it is stored 
as a kind of optional parameter in the image-file, like in PNG. Depending on 
the respective viewer / editor, gamma correction in PNG is either ignored or 
applied. If it is applied, one only can hope it is applied correctly. This 
really is a problem. Do you know which browsers support PNG 
gamma-correction?

Post a reply to this message

"scott" <sco### [at] scottcom> schrieb im Newsbeitrag 
news:4af2ed23$1@news.povray.org...

> So, no, you don't need to "gamma correct" your monitor - that makes no 
> sense at all.

Maybe. As I already posted in reply to clipka, my video card driver (Nvidia) 
allows to do gamma correcting. And Adobe has some additonal gamma 
correcting, too. And the graphics program of your choice wants to manage 
monitor color, too.

Then there is colour temperature, which can be set on most monitors. How 
does this relate to gamma?

Post a reply to this message

TC schrieb:

> Then there is colour temperature, which can be set on most monitors. How 
> does this relate to gamma? 

Maybe in some very subtle way, but I'd expect it to be dwarfed by the 
impact on color hues. Which in turn is an issue that would require 
full-fledged color management to address - which POV-Ray isn't ready for 
yet :-)

Getting gamma straight is a start. Getting color management right will 
be one step further.

Post a reply to this message

"scott" <sco### [at] scottcom> wrote:
> All monitors (all consumer ones at least) apply a gamma function to the
> incoming data before displaying it.  This is fixed, you cannot change this,
> it's just how they work (this was how CRTs worked, LCDs just copied them so
> everything looks the same as before).
>
> This is the whole point of why you *must* "gamma correct" data before
> sending it to the monitor (that just means applying the inverse of the
> monitor gamma function, so it cancels out).
>
> So, no, you don't need to "gamma correct" your monitor - that makes no sense
> at all.

I have this gamma control dialog box on my system.  I don't know whether it
applies gamma correction to the output signal, or controls the LCD itself,
though I suspect the former.

I've never seen one of these on a CRT based system, but that might well be an
artifact of history.

Post a reply to this message

Attachments:
Download 'gamma_control.png' (206 KB)

Preview of image 'gamma_control.png'

TC schrieb:
> Thank you for the explanation - it surely beats wikipedia.

Thanks :-)

> I was referring to luminance, not to the reflection in the sphere. The 
> brightness of the sky is very different, too. I meant: what is more correct 
> (related to the sky) - luminence on the left or right?

That depends on how you prefer to interpret the color values in the 
scene file.

I'd say both are wrong in this respect, because the original scene 
author tried to achieve what can be seen on the left, but due to not 
paying attention to gamma issues he ended up with parameters that result 
in the image on the right when the computations are done properly.


> Of course reflection on the left makes more sense than on the right. Is this 
> a gamma-related problem or is this an error in povray?

Whoops - are you mixing up left & right here?

It actually is a gamma-related problem, which in this case manifests 
itself at the antialiasing step.

You could, with some legitimacy, also call this a design error in the 
old POV-Ray versions (in this case 3.6 used with default parameters). It 
is /not/ possible to produce the effect seen on the left-hand side with 
POV-Ray 3.7, unless deliberately forcing it to enter 3.6-compatibility mode.


> I am having lots of problems with gamma correction on my system. At least 
> there are a lot of iffy things.

... which doesn't seem to be too uncommon, unfortunately.

> Contrary to what has been posted here, my video card's driver seems to do 
> some gamma correction (Nvidea). At least I can do a some gamma correcting in 
> the setup. However, it is a lot of voodoo: I don't know for sure what is 
> corrected and when. I really don't see any difference.

Yes, I guess I know that tool. I used it, too, to calibrate my display.

This should actually "patch" some lookup table in the graphics hardware, 
which maps 8-bit framebuffer values to values supplied to the ADC (to 
generate the analog signal for the VGA interface) or transmitted on the 
DVI interface.


> Now, I am using Corel quite a lot. Corel has a lot of colour correcting, 
> too. I downloaded the proper colour-management system files for my monitor 
> and my printer, respectively, but the printed result did not look much like 
> the screen. The PDF-file I sent to my printer (I mean the real one, the guy 
> who doesn't bother printing anything below 1000 copies ;-) did look like 
> neither my printout, nor the screen.

I guess there's some caveat here: The monitor vendor doesn't know what 
graphics card you are using, and how you set your display gamma.


> So I did trash all colour-correcting. All set to "ignore" - from video card 
> driver to Corel to printer profile and printer driver. And behold: now I get 
> on my printer what I see on my TFT and the guys at the printing press 
> produce something that comes close enough to what I want.

I guess you just have to know exactly what you're doing in order to 
benefit from color management. I for one don't, so I stick to plain old 
gamma correction for now.


> So I am a bit distrustful of colour correction, especially when it is stored 
> as a kind of optional parameter in the image-file, like in PNG. Depending on 
> the respective viewer / editor, gamma correction in PNG is either ignored or 
> applied. If it is applied, one only can hope it is applied correctly. This 
> really is a problem. Do you know which browsers support PNG 
> gamma-correction? 

You can try yourself: Just render a POV-Ray scene to PNG using the 3.7 
beta, once with File_Gamma=2.2 and once with File_Gamma=1.0.

Any software displaying both files identically (except maybe for a bit 
of color banding in the File_Gamma=1.0 version) is doing proper gamma 
handling.

Internet Explorer 8 does it right. The IC image viewer does, too, and 
Windows Explorer's image preview likewise.

Photoshop 6.0 does it wrong (but I guess current versions do a better 
job), and so does Microsoft Paint.

Post a reply to this message