Color management on EGL Wayland platform

[ppaalanen]

We are developing a color-management Wayland protocol extension, and expect EGL implementations to use it on behalf of the application, because EGL already defines the extensions to do so. We need to define the rules how that works in EGL_KHR_platform_wayland.

The relevant existing extensions that should feed into color-management are:

• EXT_gl_colorspace_bt2020
• EXT_gl_colorspace_scrgb_linear
• EXT_gl_colorspace_display_p3
• EXT_gl_colorspace_display_p3_passthrough
• EXT_gl_colorspace_scrgb
• EXT_surface_SMPTE2086_metadata
• EXT_surface_CTA861_3_metadata

Most of these extensions work by defining new values for EGL_GL_COLORSPACE EGLSurface attribute. These extension values are clear how they should map to color-management. The EGL extensions assume that the values are forwarded to and used by the platform, that is, the window system.

The base values (defined by EGL 1.5) are not obvious how they should work though, especially the default being EGL_GL_COLORSPACE_LINEAR¹. Without color-management protocol extension, Wayland cannot handle "linear color", that is, optically encoded stimulus. Hence, no application has ever actually provided "linear color" on Wayland, and I doubt they did that on any other platform either because the usual 8 bits per color channel is not enough precision for dark shades. The color-management protocol is perfectly capable of communicating optically encoded stimulus, but mapping EGL_GL_COLORSPACE_LINEAR to that would likely break all existing EGL Wayland applications.

In order to preserve the behavior of existing applications, the use of EGL_GL_COLORSPACE_LINEAR must result in EGL not setting any "image description" on the Wayland surface with color-management protocol extension. Probably EGL_GL_COLORSPACE_SRGB needs to do the same. Wayland compositors will handle such Wayland surfaces appropriately, given that it is needed for backward compatibility of any Wayland application not using color-management protocol.

This also means that using EGL API, it is not possible to tell the Wayland window system that the surface is explicitly sRGB.

We also need to guarantee a way to use EGL on a wl_surface such that the application itself, not EGL, drives the color-management Wayland extension. The Wayland extension supports more than EGL API exposes, particularly the use of ICC profiles. Defining EGL_GL_COLORSPACE_LINEAR and EGL_GL_COLORSPACE_SRGB settings to not create a wp_color_management_surface_v1 on EGL Wayland platform achieves that.

The above needs to be documented in EGL_KHR_platform_wayland.

Footnotes

1. It seems to me that EGL_GL_COLORSPACE attribute was somehow originally yet another switch in allowing GL to do the sRGB transfer function encoding/decoding automatically. Then, all EXT_gl_colorspace_* extensions re-purposed the attribute for communicating stimulus encoding to the window system (platform). ↩

[stonesthrow]

https://registry.khronos.org/EGL/extensions/KHR/EGL_KHR_gl_colorspace.txt
Is the initial colorspace extension and defines sRGB - to add to your list of relevant. As you noted about EGL_GL_COLORSPACE attribute.