One thing I never used to pay attention to is gamma correction. This is mainly because it rarely gets mentioned, and also because you can usually get pretty good results without ever even thinking about it. However it only took a few days at my new job for me to realize just how essential it is if you want professional-quality results.
Lately I’ve been doing some research into inferred rendering (more on that later), and while working up a prototype renderer in XNA I decided that I would (for once) be gamma-correct throughout the pipeline. So I went looking through the XNA Framework documentation for framework’s equvalent of the D3DSAMP_SRGBTEXTURE sampler state (which automatically converts from sRGB to linear in the texture unit) and the D3DRS_SRGBWRITEENABLE render state (which automatically converts from linear to sRGB in the ROP)…and I didn’t find them. The thought of these being left out struck me as odd, so I did a bit of searching on Google. After refining my search terms I found this post by framework developer Shawn Hargreaves, confirming that those states were not exposed in the framework due to inconsistencies between Windows and Xbox. After looking through some presentations again I concluded that he was talking about…
1. The fact that the 360 uses a 4-segment piecewise linear approximation curve to perform conversion to and from sRGB, which gives quite different results compared to what you get with PC GPU’s.
2. The fact that blending behavior is different in DX9 and DX10-level GPU’s, regardless of which API you use. DX9 GPU’s will perform framebuffer blending after conversion to sRGB (which is mathematically incorrect), while DX10 GPU’s will do the blending in linear space and then convert the blended result to sRGB. There is a cap to detect this behavior (D3DPMISCCAPS_POSTBLENDSRGBCONVERT) but it’s only available if you create an IDirect3D9Ex device.
So yeah, that’s annoying. But like most limitations in the framework you can work around them if you’re determined enough, and fortunately this one is a piece of cake. Well…on the PC, at least. So let’s start with the first half, sampling sRGB textures. Like I mentioned before there’s a nice convenient sampler state in D3D9 that will do the sRGB->linear automatically, but XNA’s SamplerState just doesn’t have it. But fortunately that’s not the only way to set sampler states…we can also get the Effects framework to do it for us by defining a sampler_state in our effect files. So I took a peek at the D3D9 Effect States documentation, and added the appropriate state declaration to my effect file. And it worked! For the lazy, all you have to do is this (important line in bold):
texture2D DiffuseMap;
sampler2D DiffuseSampler = sampler_state
{
Texture = <DiffuseMap>;
SRGBTexture = true;
};
Okay now for the other half, sRGB writes. Once again D3D9 has a convenient render state that does all of the work for us, and the Effects framework can set render states for us if we include them in a pass declaration. But unfortunately this time the Effect States documentation didn’t have anything for SRGBWRITEENABLE. Too determined to give up, I followed the standard convention of effect states and chopped the prefix off the “D3DRS_” prefix. And hey, it worked!
technique Transparent
{
pass Pass1
{
VertexShader = compile vs_3_0 TransparentVS();
PixelShader = compile ps_3_0 TransparentPS();
SRGBWriteEnable = true;
}
}
So we’ve solved our gamma problems…at least if you’re only targeting the PC and you’re using Effects. If you’re not using Effects, then I don’t know of any way to toggle those states. It’s probably possible with some sort of interop/reflection voodoo, but I don’t know enough about these things to recommend it.
There’s also the Xbox 360 problem, which is actually two problems in one. The first problem is that the Xbox 360 doesn’t use sampler and render states to control sRGB read and writes. It instead uses the D3D10 convention of having special surface formats for textures and render targets that control whether conversion takes place. I don’t have access to my Xbox 360 at the moment so I can’t verify for sure, but I strongly suspect that the effect states won’t work. And even if they did work you’d still have the second problem, which is that the Xbox uses that piecewise approximation curve (this presentation by Valve shows some of the nastiness that can occur with it).
Fortunately we can bypass those problems by doing the conversion ourselves in the shader. The good news is that the code is a piece of cake…the bad news is that it’s not super cheap since it involves raising your RGB color value to a non-integral power. Here’s the code:
// Converts from linear RGB space to sRGB.
float3 LinearToSRGB(in float3 color)
{
return pow(color, 1/2.2f);
}
// Converts from sRGB space to linear RGB.
float3 SRGBToLinear(in float3 color)
{
return pow(color, 2.2f);
}
Unfortunately with these you also have the problem that filtering and blending will be performed in sRGB space, and there’s not much you can do about that (aside from doing the filtering and blending yourself, but that would be way too expensive).
If you want to make these conversions a little cheaper, you can use a trick that my coworker showed me: round down the 2.2 to 2.0. This gives you a simple square operation for conversion to linear (you can just dot the value with itself), and a sqrt operation for conversion to sRGB.
