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

[Pekka Paalanen]

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.

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 --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20250407/2327b82a/attachment.sig>