Details
-
Bug
-
Resolution: Unresolved
-
P3: Somewhat important
-
None
-
6.4.1
-
None
-
Ubuntu 20.04 x86_64, Qt 6.4.1, Intel UHD Graphics 620
Description
I'm making a C++-based FBO renderer in a QtQuick scene. This FBO, as well as the main backbuffer, are set to be sRGB-aware. The former is configured via QOpenGLFramebufferObjectFormat::setInternalTextureFormat(GL_SRGB8_ALPHA8), while the latter is set up with QSurfaceFormat::setColorSpace(QColorSpace::SRgb).
In the rendering function QQuickFramebufferObject::Renderer::render() calls glEnable(GL_FRAMEBUFFER_SRGB), so as to enable the sRGB conversion after the fragment shader ends. The rendering works fine, i.e. the FBO gets the gamma-correct image (I checked via apitrace), but after the return from the rendering function, the QtQuick caller code disables GL_FRAMEBUFFER_SRGB unconditionally.
The result is that the window gets the gamma-incorrect (too dark) image. This happens because the FBO-attached texture has sRGB format, whose sampling always yields linear values, but the subsequent output of the QtQuick's fragment shader doesn't undergo the conversion back to sRGB format.
In the example project attached this issue is reproduced in the following way. The right half of the canvas has the reference image, made from stock Rectangle items. The left half is rendered by C++ code in sRGB mode. Ideally, the left half should look as the right one appears now, but in practice it's too dark (gamma-incorrect).