Wayland Color Management Protocol Posted For Weston

[phoronix]

Phoronix: Wayland Color Management Protocol Posted For Weston

The Wayland Color Management protocol has been years in the making and is needed for a client to specify the color space and HDR metadata of a surface. This color management protocol is ultimately needed for getting high dynamic range (HDR) support working out well within Wayland environments. This week an initial merge request was opened for implementing the draft color management protocol with the Weston reference compositor...

https://www.phoronix.com/news/Wayland-CM-Weston

[Sethox]

It has taken some time and it will still take some more time before it being stable. I don't care, it just means I get the feature in (hopefully) properly manner (vs Windows).

[Errinwright]

Does this clash with Melissa's work on HDR- and colour management?

[MastaG]

I'd say another 2 or 3 years before we can enable HDR from our desktop. Perhaps an extra year on top of it for nvidia's blob.

[tgurr]

Without proper color management to be able to load icc files wayland is pretty much unusable in a semi-professional environment where you need your monitors calibrated. Real professionals probably have devices that can be hardware calibrated directly but even me and me eyes not doing any actual graphics work but just regular office work suffer heavily from working infront of an uncalibrated monitor. Can't understand the direction with forcing wayland on everyone in the near future when such basic things aren't implemented yet, imho this is currently the most important blocker from adopting wayland and I'm not talking about HDR here.

[Quackdoc]

Without proper color management to be able to load icc files wayland is pretty much unusable in a semi-professional environment where you need your monitors calibrated. Real professionals probably have devices that can be hardware calibrated directly but even me and me eyes not doing any actual graphics work but just regular office work suffer heavily from working infront of an uncalibrated monitor. Can't understand the direction with forcing wayland on everyone in the near future when such basic things aren't implemented yet, imho this is currently the most important blocker from adopting wayland and I'm not talking about HDR here.

this hardly scratches the surface, IMO the only viable solution is what mac has, which is a fully managed pipeline, the compositor should do things like gamut mapping and tonemapping when possible

[Danny3]

I don't get it.
Can't the compositors just use internally something like 12bit of color and then take as input images in 12,10, 8bit of color, do whatever is needed and then output in 12,10,8bit depending on what is the display capable to accept?
Isn't 12bit or 10bit of color enough to have HDR support or the light intensity is not part of the color range?

Because for me 12bit, 10bit of color or how they say it in millions of billions of colors just mean the same few colors with different shades and the shades are made with a little bit more or less luminosity (light). There are not other color, just the same colors with a bit more or less light.

Can someone dumb this down?

[ehansin]

I am not sure what the proper solutions are, all I know is that I want to keep seeing improvements to all the "low-level plumbing" that underlies the Linux desktop. I use both Windows and macOS for work, and fine for what it needs to be. I actually like the UI and workflow I have set up for Windows 10, and can manage pretty well in macOS (and with a terminal and brew package manager, got my tools!) and the aesthetics there are pretty good (though have some usability gripes.)

But I see where things are going, for sure in the Windows world. Obviously already happening, but it is going to get worse. My computing increasingly more and more tied into external services, data collection, AI doing the thinking for me, etc. And I probably will not have a choice about it. I want to be the driver in that thing called *my* computing, not a passenger to over-automation I didn't ask for. But that is where things are headed.

So sane Linux solutions are an off (or is in on) ramp to how I want things. I see things happening, even if a slow process. I welcome whatever improvements come about, as they will add up over time.

[Berniyh]

I'd say another 2 or 3 years before we can enable HDR from our desktop. Perhaps an extra year on top of it for nvidia's blob.

I don't think it'll take that long, at least not for AMD with the open source drivers.
The way I understood it is that the kernel side is basically ready for HDR and we're mainly waiting for support in compositors and applications, which is what this protocol is part of.
This seems like a realistic scenario, since under some circumstances (i.e. with gamescope), you can already run some games in HDR.

So if the protocols are set, which hopefully happens sooner than later, then there is light at the end of the virtual tunnel … in HDR.

[Quackdoc]

I don't get it.
Can't the compositors just use internally something like 12bit of color and then take as input images in 12,10, 8bit of color, do whatever is needed and then output in 12,10,8bit depending on what is the display capable to accept?
Isn't 12bit or 10bit of color enough to have HDR support or the light intensity is not part of the color range?

Because for me 12bit, 10bit of color or how they say it in millions of billions of colors just mean the same few colors with different shades and the shades are made with a little bit more or less luminosity (light). There are not other color, just the same colors with a bit more or less light.

Can someone dumb this down?

it's way more complicated then that, but ill pose a set of questions to get you thinking, what happens when you have a SDR window (firefox) and a 4000nit brightness video? without tonemapping, if your magical display is bright enough, you wont even be able to see whats on the firefox screen.

How do you solve this?
A) Do nothing and render each window "as intented"
B) tonemap firefox to be as bright as the video
C) Tonemap the video to be as dim as firefox
D) tonemap both to a "Happy medium"

You have an display capable of DCI-p3, and you have 2 images on screen, one DCI-p3 and one gamma2.2. How do you render this?
A) Treat everything as sRGB and leave it to apps to map to sRGB (the current method)
B) Leave it to the app to try and map images to DCI-P3
C) The compositor to map everything to sRGB
D) The compositor maps everything to DCI-p3

and what information does the compositor need to get from the clients to determine what to do in the case of multiple viable solutions?

These are the kinds of things compositors will need to ask themselves, how to go about doing these conversions and whatnot. and it's important to actually figure things out like this since you need to know what to add to the spec so you don't have, for lack of a better term that I know of, a "Rolling spec"

EDIT: There are lots of other smaller problems, as you can see the wayland spec isn't all that long, but the wayland devs are not color scientists, I see that troy sobotka has been getting involved with the color-and-hdr repo which is really nice, but color is a massively complicated topic with tons of misinformation out there which means a lot of the work has been just stumbling along