пн, 7 апр. 2025 г., 14:19 Pekka Paalanen <pekka.paala...@haloniitty.fi>:
> On Fri, 4 Apr 2025 22:14:10 +0300 > Andrew Randrianasulu <randrianas...@gmail.com> wrote: > > > пт, 4 апр. 2025 г., 21:35 Andrea paz <gamberucci.and...@gmail.com>: > > > > > @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. > > > https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/14 > was created 5 years ago. > > https://github.com/ValveSoftware/gamescope/pull/1168 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: > > > > > > > https://www.collabora.com/news-and-blog/news-and-events/12-years-of-incubating-wayland-color-management.html > > 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: > https://gitlab.freedesktop.org/pq/color-and-hdr/-/issues/27 > > 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: > > > https://gitlab.freedesktop.org/pq/color-and-hdr > > > > > > Old discussion on monitor profiling (in the thread, user Graeme Gill > > > is ArgylCMS's developer): > > > https://gitlab.freedesktop.org/pq/color-and-hdr/-/issues/27 > > > > > > Wayland CMS implementation in Gnome: > > > https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4291 > > > > > > > > > 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. > Is there possibility for X extension for Xwayland allowing relatively simple way to tell Xwayland what to do with each window/region? A bit like https://github.com/oyranos-cms/oyranos/blob/master/libxcm/include/X11/Xcm/Xcm.h I looked in libplacebo (for avoiding to deal directly with Vulkan et al) and ... it was not simple for me. > 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 > https://gitlab.freedesktop.org/pq/color-and-hdr/-/issues as well. I'm > also subscribed to argyllcms and lcms-user lists for topics around ICC. > > > Thanks, > pq >
