Khronos Public Bugzilla
Bug 359 - EXT_framebuffer_sRGB needs updates for glClear & glAccum; so does core
EXT_framebuffer_sRGB needs updates for glClear & glAccum; so does core
Status: RESOLVED FIXED
Product: OpenGL
Classification: Unclassified
Component: API Specification
3.0
All All
: P3 normal
: ---
Assigned To: Mark Kilgard
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-09-16 13:42 PDT by Mark Kilgard
Modified: 2013-07-11 01:15 PDT (History)
1 user (show)

See Also:


Attachments
updated EXT_framebuffer_sRGB specification (28.76 KB, text/plain)
2010-09-16 13:42 PDT, Mark Kilgard
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mark Kilgard 2010-09-16 13:42:20 PDT
Created attachment 54 [details]
updated EXT_framebuffer_sRGB specification

Jon,

The EXT_framebuffer_sRGB specification fails to address the behavior of an sRGB framebuffer with respect to clears and accumulation buffer operations.

In short, when you clear a color buffer with sRGB enabled, the clear color value should be considered a linear RGB value (which should be converted to sRGB for clearing the sRGB framebuffer.  This behavior is consistent with DirectX 9, 10, and 11 and NVIDIA's shipping behavior.

I hope these changes are uncontroversial.  I've not assessed what other non-NVIDIA implementations do.  For applications that clear to white, black, or some other fully saturated color (1,0,0 for red for example), there's no difference.  This only matters when the clear color's sRGB and linear form are different.

Likewise, the accumulation buffer performs linear operations so it is important to convert colors from an sRGB-enabled framebuffer to linear RGB values on ACCUM or LOAD operations and converted back to sRGB on RETURN operations.

NVIDIA's driver currently doesn't implement the proper sRGB conversions for the accumulation buffer, but it really is the "right thing" to do.  Because there is leeway in the specification for how the sRGB conversion is approximated, an identity conversion could be considered a valid implementation though someone truly expecting to work in an sRGB color space would be disappointed by the accumulation buffer not respecting sRGB.

It is simply an oversight (mine) that these interactions were not properly addressed.

Because EXT_framebuffer_sRGB's functionality was integrated into OpenGL 3.0, it is important that the changes (edited appropriately) should be made to the core specification.

I'm aware of no applications that would be adversely affected by this clarification/fix to the specifications.

I'm attaching an updated EXT_framebuffer_sRGB specification for discussion.

- Mark
Comment 1 Jon Leech 2010-09-24 16:43:39 PDT
We talked about this in ES and ARB F2F meetings. ES had noted that there
are also potential interactions with BlitFramebuffer, CopyTexImage,
and CopyTexSubImage, in addition to Clear & Accum. We would like to see
you evaluate these and further update the spec, or note why it
doesn't need to be updated, and then hold an ARB vote to pull these
updates into ARB/core versions of the functionality.

As far as the EXT version, since Apple and NVIDIA are the listed authors
who are shipping GL drivers, it seemed like you just need to get Apple's
signoff to update the EXT - the process above is for moving the fixes
into the Khronos-controlled specs.
Comment 2 Jon Leech 2013-05-07 15:19:46 PDT
Hi Mark,
We went through this for the ARB and GL core specs and eventually arrived
at a set of resolutions slightly different than proposed for the EXT. But
I realized just now that we never updated the EXT in the registry. I think
where we last left this was that Apple probably ought to sign off on your
proposed EXT updates since they are listed as a co-author. If they're OK
with it then I will just update the spec in the registry as you suggest.
Or if we should let this drop at this point, please close the bug.
Comment 3 Jon Leech 2013-07-11 01:15:10 PDT
I see that Apple actually was listed in the updated EXT spec as having
signed off on the changes, which was the one thing I was unclear about.
So the registry has been updated, per bug 360.