[Cin] "Competitors" or do we want to stay alive?

Mon Apr 7 11:44:25 UTC 2025

пн, 7 апр. 2025 г., 14:19 Pekka Paalanen <pekka.paalanen at haloniitty.fi>:

> On Fri, 4 Apr 2025 22:14:10 +0300
> Andrew Randrianasulu <randrianasulu at gmail.com> wrote:
>
> > пт, 4 апр. 2025 г., 21:35 Andrea paz <gamberucci.andrea at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20250407/08fe30e6/attachment-0001.htm>