Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Results 1 to 10 of 10

Thread: Multisample resolve is not gamma correct with FBOs

Hybrid View

  1. #1
    Junior Member Newbie
    Join Date
    Aug 2006
    Posts
    8

    Multisample resolve is not gamma correct with FBOs

    Hi,

    I tested this with both Nvidia GT200 and G80/G90 series (drivers release Forceware 177.35 & 177.41). If the rendering is done without FBOs i.e. multisampling is controlled either by the Nvidia control panel or by selecting a pixel format with a multisample buffer (ARB_multisample extension) then the AA resolve is gamma correct. The Nvidia control panel parameter "Antialiasing - Gamma correction" must be set to "on" though.

    Gamma correct means each MSAA sample is de-gammatized prior resolve and then gammatized again. Gamma correct resolve results in a much better AA quality as shown by the following screenshots of my test application (@ 8xQ - 8x pure MSAA, no CSAA):

    Gamma correct star (no FBOs):
    http://cdn-2-service.phanfare.com/images...89b9628ae6e92_5

    Gamma incorrect star (FBOs):
    http://cdn-2-service.phanfare.com/images...fac5ab20f8883_5

    The gamma incorrect version looks like being outlined black...

    The theory behind this is well explained here:
    http://www.all-in-one.ee/~dersch/gamma/gamma.html

    In addition, here is a test that "magnify" the MSAA gradient seen on the edge of a white triangle on a black background. The middle gradient band is the MSAA gradient, the upper band the expected gamma correct resolve result and the bottom band is the expected result without gamma correction.

    Gamma correct gradient (no FBOs):
    http://cdn-2-service.phanfare.com/images...02f368af83ae3_5

    Gamma incorrect gradient (FBOs):
    http://cdn-2-service.phanfare.com/images...c7b6731ecf11d_5

    From the following specification note it seems all the API is there...

    Excerpt from "EXT_framebuffer_sRGB":

    "17) How does this extension interact with multisampling?

    RESOLVED: There are no explicit interactions. However, arguably
    if the color samples for multisampling are sRGB encoded, the
    samples should be linearized before being "resolved" for display
    and then recoverted to sRGB if the output device expects sRGB
    encoded color components.

    This is really a video scan-out issue and beyond the scope
    of this extension which is focused on the rendering issues.
    However some implementation advice is provided:

    The implementation sufficiently aware of the gamma correction
    configured for the display device could decide to perform an
    sRGB-correct multisample resolve. Whether this occurs or not
    could be determined by a control panel setting or inferred by
    the application's use of this extension."

    As a result I would expect this to work in order to get a gamma correct AA resolve:

    - Render to FBO with a render buffer's internal format set to GL_SRGB8_ALPHA8_EXT (EXT_texture_sRGB - not supported for now, FBO not complete reported);
    - Enable GL_FRAMEBUFFER_SRGB_EXT for the destination FBO (EXT_framebuffer_sRGB);
    - Perform blit/resolve function.

    However it would be nice to be able to render to an higher precision formats and still be get gamma correct AA (such as RGB10_A2, R11F_G11F_B10F_EXT or GL_RGBA_FLOAT16). So it could work like this:

    - Enable GL_FRAMEBUFFER_SRGB_EXT for the source FBO (EXT_framebuffer_sRGB);
    - Enable GL_FRAMEBUFFER_SRGB_EXT for the destination FBO (EXT_framebuffer_sRGB);
    - Perform blit/resolve function.

    Is there a plan to fix this for Nvidia? Is it working on other vendors implementations?

    thanks,

    Cub

  2. #2
    Member Regular Contributor
    Join Date
    Jan 2004
    Posts
    314

    Re: Multisample resolve is not gamma correct with FBOs

    Interesting observation, but the behaviour does not necessarily sound like an error to me.

    Gamma-correction compensates for non-linearity of the display monitor and perhaps even for the user's eyes, so should be the very last step before the user sees the results. I would assume that gamma correction by default should not apply to intermediate results.
    Since you have observed that the results are correct when stuff is being rendered to the frame buffer, and not when rendered to textures, it sounds to me like this is correct behaviour.

    I can however imagine incorrect results if gamma correction is applied to the fragment output before it's written to the multisample buffer.
    Gamma correction should in my opinion be applied only to the final results in the framebuffer itself. (Which is where I disagree with some of nVidia's recommendations in the "importance of being linear" chapter in GPU GEMS 3, which suggests putting gamma correction in the fragment shader).

  3. #3
    Member Regular Contributor
    Join Date
    May 2001
    Posts
    348

    Re: Multisample resolve is not gamma correct with FBOs

    There are two completely separate concepts:
    - Correcting for the non-linear output response curve of the display device, and
    - Storing colour information in non-linear format and linearising it before performing computations.

    The former should indeed only happen in the display pipeline which sends the image to the monitor. But the latter is effectively a form of colour compression and should be performed any time colour information is written to or read from an image marked as sRGB, including texture fetch, blending, framebuffer writes, and downsampling.

    It's a shame sRGB storage is so often referred to as "gamma correction" since that's not what it is. It's a fixed encoding that takes the differences in perception of dark and light colours into account, and it only makes sense for fixed point formats such as RGB8.

    R11F_G11F_B10F_EXT or GL_RGBA_FLOAT16 should be used to store linear colours since the float representation already guarantees much higher precision for dark colours.

  4. #4
    Member Regular Contributor
    Join Date
    Jan 2004
    Posts
    314

    Re: Multisample resolve is not gamma correct with FBOs

    Confusing terminology aside, and assuming that the FBO used by Cubitus is indeed in sRGB format, the issue seems to be that the raw values are being interpolated linearly instead of being decoded first, as is probably the case with the frame buffer.

    Then I would concur with Cubitus' assessment that this is a bug. Might not be a driver-level bug though, it may well be fixed functionality in hardware.

  5. #5
    Junior Member Newbie
    Join Date
    Aug 2006
    Posts
    8

    Re: Multisample resolve is not gamma correct with FBOs

    I agree that this might not be a bug. However the API should let the application specify if linearization is needed prior MSAA samples averaging, and before storing it if the destination buffer has limited precision (fix point 8-bit or 10-bit per component). In order to keep precision when it matter the most...

    Note 1: On a GeForce card with release 177.35 & 177.41 the FBO resolve operation behave like it is without FBO if the blit/resolve destination FBO is 0 (backbuffer) i.e. linearization occur before average when the Nvidia control panel parameter "Antialiasing - Gamma correction" is set to "on". This is not a great workaround since an ugly glCopyTexImage is then needed to get back the result to texture, the FBO size is limited to window size and formats are limited to pixel formats.

    Note 2: The internal format of the render buffer is indeed GL_RGBA8 since GL_SRGB8_ALPHA8 is not allowed (FBO not complete).

    Cub

  6. #6
    Junior Member Newbie
    Join Date
    Aug 2006
    Posts
    8

    Re: Multisample resolve is not gamma correct with FBOs

    Correction: It is allowed to render to a renderbuffer with internal format set to GL_SRGB8_ALPHA8 (I did a mistake in my test) but still it does not change the end result: the AA resolve is not gamma correct.

    Cub

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •