WayfireWM
[Feature Request] Is color management planned in an observable future?
Something like compicc plugin (but not oyranos-based, if possible))). colord seem to work with wayland AFAIK.
I will be honest, I know next to nothing about color management, and I have no need for it personally. Hence the answer is no, except if somebody doesn't tell me exactly what is needed, or if support is added in wlroots which would make it so I don't have to know the details.
Anyway, we already support gamma correction based on this protocol. It is already used for redshift on Wayland which works in Sway and in Wayfire. If that is enough, then somebody needs to write a client which adjusts the gamma tables accordingly. In this case, there is also nothing Wayfire needs to do besides what it already does.
Hope the info helps, if not, sorry, can't say anything more since I probably know less than you in this particular area.
I see... AFAIU gamma correction is only a part of it... I'm not a guru in this area, either. However, colord seems to work with wayland as stated here https://www.freedesktop.org/software/colord/faq.html
In compiz 0.8 that was implemented via compicc plugin that calls oyranos cms to get things done. However oyranos works in a quite weird way: it pretends that display is an sRGB one, therefore all not-color-managed apps "just work", because oyranos does all the conversion magic under the hood. But that's not very useful, for one may just switch the monitor into sRGB mode (as soon as we're talking about monitors) with exactly the same end result. However, for color-managed apps there is some additional X11 protocol to inquire the real color gamut (that seems not to be used by any real app so it appears to be quite useless, again. I just switched color management via compicc off when using darktable and on otherwise, not to have eye-burning colors on the screen. An that was better than nothing). And oyranos itself was used by KDE but not anymore, so it's future is quite unpredictable (or, TBH, quite predictable). Within X ecosystem apps use either _ICC_PROFILE atom or inquire colord to get info about how RGB values map onto monitor real color, as colord FAQ states (see above). Colord works as a daemon and sets up color profiles in real-time (what I personally doubt is very useful: hot-plugging different devices isn't a widespread use case IMO). I think a static setup once the monitor is plugged is enough for most use cases (which argyll does, for instance). But as soon as we are talking about Wayland, colord seems to be the only option. That's about all I know about that. I only may provide some useful links to whoever may want to get into it. https://ninedegreesbelow.com/photography/articles.html https://encrypted.pcode.nl/blog/index.html%3Fp=983.html
UPDATE: I wrote the above from my point of view based on my sole use case. If one owns a notebook and connects few different monitors to it, or uses a printer, than colord is very useful, indeed. (I just always try to avoid a daemon for the task that might be painlessly solved without it. So I realized that there might be use cases when it's really helpful).
Another thing to be mentioned here. compicc's biggest benefits is that it uses the GPU shaders to correct colors on the fly. So it's blazing fast and virtually exhibits no CPU consumption. Its major drawback is it relies upon oyranos and X protocol extension nobody seems to use. Probably if compicc was written when colord already existed, they might comprise a great couple...
Another thing to be mentioned here. compicc's biggest benefits is that it uses the GPU shaders to correct colors on the fly. So it's blazing fast and virtually exhibits no CPU consumption. Its major drawback is it relies upon oyranos and X protocol extension nobody seems to use. Probably if compicc was written when colord already existed, thay might be a great couple...
If the transformations can be achieved via a simple shader, Wayfire provides APIs for that (and they are used by multiple plugins already).
I have also heard of per-surface color correction protocol, but it is far from ready as far as I know.
Looking at what Weston does,
- weston_cms_set_color_profile only sets gamma (by using lcms2 to get it from an ICC profile)
- cms-colord registers outputs with colord and applies profiles using
weston_cms_set_color_profile
this should be possible with a client.
https://github.com/swaywm/sway/issues/1486 links to http://www.argyllcms.com/WaylandCM_v1.txt which discusses a potential future per-application color management protocol, but it doesn't mention colord at all.
Seems like colord rejects the "conversion in compositor" idea and pushes the conversion onto the application. Which makes everything easier for compositor developers :)
Just for the case, Richard Hughes, the colord author's site: https://hughsie.com. Email's at the footer))) Haven't communicated with him myself but they say he's quite supportive. Maybe he's got some vision about how to implement this in a proper way. Thanks for taking part in this!
Abandoned plugin for Compiz 0.9: https://github.com/gebner/compiz-cms -- another attempt to offload the calculations to the GPU by pushing the transformation into the compositor, potentially speeding up workflow dramatically, although an incomplete one: because the applications are not able to mark specific regions with different transformation needs, the plug-in assumes all images are sRGB. From one hand, it gives the possibility to color-correct the whole desktop including background images, from the other hand it restricts the app's ability to naturally pass wide-gamut images to wide-gamut display, which kills the whole idea the same way compicc did. The ideal workflow would be: for the desktop and not-color-aware apps the plugin does color mapping as if the monitor was sRGB. For color-aware ones there should be a "tunnel" allowing the app to get color profile and use it directly, bypassing the default color correction. That is different from how it supposed to work in X11 now (when there is no color correction by default, making interface/background colors oversaturated on a wide gamut monitor). However to be able to do this, the compositor has to somehow distinguish color-corrected apps. As a user, I wouldn't mind to manually name such apps for a compositor (like one may create window rules, for example), because there are actually just few of them (do it once and be happy forever). I have no idea if it can be automated somehow (for this the compositor has to know if the app calls colord or not).
for the desktop and not-color-aware apps the plugin does color mapping as if the monitor was sRGB. […] when there is no color correction by default, making interface/background colors oversaturated on a wide gamut monitor
Oh, so that's why a protocol for marking buffers would be good.
Also, the compositor should be compositing in 10-bit for wide-gamut support! Which is complicated since you still need 8-bit surfaces for alpha transparency. @ammen99 everything is composited in 8-bit currently, right?
@kanyck If you just want to attach a shader, this should be very easy. Just ask @soreau he already has a similar plugin, and then you can play with the shader in the source code.
@myfreeweb Yes, everything is in RGBA format. However, I am not sure how 10-bit color should work at all - do we need special EGL atrributes for the context?
The problem with alpha can be easily solved if textures can be 10-bit or 8-bit. Wayfire's shaders already support having views with different texture formats, so it should be"just" adding a new texture type. However, does wlroots support such formats at all yet?
So, there seems to be finally some work on Wayland's colour handling protocol and experimental weston implementation: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/14#note_1117408
Considering that almost all displays come with out-of-wack defaults and, with rise of "HDR", every one of them pushes widely different contrast and gamut numbers, colour "normalization" is vital, especially when having multiple displays. X11 cannot die until this is done.
On the topic of HDR, a Sway issue links https://code.videolan.org/videolan/libplacebo. It may be possible to use this in conjunction with colord.
Some initial HDR/color management support has landed in Weston 11, more is promised in Weston 12. Hopefully it may become usable with some reservations within a year or so. Looking forward to drop X11 -- there are some weird things are happening on my Compiz desktop after recent system update. No chance they'll be fixed, nor can I find a suitable alternative to Compiz under xorg without loosing goodies I got addicted to :-)
In recent developments, wayfire upgraded to wlroots 0.17.x which adds gamma support. This means utilities such as wlsunset now work. Closing..
