SRGB and SDK 0.6.0.0

The information is teased here, and then lost once you fall for that joke: "For more information, see Migrating from SDK 0.6.x to SDK 0.7..."

https://developer.oculus.com/downloads/ ... r_Windows/

It leads to no related information about SRGB! Oculus VR, could you please hire someone proof reading your documentation for the billions facebook invested? This is really not funny anymore!

I mean, 370+ reads on this thread, now answer and only one more or less active moderator doing guesswork at its best, can't be serious about that!

I don't know the answer off hand, but I bet if you look at the source code for one of the included samples (like Oculus Room Tiny), you will find your answer.

I appreciate your work, and know I have to read samples and can reverse engineer things. But documentation could be better, at least not leading to dead ends.

You should use sRGB if you are writing sRGB values. There was a bug that made it inconsistent before but it got fixed at some point recently.

I have a dark Raw-Texture, that probably is sRGB. Is remains to dark if I tell the SDK it is a normal R8R8B8A8_UNORM and is not rendered with Gamma 2.2 but 1.0. Once I request a R8R8B8A8_UNORM_SRGB texture as SwapSet, the Runtime 0.8beta (with a 0.6.0.1beta SDK in project) will perform a second sRGB transformation and render even darker with gamma < 1.0 - isn't this the opposite of how it should be? Couldn't Oculus VR hire someone to keep track of those nasty errors (or am I doing something wrong - without appropriate documentation each developer will spend days finding out).

Btw. this Forum is gloriously FU, once you login and go back to the Thread it will constantly forward you to the Login each 20sec. or something...

Any chance the text for 'For more information, see Migrating from SDK 0.6.x to SDK 0.7..." can be pasted since it's removed from the documentation? Seems like that could help a lot of people..

Here is a section of the docs that seems relevant:

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.

https://developer.oculus.com/documentat ... e-archive/

thx a lot for the link that seemed to got lost :)

So, since there is no possibility to set the

ovrSwapTextureSetD3D11_Typeless

flag in SDK 0.6.0.1beta, there is no way to remain backwards compatible form Runtime 0.8beta to Runtime 0.6.0.1beta because of sRGB. That is sad, since Runtime 0.6.0.1beta was the last one backwards compatible for old demos compiled with earlyer SDKs... but we also need to be compatible to Runtime 0.8beta since it is the only one supporting Windows 10.

My picture is perfect with Runtime 0.6.0.1beta and becomes to dark with 0.8beta. Guess my picture is in linear, and is somehow interpreted nonlinear by changes from the Runtime 0.8beta - why is everybody elses pictures to light? when I request DXGI_FORMAT_B8G8R8A8_UNORM_SRGB it becomes even darker...

btw, i think it has to be

#define GL_SRGB8_ALPHA8 0x8C43

no GL_SRGB_ALPHA8