[Mesa-dev] Adding support for sRGB framebuffers to EGL

[John Kåre Alsaker]

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 <brianp at 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.alsaker at 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.alsaker at 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 at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
>