GL_FRAMEBUFFER_SRGB_EXT banding problems (gamma correction)

Question

Consider the following code. imageDataf is a float*. In fact, as the code shows it consist of float4 values created by a ray tracer. Of course, the color values are in linear space and I need them gamma corrected for output on screen. So what I can do is a simple for loop with a gamma correction of 2.2 (see for loop). Also, i can use GL_FRAMEBUFFER_SRGB_EXT, which works almost correclty but has "banding" problems.

Left is using GL_FRAMEBUFFER_SRGB_EXT, right is manual gamma correction. Right picture looks perfect. There may be some difficulties to spot it on some monitors. Does anyone have a clue how to fix this problem? I would like to do gamma correction for "free" as the CPU version makes the GUI a bit laggy. Note that the actual ray tracing is done in another thread using GPU(optix) so in fact its about as fast in rendering performance.

GLboolean sRGB = GL_FALSE;
glGetBooleanv( GL_FRAMEBUFFER_SRGB_CAPABLE_EXT, &sRGB );
if (sRGB) {
    //glEnable(GL_FRAMEBUFFER_SRGB_EXT);
}

for(int i = 0; i < 768*768*4; i++)
{
    imageDataf[i] = (float)powf(imageDataf[i], 1.0f/2.2f);
}

glPixelStorei(GL_UNPACK_ALIGNMENT, 8);

glDrawPixels( static_cast<GLsizei>( buffer_width ), static_cast<GLsizei>( buffer_height ),
    GL_RGBA, GL_FLOAT, (GLvoid*)imageDataf);

//glDisable(GL_FRAMEBUFFER_SRGB_EXT);

score 3 · Accepted Answer · answered Apr 01 '13 at 13:57

When GL_FRAMEBUFFER_SRGB is enabled, this means that OpenGL will assume that the colors for a fragment are in a linear colorspace. Therefore, when it writes them to an sRGB-format image, it will convert them internally from linear to sRGB. Except... your pixels are not linear. You already converted them to a non-linear colorspace.

However, I'll assume that you simply forgot an if statement in there. I'll assume that if the framebuffer is sRGB capable, you skip the loop and upload the data directly. So instead, I'll explain why you're getting banding.

You're getting banding because the OpenGL operation you asked for does the following. For each color you specify:

Clamp the floats to the [0, 1] range.
Convert the floats to unsigned, normalized, 8-bit integers.
Generate a fragment with that unsigned, normalized, 8-bit color.
Convert the unsigned, normalized, 8-bit fragment color from linear RGB space to sRGB space and store it.

Steps 1-3 all come from the use of glDrawPixels. Your problem is step 2. You want to keep your floating-point values as floats. Yet you insist on using the fixed-function pipeline (ie: glDrawPixels), which forces a conversion from float to unsigned normalized integers.

If you uploaded your data to a float texture and used a proper fragment shader to render this texture (even just a simple gl_FragColor = texture(tex, texCoord); shader), you'd be fine. The shader pipeline uses floating-point math, not integer math. So no such conversion would occur.

In short: stop using glDrawPixels.

Of course I comment out the for loop when using GL_FRAMEBUFFER_SRGB, as should be evident from the generated image. Well, since there is no penalty for me besides slight lag in GUI i'll let the GPU be alone to do the actual ray tracing. Thanks for your help. — apartridge, Apr 01 '13 at 15:52

GL_FRAMEBUFFER_SRGB_EXT banding problems (gamma correction)

1 Answers1