Everything is better in color. Even better if it is HDR.
In this post, we’ll provide an overview of what is happening with color in GTK, without diving too deeply into the weeds of colorimetry and color science.
The high-level goals of this effort are to enable proper handling of HDR content and color-managed workflows.
In the beginning, sRGB
Up until now, colors in GTK were always assumed to be in the sRGB color space. The omnipresent GdkRGBA struct is defined as specifying an sRGB color.
sRGB was a great thing 20 years ago, but there world is moving on to other color spaces that include a wider range of hues (such as Display-P3) or a bigger dynamic range (such as BT.2100-PQ).
After having this on our agenda for quite a while (initial investigations into this topic happened in 2021), we’re finally moving ahead with landing the foundations for a more colorful future.
Coming soon: GdkColorState
Earlier this year, we’ve merged some great work by Alice to support modern color syntax and color spaces in our CSS engine. Having expressive colors in CSS is great, but it can’t really shine if all our rendering machinery still requires colors to be specified in sRGB.
So over the past month or two, we’ve added support for doing our rendering in well-defined color spaces, and introduced an object representing these. It is called GdkColorState (don’t ask me why the name changed from space to state).
As of now, GdkColorState can represent sRGB and BT.2100-PQ, as well as their linearized variants. You cannot yet do much with these objects, they are mainly used internally by our renderers.
One thing you can already do though, is trying out how rendering in a linear color space will look, by setting the
GDK_DEBUG=linear
environment variable.
This is a change that we need to do eventually, to produce correct and understandable results, in particular when working with HDR content.
Doing all our compositing in a linear color state does look subtly different though, so want to delay this change until all of the surrounding work is done, and do it at beginning of a development cycle to give everybody time to adjust.
New protocols
The Wayland color management protocol has been a long time in the making, but it is hopefully close to leaving the experimental phase — kwin already has support for it, and there is a mutter branch as well.
We have added support for the xx-color-management-v4 protocol, so we get the preferred color state from the compositor (if it is supports that protocol), and we can tell it about the color state of the frames that we produce.
It is unlikely that your compositor will prefer an HDR color state like BT.2100-PQ today (unless you find the hidden switch to turn on experimental HDR support), but you can try how things look when GTK is rendering in that color state by setting the
GDK_DEBUG=hdr
environment variable.
Note that this doesn’t make HDR content appear on your screen — we do our rendering in HDR and translate the final frame back to sRGB as the last step. Making HDR content appear on your screen requires a compositor that accepts such content.
In the future: More color states and linear compositing
We still have a long todo list to fully develop color support in GTK.
The highlights include
- More color states (including OKLCH for better gradients and YUV for video content)
- Color state aware rendering api (GdkColor, and new GtkSnapshot APIs)
- Passing CSS color state information down to the renderer
- Propagating color state information from gstreamer (for HDR, among other things)
- Switching to linear compositing
A few of these will hopefully make it in time for the GTK 4.16 release.
Summary
Better color support is coming soon to GTK.