The Wayland color-management protocol extension has landed on Feb 13th, 2025, in upstream wayland-protocols repository in the staging directory. It was released with wayland-protocols 1.41. The extension enables proper interactions between traditional (sRGB), Wide Color Gamut (WCG), and High Dynamic Range (HDR) image sources and displays once implemented in Wayland compositors and used in applications.

This has been a long way coming. Some discussions happened already in 2012 and led me to draft my first design. Naturally, that is not the current design. The first version similar to the current design was posted by Niels Ole Salscheider in 2014. I recall there having been heated discussions between people like me and Graeme Gill around those years, and I think there was a gap of activity for a few years as well.

In 2020, Sebastian Wick opened the merge request (MR) that evolved to become the accepted protocol extension. That MR was open for 5 years and a month, and accumulated 820 comments. Those comments are only a fraction of all the discussions. Sebastian's GitLab fork issues and merge requests have more. The documentation for color management also swelled so much that we decided to create a new repository just for that in 2021: color-and-hdr. In color-and-hdr we defined our terminology, discussed implementation design issues, collected resources, and more.

The protocol development branch grew to 141 commits. More recently, those commits tended to contain commit messages full of design rationale. We didn't want that information to get lost, so we saved it in a historical branch upstream. Wayland-protocols main branch got just a single commit with everything squashed, as is the project practice.

Over the years, Sebastian and I had some discussions with the World Wide Web Consortium people who are defining HDR for the web. Through them, we even managed to get an answer from SMPTE on a question that puzzled us on the HDR static metadata.

Of course, a protocol is just a language. Two participants need to speak the same language for the language to be of any use: Wayland compositors and a component on the application side (e.g., a toolkit library). Major efforts have been going on in various projects to prove and take advantage of the protocol, including KWin, Mutter, Weston, wlroots, GStreamer, GTK, Qt, SDL, Mesa, and mpv. Support in Mesa means that applications will be able to render and display in HDR by using the relevant EGL and Vulkan features.

The color-management Wayland extension is enough for entertainment purposes like games and movies. However, it is not enough for professional color management needs including photo editing and print preview. The major missing piece is the ability to measure the display response. Every monitor is unique, and measuring is the only way to achieve reliably repeatable and accurate display behavior. If I get to it first, I will probably start by drafting a Weston-private Wayland extension to see what it will need. It is not certain it will be a Wayland extension in the end, it could also be a portal.

In addition to everyone already mentioned and unmentioned, I would personally like to thank Troy Sobotka, Tony Vladusich, Graeme Gill, and Marti Maria. You have helped me understand this stuff, provided software, and most importantly made me understand that no one really understands how color works.

Related Posts

Weston 14.0: DRM-backend, color management, and output mirroring

Wine on Wayland: A year in review (and a look ahead)

A Pixel's Color & new documentation repository

Related Posts

Weston 14.0: DRM-backend, color management, and output mirroring

Wine on Wayland: A year in review (and a look ahead)

A Pixel's Color & new documentation repository