1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
|
<?xml version='1.0' encoding='utf-8' ?>
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
<!ENTITY % BOOK_ENTITIES SYSTEM "Wayland.ent">
%BOOK_ENTITIES;
]>
<chapter id="chap-Color-Management">
<title>Color management</title>
<section id="sect-Color-Management-preface">
<title>Overview</title>
<para>
Color management in Wayland considers only displays. All pictures in
Wayland are always display-referred, meaning that the pixel values are
intended as-is for some specific display where they would produce the
light emissions (<ulink
url="https://cie.co.at/eilvterm/17-23-002">stimuli</ulink>) the picture's
author desired. Wayland does not support displaying "raw" camera or
scanner images as they are not display-referred, nor are they even
pictures without complex and subjective processing.
</para>
<para>
Stimuli — the picture itself — are only half of the picture reproduction.
The other half is the environment where a display is viewed. A striking
example is comparing a brightly lit office to a dark movie theater, the
stimuli required to produce a good reading of the picture is greatly
different. Therefore display-referred does not include only the display
but the viewing environment as well.
</para>
<para>
Window systems have been very well capable of operating without any
explicit consideration to color management. This is because there used to
be the implicit assumption of the standard display, the sRGB display,
which all computer monitors implemented, more or less. The viewing
environment was and still is accounted by adjusting the display and/or the
room to produce a workable experience. Pictures are authored on a computer
system by drawing, painting and adjusting the picture until it looks right
on the author's monitor. This implicitly builds the standard display and
environment assumption into the picture data. Deviations from the sRGB
specification were minor enough that they often did not matter if not in a
professional context like the printing industry. Displaying video material
required some more attention to the details, because video and television
standards differ enough from the sRGB display. What really made explicit
color management a hard requirement for entertainment is the coming of
wide color gamut (WCG) and high dynamic range (HDR) materials and
displays.
</para>
<para>
The color management design in Wayland follows the general Wayland design
principles: compositors tell clients what would be the optimal thing to
do, clients tell the compositors what kind of pictures they are actually
producing, and then compositors display those pictures the best they can.
</para>
</section>
<section id="sect-Color-Management-Protocol">
<title>Protocol Interfaces</title>
<para>
Color management interfaces in Wayland and divided into two protocols:
<ulink url="https://gitlab.freedesktop.org/wayland/wayland-protocols/-/tree/main/staging/color-management?ref_type=heads">color-management</ulink>
and
<ulink url="https://gitlab.freedesktop.org/wayland/wayland-protocols/-/tree/main/staging/color-representation?ref_type=heads">color-representation</ulink>.
They are designed to work together, but they can also be used
independently when the other one is not needed.
</para>
<section id="sect-Color-Management-Protocol-color-management">
<title>Color-management</title>
<para>
Color management protocol has two main purposes. First, it puts the
responsibility of color management on the compositor. This means that
clients do not necessarily need to care about color management at all,
and can display just fine by using the traditional standard display
assumption even when the actual display is wildly different. Clients
can also choose to target some other assumed display and let the
compositor handle it, or they can explicitly render for the actual
display at hand. Second, when the window system has multiple different
monitors, and a wl_surface happens to span more than one monitor, the
compositor can display the surface content correctly on all spanned
monitors simultaneously, as much as physically possible.
</para>
<para>
Color-management protocol concentrates on colorimetry: when you have a
pixel with RGB values, what stimulus do those values represent. The
stimulus definition follows the CIE 1931 two-degree observer model. Some
core concepts here are color primaries, white point, transfer function,
and dynamic range. The viewing environment is represented in an
extremely simplified way as the reference white luminance. The
connection between pixel RGB values and stimulus plus viewing
environment is recorded in an <emphasis>image description</emphasis>
object. Clients can create image description objects and tag
<code>wl_surface</code>s with them, to indicate what kind of surface
content there will be. Clients can also ask what image description the
compositor would prefer to have on the <code>wl_surface</code>, and that
preference can change over time, e.g. when the <code>wl_surface</code>
is moved from one
<code>wl_output</code> to another. Following the compositor's preference
may provide advantages in image quality and power consumption.
</para>
<para>
Image description objects can come in two flavors: parametric and
ICC-based. The above was written with parametric image descriptions in
mind, and they have first-class support for HDR. ICC-based image
descriptions are wrapping an ICC profile and have no other data. ICC
profiles are the standard tool for standard dynamic range (SDR) display
color management. This means the capabilities between the two flavors
differ, and one cannot always be replaced by the other. Compositor
support for each flavor is optional.
</para>
</section>
<section id="sect-Color-Management-Protocol-color-representation">
<title>Color-representation</title>
<para>
Color-representation protocol deals with (potentially sub-sampled)
YCbCr-RGB conversion, quantization range, and the inclusion of alpha in
the RGB color channels, a.k.a. pre-multiplication. There are several
different specifications on how an YCbCr-like (including ICtCp) signal,
with chroma sub-sampling or not, is created from a full-resolution RGB
image. Again, a client can tag a <code>wl_surface</code> with
color-representation metadata to tell the compositor what kind of pixel
data will be displayed through the wl_surface.
</para>
<para>
The main purpose of color-representation is to correctly off-load the
YCbCr-RGB conversion to the compositor, which can then opportunistically
off-load it further to very power-efficient fixed-function circuitry in
a display controller. This can significantly reduce power consumption
when watching videos compared to using a GPU for the same, and on some
embedded hardware platforms it is a hard requirement for processing high
resolution video.
</para>
</section>
</section>
</chapter>
|
