sRGB findings on various platforms
MarijnS95 opened this issue Β· comments
For the past while I've been working on and off on turning the current sRGB colorspace support into full-fledged color space support, with a focus on EGL (Wayland desktop and Android phones). As it turns out there are quite a few backend differences that only make this feasible for the EGL backend. But before we get into some design questions I'd like to ask (separate issue), let's first look at sRGB as every backend and implementation has already gotten me totally confused. This is not really a Glutin issue but more of a general OpenGL ecosystem mess, though it might definitely be relevant to keep our implementation and documentation in check so I'm sharing it anyway.
The following was tested on a:
- Sony Xperia 1IV;
- RX 6800 Sway (ArchLinux);
- Intel UHD 620 on Sway;
- RX 6800 XT on Windows.
Preface
GL_FRAMEBUFFER_SRGB
is a feature that performs linear->sRGB conversion when writing to sRGB textures / framebuffers. It has no effect when the target is already linear (or so it is documented...);- This color space is queried using
FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING
; - I think support for
GL_FRAMEBUFFER_SRGB
is what is queried/filtered viaFRAMEBUFFER_SRGB_CAPABLE_*
on WGL and GLX. Though it works regardless if it is not capable (??); - For X11 there is no way to configure a color space via GLX. Perhaps this can be set on a window beforehand?
Android EGL
- Default color space is linear;
GL_FRAMEBUFFER_SRGB
(automatic linear->srgb conversion when writing to an srgb framebuffer) is on by default;- Querying
FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING
is not supported (it's GLES 3.2 though...); - Changing the color space via
EGL_GL_COLORSPACE
toEGL_GL_COLORSPACE_SRGB
appropriately uses the defaultFRAMEBUFFER_SRGB
conversion, the image is now brighter;- The image stays at the original darker color when in
GL_COLORSPACE_SRGB
withgl.Disable(gl::FRAMEBUFFER_SRGB)
.
- The image stays at the original darker color when in
π, all working as expected.
Wayland EGL (AMD Mesa)
GL_SRGB
is always reported byFRAMEBUFFER_ATTACHMENT_COLOR_ENCODING
;- Changing the color space via
EGL_GL_COLORSPACE
makes no difference (color stays the same,COLOR_ENCODING
always returnsGL_SRGB
); GL_FRAMEBUFFER_SRGB
is off by default;- Enabling
GL_FRAMEBUFFER_SRGB
always makes the image brighter (makes sense given that the framebuffer is always considered to be inGL_SRGB
colorspace); - The
EGL_(GL_)COLORSPACE
attributes follow which color is being set inCreatePlatformWindowSurface*
.
Wayland EGL (AMD ProGL)
(using progl
command)
- Default color space is
GL_LINEAR
according toFRAMEBUFFER_ATTACHMENT_COLOR_ENCODING
; EGL_COLORSPACE
isEGL_GL_COLORSPACE_SRGB
, butEGL_GL_COLORSPACE
isEGL_GL_COLORSPACE_LINEAR
;- Setting
EGL_COLORSPACE
has no effect; - Setting
EGL_GL_COLORSPACE
toSRGB
correctly makesCOLOR_ENCODING
returnGL_SRGB
;- Turning on
GL_FRAMEBUFFER_SRGB
makes the image brighter (only when the color encoding is sRGB π).
- Turning on
X11 (AMD Mesa)
COLOR_ENCODING
is alwaysGL_SRGB
;- Alternating configs are sRGB-capable;
GL_FRAMEBUFFER_SRGB
makes the output lighter on every config (even those that are not "sRGB capable").
X11 (AMD ProGL)
COLOR_ENCODING
always reportsGL_LINEAR
;- No config is "sRGB-capable" (??);
- Enabling
GL_FRAMEBUFFER_SRGB
makes the output bright (this should not be the case for linear framebuffers?!).
Wayland EGL (Intel UHD 620 on Mesa)
FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING
is alwaysGL_SRGB
;EGL_COLORSPACE
isEGL_COLORSPACE_SRGB
, whileEGL_GL_COLORSPACE
isEGL_COLORSPACE_LINEAR
;- Changing either of these has no effect on
COLOR_ENCODING
;
- Changing either of these has no effect on
- Enabling
GL_FRAMEBUFFER_SRGB
always makes the image brighter (as expected forCOLOR_ENCODING
=GL_SRGB
).
X11 (Intel UHD 620 on Mesa)
- Also alternating configs which are "sRGB-capable";
- On all configs
COLOR_ENCODING
isGL_SRGB
; FRAMEBUFFER_SRGB
is disabled by default, but enabling it always makes the image brighter.
Windows (RX 6800 XT)
COLOR_ENCODING
isGL_LINEAR
;GL_FRAMEBUFFER_SRGB
is disabled;- Enabling
GL_FRAMEBUFFER_SRGB
makes the image brighter (again, weird for alinear
color encoding...); - All configs are sRGB-capable;
WGL_EXT_colorspace
is not in the list of supported extensions;- As expected, querying
WGL_COLORSPACE_EXT
viawglGetPixelFormatAttribivARB()
always fails; - However, setting
WGL_COLORSPACE_EXT
toWGL_COLORSPACE_SRGB_EXT
viawglChoosePixelFormatARB()
:- Makes
COLOR_ENCODING
returnGL_SRGB
π; - Makes the image darker π;
- Enabling
GL_FRAMEBUFFER_SRGB
gets the image back to normal colors π. - Very nice (especially that the image gets darker, means the compositor actually interprets the data differently as we expect...), but super confusing once again.
- Makes
Changing the color space via EGL_GL_COLORSPACE makes no difference (color stays the same, COLOR_ENCODING always returns GL_SRGB);
SRGB setting in EGL is mostly when you're dealing with GLES context and not OpenGL from what I understand, because you can't manipulate with attachment function in OpenGL.
Setting EGL_COLORSPACE has no effect
It should have it with gles context..
I'm not that familiar with real OpenGL use.
SRGB setting in EGL is mostly when you're dealing with GLES context and not OpenGL from what I understand, because you can't manipulate with attachment function in OpenGL.
Should be available on both afaik: https://registry.khronos.org/EGL/extensions/EXT/EGL_EXT_image_gl_colorspace.txt
Setting EGL_COLORSPACE has no effect
It should have it with gles context..
I'm not that familiar with real OpenGL use.
Oh no, more variables; maybe I should retest this all again and put the results in a big table that's a bit more clear. More on that later.
Replying to the rest of your sRGB comments from #1653 (comment) here:
There does not seem to be a way to query which color spaces a certain config/surface supports, [..]
This is present because some platform determine the framebuffer type at the surface/context creation time and you can't switch at runtime.
Do you imply from *FRAMEBUFFER_SRGB_CAPABLE_ARB/EXT
that the framebuffer must be an SRGB texture? Renderdoc seems to agree with that thought but https://registry.khronos.org/OpenGL/extensions/ARB/ARB_framebuffer_sRGB.txt seems to suggest that it only exposes whether sRGB blending/conversion is available (which only makes sense on sRGB surfaces, so implying that it's sRGB)?
As outlined in this issue that sRGB blending/conversion seems to be applied to non-sRGB-capable configs. And COLOR_ENCODING
is not always representing the actual value of a texture. Do you think I am querying it correctly?
gl.GetFramebufferAttachmentParameteriv(
gl::FRAMEBUFFER,
gl::FRONT,
gl::FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING,
&mut ce
);
Basically GLES and that's why we have those checks, mostly. Since when you have OpenGL context you don't have
GL_ARB_framebuffer_sRGB
.
Isn't it the other way around? GL_ARB_framebuffer_sRGB
is in the OpenGL extensions but not in ES. They have https://registry.khronos.org/OpenGL/extensions/EXT/EXT_sRGB.txt and https://registry.khronos.org/OpenGL/extensions/EXT/EXT_sRGB_write_control.txt.
After all I also had to switch gl_generator
from Api::Gles
to Api::Gl
to use that extension and get the constant for FRAMEBUFFER_SRGB
.
Should be available on both afaik
Hm, I know that with gles you can't change buffer colorspace at runtime, at least with gles2, maybe you can with gles3. It should be testable if you pick ES context and play with srgb on a surface, though, you likely did that already.
Do you imply from *FRAMEBUFFER_SRGB_CAPABLE_ARB/EXT that the framebuffer must be an SRGB texture?
Not sure what you mean. I was saying that some platforms define buffer type at surface creation, e.g. EGLSurface with gles2 context. That's the only reason we have sRGB API on a surface creation.
Hm, I know that with gles you can't change buffer colorspace at runtime, at least with gles2, maybe you can with gles3. It should be testable if you pick ES context and play with srgb on a surface, though, you likely did that already.
I can get an ES 3.2 and OpenGL 4.6 context on the RX 6800 XT from Mesa. Via Wayland EGL, on OpenGL 4.6, as above FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING
always returns GL_SRGB
. However, renderdoc says that it is R8G8B8A8_UNORM
as opposed to _SRGB
when I set EGL_GL_COLORSPACE
to GL_COLORSPACE_LINEAR
. GL_FRAMEBUFFER_SRGB
always facilitates a conversion though, the image looks the same regardless of the colorspace.
(Maybe I am reading FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING
from the wrong place?)
On GLES3 on the same Mesa driver it works better: the linear->sRGB conversion only happens when I set EGL_GL_COLORSPACE
to EGL_COLORSPACE_sRGB
. Renderdoc also confirms SRGB
vs UNORM
as texture format.
On GLX on this Mesa driver I get identical behaviour.
Not sure what you mean. I was saying that some platforms define buffer type at surface creation, e.g. EGLSurface with gles2 context. That's the only reason we have sRGB API on a surface creation.
Only EGL does this, WGL has a way to set it on the config, GLX doesn't expose any parameters.
I think I should leave this here and focus on EGL colorspace support, instead of messing with broken sRGB support :)
https://registry.khronos.org/EGL/specs/eglspec.1.5.pdf
Only OpenGL and OpenGL ES contexts which support sRGB rendering must respect requests
forEGL_GL_COLORSPACE_SRGB
, and only to sRGB formats supported by the context (normally just SRGB8) Older versions not supporting sRGB rendering will ignore this surface attribute.
Applications using OpenGL must additionally enableGL_FRAMEBUFFER_SRGB
to perform
sRGB rendering, even when an sRGB surface is bound; this enable is not required (or supported)
for OpenGL ES.
Strange because I need that flag on ES to get sRGB conversion working π