Welcome to the Oculus Developer Forums!

Your participation on the forum is subject to the Oculus Code of Conduct.

In general, please be respectful and kind. If you violate the Oculus Code of Conduct, your access to the developer forums will be revoked at the discretion of Oculus staff.
New to the forums? Click here to read the How To guide. -- Developers click here.

sRGB render target issue

RouslanRouslan Posts: 8
I created an sRGB render target + view and my app clearly appears too bright in the HMD. I used:
    desc.Format = OVR_FORMAT_R8G8B8A8_UNORM_SRGB;    desc.MiscFlags = ovrTextureMisc_None;
and verified that ovr_CreateTextureSwapChainDX() returns a DXGI_FORMAT_R8G8B8A8_UNORM_SRGB texture.

Checking the Tiny Room sample, I was surprised to find that it doesn't follow the guideline from:


and creates a non-sRGB view for the sRGB render target. I am puzzled, can somebody explain what is going on?

OculusRoomTiny: main.cpp:
    bool Init(ovrSession session, int sizeW, int sizeH)    {        Session = session;
        ovrTextureSwapChainDesc desc = {};        desc.Type = ovrTexture_2D;        desc.ArraySize = 1;        desc.Format = OVR_FORMAT_R8G8B8A8_UNORM_SRGB;        desc.Width = sizeW;        desc.Height = sizeH;        desc.MipLevels = 1;        desc.SampleCount = 1;        desc.MiscFlags = ovrTextureMisc_DX_Typeless;        desc.BindFlags = ovrTextureBind_DX_RenderTarget;        desc.StaticImage = ovrFalse;
        ovrResult result = ovr_CreateTextureSwapChainDX(session, DIRECTX.Device, &desc, &TextureChain);        if (!OVR_SUCCESS(result))            return false;
        int textureCount = 0;        ovr_GetTextureSwapChainLength(Session, TextureChain, &textureCount);        for (int i = 0; i < textureCount; ++i)        {            ID3D11Texture2D* tex = nullptr;            ovr_GetTextureSwapChainBufferDX(Session, TextureChain, i, IID_PPV_ARGS(&tex));            D3D11_RENDER_TARGET_VIEW_DESC rtvd = {};            rtvd.Format = DXGI_FORMAT_R8G8B8A8_UNORM;            rtvd.ViewDimension = D3D11_RTV_DIMENSION_TEXTURE2D;            ID3D11RenderTargetView* rtv;            DIRECTX.Device->CreateRenderTargetView(tex, &rtvd, &rtv);            TexRtv.push_back(rtv);            tex->Release();        }
        return true;    }


  • imperativityimperativity Posts: 3,587 Valuable Player

    I am forwarding your query on to the PC SDK team for their input.

    I will update this thread when I have more information to share.
  • imperativityimperativity Posts: 3,587 Valuable Player

    Here is some in-depth commentary on the behavior you are encountering with sRGB render targettng:

    "The reason our ORT code does what it does is because the ORT shader outputting the colors is writing out sRGB-ready values meaning it doesn't want the GPU's blender unit (also referred to as the Raster Operator or ROPs) to do the linear-to-sRGB conversion. Normally the ROPs do the linear-to-sRGB conversion on output when the render target view format is set to sRGB. By setting the format to non-SRGB (or linear) this leaves the burden to do the linear-to-sRGB conversion to the shader code. Arguably not recommended.

    This is also why ORT uses the typeless flag which allows one to create a texture in one format and then switch the format in the Shader Resource View (SRV) or Render Target View (RTV). By creating an sRGB format texture using the Create Texture SDK call, and then switching the format to be linear for the RTV, it works around the GPU's sRGB converter to be handled by the shader. However, since the texture was originally created as sRGB, the Oculus compositor using this texture will treat the texture as sRGB upon sampling the texture. This helps avoid the compositor shaders from having to do any sRGB-to-linear conversions as the SRV format used in the texture sampler will handle the conversion.

    I admit this can be confusing and also hard to explain in simple words especially if you have no exposure to gamma conversions and linear rendering etc. in modern GPUs.

    I think Ed has an open task to fix our ORT sample code to make sure they're all doing the same thing, and preferably avoiding this bit of code as it can be hard to understand and "hard to understand" code shouldn't have any place in our ORT sample."
Sign In or Register to comment.