Bug: sRGB on QuadroFX 1700

I’m currently playing a bit with sRGB-corrected rendering. So I tried WGL_ARB_framebuffer_sRGB.
Rendering sRGB to the window framebuffer is intended, so I enable GL_FRAMEBUFFER_SRGB.

In a second step I do some offscreen-rendering into a GL_RGBA8 renderbuffer. For this step I do not want sRGB rendering and GL_FRAMEBUFFER_COLOR_ATTACHMENT_ENCODING is returning GL_LINEAR like expected.
So I assume, that even though GL_GFRAMEBUFFER_SRGB is enabled, sRGB has no effect when I render into this FBO. Unfortunately, despite GL_RGBA8, sRGB rendering is still being done and my readback-results get wrong.

Also, I noticed that glClearColor() is affected by sRGB rendering. Where in the ARB_framebuffer_sRGB specs is this effect hidden?
I only found this:

  1. How is the constant blend color handled for sRGB framebuffers?
    RESOLVED: The constant blend color is specified as four floating-point values. Given that the texture border color can be specified at such high precision, it is always treated as a linear RGBA value.

(Btw, the specs erroneously refer to the texture border color!)

So I assumed that glClear is probably not affected by sRGB rendering as well… Am I wrong?

I’ve tested this on a QuadroFX1700 (266.45), WinXP64

My only experience with sRGB is under D3D, so take what I say here with the appropriately sized grain of salt.

sRGB corrected rendering is a two-step operation, thus (source: DirectX SDK):[ul][li]Indicate whether a texture is gamma 2.2 corrected or not (sRGB or not). The driver will either convert to a linear gamma for blending operations at SetTexture time, or the sampler will convert it to linear data at lookup time.[]Indicate whether the pixel pipeline should gamma correct back to sRGB space when writing out to the render target.[/ul]And also:[ul][]All other colors (clear color, material color, vertex color, etc.) are assumed to be in linear space.[/ul]So to correctly disable sRGB you’ll need to do so at both stages in the pipeline, and likewise for correctly enabling.[/li]
I’m not sure how reasonable it is to assume that the same rules apply to OpenGL though.

Unfortunately, despite GL_RGBA8, sRGB rendering is still being done and my readback-results get wrong.

How do you know that this is the case? Specifically, I’d like to see what test you used to verify this.

Also, I noticed that glClearColor() is affected by sRGB rendering. Where in the ARB_framebuffer_sRGB specs is this effect hidden?

Any RGB value you write to an sRGB framebuffer is assumed to be given in linear space and will therefore be converted to sRGB space. Clearing is just another form of writing to the framebuffer, so it applies.

I just enabled sRGB for the window framebuffer, leaving everything else untouched. I did not use sRGB textur- or renderbuffer formats yet.
In an extra pass I render into an GL_RGBA8 renderbuffer. That buffer is then read out via glReadPixels(). I require that the returned data has a specific range of values (actually, its IDs I read back)… but as soon as I enabled GL_FRAMEBUFFER_SRGB, this readback gives me wrong values and the app crashes :slight_smile:
Since my renderbuffer has no SRGB format, it should not be affected by sRGB color conversions, regardless if GL_FRAMEBUFFER_SRGB is enabled or not.

That the clear color is also converted to sRGB makes indeed sense For instance, if you set it to [0.5 0.5 0.5], you’d expect the visual effect of “half white”.
I just wish they had been more elaborate in the specs about that. Another question is, if glBlitFramebuffer does a conversion or not…

Clear is not well specified.

BlitFramebuffer clearly says that all per-fragment operations (except scissor) are ignored. sRGB conversion would fall into that category.

BlitFramebuffer clearly says that all per-fragment operations (except scissor) are ignored. sRGB conversion would fall into that category.

sRGB conversion is not a “per-fragment operation?” It’s a color conversion operation, which the spec clearly says happens during blitting between two framebuffers with different internal formats.

sRGB conversion when writing a fragment to the framebuffer is a per-fragment operation, just like depth test or blending:

Per-Fragment Operations and the Framebuffer
4.1 Per Fragment Operations
4.1.8 sRGB Conversion

and

“Blit operations bypass the fragment pipeline. The only fragment operations which affect a blit are the pixel ownership test and the scissor test.”

I read this to mean that sRGB conversion is always skipped when blitting into an sRGB framebuffer, even if FRAMEBUFFER_SRGB is enabled.

Just verified also on a GTX470, 266.58 drivers, Win7 x64.
Non-sRGB renderbuffers are affected by sRGB rendering :frowning:

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.