I failed to consider that premultiplied sRGB color channels can be stored two ways. The friendly way, to_srgb_gamma(color * alpha) and what applications actually use, to_srgb_gamma(color) * alpha. That might affect this proposal.
On Thu, Sep 27, 2012 at 3:49 PM, Brian Paul <bri...@vmware.com> wrote: > Just some quick comments. > > I think the term "GAMMA" should be omitted. I'm no expert but I'm not sure > that sRGB is strictly a gamma function. The GL_EXT_texture_sRGB spec says > "The sRGB color space roughly corresponds to 2.2 gamma correction." Also, > the term GAMMA doesn't appear in any of the existing GLenum values related > to sRGB. Only sRGB's gamma function is used and it is explicitly named so to avoid confusion with the whole sRGB color space. > > Therefore, I think EGL_GAMMA_SRGB_BIT should be just EGL_SRGB_BIT, > EGL_GAMMA_LINEAR -> EGL_LINEAR, > EGL_GAMMA_SRGB -> EGL_SRGB. > > For the query, you might use "COLOR_ENCODING" like > GL_ARB_framebuffer_object. You could use glGetFramebufferAttachmentParameter with GL_FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING to check if you got a sRGB framebuffer, but you can't set it. > > You could also take a look at > http://www.opengl.org/registry/specs/EXT/framebuffer_sRGB.txt to see how > this was handled for GLX and WGL. This is done similarly with a capability flag in GLX/WGL, but with the surface attribute moved into OpenGL (and it affects other rendertargets). > > -Brian > > > > On 09/26/2012 04:49 AM, John Kåre Alsaker wrote: >> >> EGL_GAMMA_SRGB_BIT should be changed to a boolean EGL config attribute >> so it can be optionally sorted by eglChooseConfig. It should be sorted >> after EGL_COLOR_BUFFER_TYPE and true values would be preferred. This >> sorting should be optional and is done so compositing window managers >> can sample the framebuffer as an sRGB texture. EGL_GAMMA_SRGB_BIT >> could also optionally be disabled when the format is not supported as >> an sRGB texture by the hardware. >> >> On Wed, Sep 26, 2012 at 10:19 AM, John Kåre Alsaker >> <john.kare.alsa...@gmail.com> wrote: >>> >>> The way this would interact with ARB_framebuffer_sRGB is that the >>> EGL's surface EGL_GAMMA attribute would be ignored. If a EGL config >>> has the EGL_GAMMA_SRGB_BIT, it is required to support sRGB for the >>> default OpenGL framebuffer. >>> >>> On Tue, Sep 25, 2012 at 5:58 PM, John Kåre Alsaker >>> <john.kare.alsa...@gmail.com> wrote: >>>> >>>> Hello, >>>> >>>> I would like add support for sRGB framebuffers to EGL. Here are my >>>> proposed changes to EGL: >>>> >>>> A new EGL_SURFACE_TYPE bit: >>>> EGL_GAMMA_SRGB_BIT - This format supports sRGB framebuffers. This also >>>> means that ARB_framebuffer_sRGB is supported for this format. >>>> >>>> New values: >>>> EGL_GAMMA_LINEAR - The gamma is linear. >>>> EGL_GAMMA_SRGB - The gamma is as defined by the sRGB standard. >>>> >>>> New EGL surface attribute: >>>> EGL_GAMMA - The gamma of the surface's framebuffer. The default value >>>> is EGL_GAMMA_LINEAR. >>>> >>>> When the surface's EGL_GAMMA attribute's value is EGL_GAMMA_SRGB and >>>> this is supported by >>>> the format, reads from this framebuffer will be converted from sRGB >>>> gamma and writes will >>>> be converted to sRGB gamma. This may not apply to all functions in the >>>> client API. >>>> >>>> There may be something related to the ARB_framebuffer_sRGB extension >>>> in EGL already, in >>>> which case someone should link me to it. >>>> >>>> There's two assumptions behind this proposal. One is that you won't >>>> support sRGB only >>>> formats. The other is that linear gamma and sRGB gamma format support >>>> is the same. >>>> This means that window systems can't add a new linear gamma format >>>> without adding an sRGB >>>> format and the other way around. >>>> >>>> I'd like some comments on this proposal and tips on how it could be >>>> implemented in the >>>> mess that is DRI. >>>> >>>> Thanks, >>>> John Kåre >> >> _______________________________________________ >> mesa-dev mailing list >> mesa-dev@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/mesa-dev > > _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
