Here's a little story about gamma, texture preprocessors, and HDR rendering...



So, as most graphics people hopefully already know by now, when rendering images you need to take the monitor gamma into account. This gamma was a defect on old CRT monitors, which for compatibility is being emulated by modern LCDs, so we're stuck with it. While building my HDR pipeline for The Project(tm), I'm taking care of doing computations in gamma space or in linear space as needed.

Now, I'm programming on my PC, which has a HP LP2475w connected to it, an awesome 24" LCD which out of the box looks great, except it's a bit too bright (so I lowered that) and oversaturated (at some point I'll have to calibrate I guess). Now look at the following test pattern:



The background is a checkerboard -- alternating white and black squares. Seen from this distance, it looks like a 50% grey solid fill (minus some moiree and gradients from taking the photo).

In front of this, on the left, you have a little square, which is filled up with (128, 128, 128). This is the classic mistake: you just add up black and white to end up with 50% grey, and expect this to look the same as the background. As you can see, it clearly stands out as too dark.

Also in front, but on the right, there's another square. It's filled with 50% grey that is gamma adjusted. As you can see, or cannot see, it blends in with the background very well, so this is the right thing to do. So far so good.


Then I was rather surprised to discover that the same setup looks like this on my Dell XPS M1730 laptop:



Clearly, the "correct" square does not blend in with the background at all; in fact, it's way too bright (or dark?). This means that 2.2-gamma-adjusted values are not "bumped down (up?)" enough by the screen to become linear again. I played a bit with the NVidia control panel but couldn't easily find a mix of the six or so sliders to resolve this.

So that means a couple of things:

1. when doing gamma sensitive work, double-check your screen first with a setup like this. If I had worked on the dell, I might have been chasing a "math bug" which is just the screen playing tricks;

2. perhaps the video card needs to be checked, too. I'm blaming the screen here, but incidentally the PC is an ATI (-4780), but the laptop is NVidia (-8800). Maybe not so much the hardware, but drivers and their default settings could matter.

3. in case it wasn't obvious yet, this stuff really matters; simply averaging values (the left square) clearly darkens this scene, your mipmaps, filtered rendertargets, blended postprocessing, etc.

4. beware your tools. Both photoshop CS3 and the DirectX Texture Tool produce the left square when viewing a checkerboard at 50% zoom. In other words, assume tools are gamma-oblivious.


Note that although this is not a story about colorspace settings when processing photos, the basic problem is the same (knowing in what space you are and making sure you stay in it).


On a side note, all my photo processing has been done on the laptop.... which means I've been tweaking my pics for a screen with not enough / too much contrast, meaning they might all be a bit overdone in that department. Now I'm scared to look at them on something more 2.2-ish, I might discover I have 4 years worth of over-shopped shots :\ The good news is that most user screens are probably out of whack too, anyway.