SRGB and SDK 0.6.0.0

Migration: Compositor and sRGB/Gamma Correctness

Prior to Oculus SDK 0.7, the Oculus compositor treated all eye texture formats as sRGB color textures, even when marked otherwise. As a result, when applications provided sRGB-correct textures (e.g. DXGI_FORMAT_R8G8B8A8_UNORM_SRGB and GL_SRGB_ALPHA8), the results would look wrong. The compositor now requires all provided textures to be labelled with correct sRGB format. If an application uses an eye texture format such as DXGI_FORMAT_R8G8B8A8_UNORM, this will cause the results in the HMD display to look too bright even though the mirror texture visible on the desktop window might look normal.

There are a few ways to address this, but we will describe two of them. The first ensures that the application and Oculus compositor correctly manage sRGB. The second is for existing applications that want to make the fewest rendering changes.

Note: Oculus strongly recommends that you don't simply apply pow(2.2) in the shader that writes into an 8-bit eye texture. While the results in the final HMD output might look right initially, there will be significant luminance-banding issues that only show up under subtle visual situations.
The recommended method requires you to render in an sRGB-correct fashion, and then set the texture format accordingly. For D3D11, most applications use DXGI_FORMAT_R8G8B8A8_UNORM_SRGB instead of DXGI_FORMAT_R8G8B8A8_UNORM. For OpenGL, the correct format is GL_SRGB_ALPHA8, but you have to make sure that the application calls glEnable(GL_FRAMEBUFFER_SRGB).

In some cases, making an existing application sRGB-correct might not be straightforward. There are some implications, including sRGB-correct diffuse texture sampling, linear-space and energy-conserving shading, and GPU-accelerated gamma read/write technology that are available in any modern GPU. We expect some applications that are gamma-correct do not rely on GPU read/write conversions and have opted to handle the conversions via shader math such as applying pow(2.2) and its inverse. This approach requires some finesse which is explained in the second method.

Although not recommended, the least resistance method allows the application to keep its rendering as-is while only modifying the calls to ovr_CreateSwapTextureSetD3D11() for D3D11 rendering or modifying the GL context state for OpenGL rendering.

Since each render API requires different approaches, a detailed explanation is provided in the function declarations of both ovr_CreateSwapTextureSetD3D11() and ovr_CreateSwapTextureSetGL() in OVR_CAPI_D3D.h and OVR_CAPI_GL.h respectively. For this purpose and other potential uses, we introduced a ovrSwapTextureSetD3D11_Typeless flag for D3D11 that allows the application to create DXGI-specific typeless textures that can have a ShaderResourceView that does not have to be the same as the RenderTargetView. Keep in mind that this also applies as a mirror texture creation flag. For OpenGL, the application can simply drop the glEnable(GL_FRAMEBUFFER_SRGB) while still creating a swap texture set with the format GL_SRGB_ALPHA8.

For more information, refer to the "Swap Texture Set Initialization" section and the code samples provided in the SDK.