OETF not applied for linear color buffer (causing incorrect gamma)
Note: I created a report for the same issue to SteamVR, but for some reason the report I submitted publicly is no longer public. Here's the link, maybe it works for others if logged in: https://steamcommunity.com/app/250820/discussions/8/2448217320138636173/.
Issue
Monado does not perform the required OETF on linearly encoded swapchain buffers.
This is an issue for color-managed applications, that render the scene entirely with linear encoding to a linear buffer (e.g. GL_RGBA8
), and only apply the OETF for outputs it manages itself.
Note that the OpenXR application has no idea of which displays the buffer will be drawn to, even if all HMD displays are assumed to use sRGB. E.g. the runtime may still mirror the VR view to a monitor using a different color space. Hence the runtime must be the one applying the OETF.
More concretely: Monado needs to at least transform the linear buffer to sRGB for output on HMDs. Otherwise the result is way too dark.
Steps to Reproduce
The Hello-XR OpenXR example already only uses non-sRGB buffers for OpenGL. If you compare the result to the result of WinMR or Oculus, it is noticeably darker.
Expected
A non-sRGB buffer sent to the OpenXR runtime should be rendered to screen with an OETF applied, so sRGB for practically all HMDs (afaik). The Hello-XR example should visually match what WinMR and Oculus display. The result in an HMD should also visually match regardless if a linear or an sRGB buffer was submitted. In the former case Monado should perform the transform to sRGB.
Note that WinMR used to have the same issue but fixed it. Given that SteamVR has it too, this seems like a common enough issue that should be addressed with conformance tests and less ambiguous specification wording. (I'll try to create an OpenXR report about this.)