<div dir="auto"><div> <div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">пн, 7 апр. 2025 г., 14:19 Pekka Paalanen <<a href="mailto:pekka.paalanen@haloniitty.fi">pekka.paalanen@haloniitty.fi</a>>: </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, 4 Apr 2025 22:14:10 +0300 Andrew Randrianasulu <<a href="mailto:randrianasulu@gmail.com" target="_blank" rel="noreferrer">randrianasulu@gmail.com</a>> wrote: > пт, 4 апр. 2025 г., 21:35 Andrea paz <<a href="mailto:gamberucci.andrea@gmail.com" target="_blank" rel="noreferrer">gamberucci.andrea@gmail.com</a>>: > > > @Georgy > > X11 supports CMS more or less well. Even I was able to profile the > > monitor and install it with colord. It's not full support like Windows > > or Apple has, but it's doable. Hi, X11 supports color management by having nothing to do with it. It's a strictly hands-off design. Each application can choose a different CMS simultaneously. An application that does not explicitly use a CMS also does not have any color management with X11. The X server can step out of the way and let applications post pixels as-is to each monitor. This is good for application-side color management, the pixel values do not get arbitrarily munged. However, X11 also offers a number of interfaces to force the X server to munge the pixel values. It allows loading a VCGT, but it also allows any app to change any of the pixel munging settings, so the display calibration is fragile. On X11 it is the responsibility of each application to make each part of their windows color-managed for the monitor they happen to overlap. X11 does nothing to help with that. > > For Wayland the big problem, why they didn't want to make a CMS, is > > its being decentralized, a protocol to which various software could > > interact by bringing their own version of CMS. The trouble is that a > > CMS must be centralized by definition, if everyone fakes their own > > implementation goodbye std. In the Wayland model, the color management is centralized in the Wayland compositor you use. Any application that does not choose to manage its own colors will get color-managed by the compositor automatically and unavoidably. > > On Wayland, good programmers but bad color scientists, they didn't > > even know how to start. Then Valve created The Gamescope to be able to > > play games in HDR, and Wayland started from that to implement its CMS. <a href="https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/14" rel="noreferrer noreferrer" target="_blank">https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/14</a> was created 5 years ago. <a href="https://github.com/ValveSoftware/gamescope/pull/1168" rel="noreferrer noreferrer" target="_blank">https://github.com/ValveSoftware/gamescope/pull/1168</a> was filed 1 year ago, after the above had already settled on the fundamental information to be carried. EGL and Vulkan HDR extensions are the real API predecessors here for both, and ITU-R recommendations and SMPTE specifications have had their influence as well. > > The result is not a real CMS but just something for video games and > > movies. True, lately they seem to have figured out the problem and one > > can hope that they will be able to solve it. The decision to concentrate first to the HDR aspect was a deliberate decision due to popular demand. The professional color-managed workflows were always in my mind from the start. In fact, people were in a hurry to implement HDR support without any thought to color management, but I'm really happy to have been able to sell the idea that color management is a prerequisite to HDR support. Otherwise we would now have ad hoc HDR support that would quite likely be fundamentally incompatible with the goals of color management. > > For the time being, the main developer said:... > > 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. > > ... > > > > Introduction to CMS in Wayland by the lead developer: > > > > <a href="https://www.collabora.com/news-and-blog/news-and-events/12-years-of-incubating-wayland-color-management.html" rel="noreferrer noreferrer" target="_blank">https://www.collabora.com/news-and-blog/news-and-events/12-years-of-incubating-wayland-color-management.html</a> You quoted that part, but conveniently ignored everything else that goes against your statements. My plan for display profiling and calibration was documented 2 years ago: <a href="https://gitlab.freedesktop.org/pq/color-and-hdr/-/issues/27" rel="noreferrer noreferrer" target="_blank">https://gitlab.freedesktop.org/pq/color-and-hdr/-/issues/27</a> and this was linked in the text you quoted, and below. Note, that it is possible to calibrate and profile a monitor without anything from issue 27, it's just tedious and error-prone to achieve. Issue 27 makes that process easier to get right, more robust, and more user friendly. The one thing that issue 27 does mention is the programming of a VCGT, but I am unsure whether that has any benefit for any HDR monitor driven in HDR mode. > > > > A summary by Paalanem of everything that happened in the 12 years of > > development: > > <a href="https://gitlab.freedesktop.org/pq/color-and-hdr" rel="noreferrer noreferrer" target="_blank">https://gitlab.freedesktop.org/pq/color-and-hdr</a> > > > > Old discussion on monitor profiling (in the thread, user Graeme Gill > > is ArgylCMS's developer): > > <a href="https://gitlab.freedesktop.org/pq/color-and-hdr/-/issues/27" rel="noreferrer noreferrer" target="_blank">https://gitlab.freedesktop.org/pq/color-and-hdr/-/issues/27</a> > > > > Wayland CMS implementation in Gnome: > > <a href="https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4291" rel="noreferrer noreferrer" target="_blank">https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4291</a> > > > > > > A theoretical question: can CinGG be adapted to work in Wayland or is > > it impossible? Has XWayland limitation? X11 and Wayland designs for color management are fundamentally incompatible. With X11, applications never tell the display server what kind of pixels they are producing or which, if any, color profile they used for the display. With Wayland, applications must describe their pixels to the display server. Since X11 applications tell nothing to the X server, Xwayland has no color information to forward to the Wayland compositor. There can be case-specific manual solutions, though, that rely on correctly configuring both the X11 apps and the Wayland compositor. X11 apps need to be configured to render for a specific display profile, and the Wayland compositor needs to assume the X11 windows are rendered for the same specific display profile. How that is actually done is up for each X11 app and each Wayland compositor. </blockquote></div></div><div dir="auto"> </div><div dir="auto">Is there possibility for X extension for Xwayland allowing relatively simple way to tell Xwayland what to do with each window/region?</div><div dir="auto"> </div><div dir="auto">A bit like</div><div dir="auto"> </div><div dir="auto"><a href="https://github.com/oyranos-cms/oyranos/blob/master/libxcm/include/X11/Xcm/Xcm.h">https://github.com/oyranos-cms/oyranos/blob/master/libxcm/include/X11/Xcm/Xcm.h</a></div><div dir="auto"> </div><div dir="auto">I looked in libplacebo (for avoiding to deal directly with Vulkan et al) and ... it was not simple for me.</div><div dir="auto"> </div><div dir="auto"> </div><div dir="auto"> </div><div dir="auto"><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> I happened to see there is a Cinelerra.GG ticket open for ICC support. A native Wayland application would not necessarily need to work with ICC profiles, the color management protocol has an alternative (and HDR-capable!) interface for "parametric image descriptions" which are much closer to video metadata interfaces than ICC. EGL and Vulkan color related extensions will map to the Wayland color-management protocol as the support lands and matures in Mesa, so it's possible to take advantage of Wayland color features without touching the protocol yourself. > > IF i understand correctly basically screencapture, user input, > monitor/compositor all tied to X11. There are (or were) different output > modules (to DV tape, to mjpeg card), so I guess SOME abstraction between > core and video i/o exist in cinelerras. Right now cingg reported to work > over Xwayland but I do not know how any (external) color management etc > work in this case. Under wayland you need EGL not GLX and cingg uses rather > obscure Xserver pbuffer mechanism. Not sure how easy/impossible is to > rewrite it for EGL. > > I do not even know where such questions should be asked now! On xorg-devel? > in gitlab issues? > > cc xorg-devel because I have them in my auto-address book in gmail. Wayland-related things can be discussed on wayland-devel@, cc'd, but it requires subscription to avoid the manual moderation queue when sending email to it. I'm happy to discuss color management topics in <a href="https://gitlab.freedesktop.org/pq/color-and-hdr/-/issues" rel="noreferrer noreferrer" target="_blank">https://gitlab.freedesktop.org/pq/color-and-hdr/-/issues</a> as well. I'm also subscribed to argyllcms and lcms-user lists for topics around ICC. Thanks, pq </blockquote></div></div></div>