mirror of
https://gitlab.freedesktop.org/wayland/wayland.git
synced 2025-10-29 05:40:16 -04:00
doc: add a section on color management
I think the docbook deserves an introduction to how color management is designed in Wayland, aimed at people who are familiar with pixels but new to the topic. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This commit is contained in:
Pekka Paalanen
parent
53fbc2b0c1
commit
ba9f9a446f
3 changed files with 141 additions and 0 deletions
139
doc/publican/sources/Color.xml
Normal file
139
doc/publican/sources/Color.xml
Normal file
|
|
@ -0,0 +1,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>
|
||||||
|
|
@ -12,6 +12,7 @@
|
||||||
<xi:include href="Architecture.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
|
<xi:include href="Architecture.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
|
||||||
<xi:include href="Protocol.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
|
<xi:include href="Protocol.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
|
||||||
<xi:include href="Xwayland.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
|
<xi:include href="Xwayland.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
|
||||||
|
<xi:include href="Color.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
|
||||||
<xi:include href="ProtocolSpec.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
|
<xi:include href="ProtocolSpec.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
|
||||||
<xi:include href="Client.xml" xmlns:xi="http://www.w3.org/2001/XInclude"/>
|
<xi:include href="Client.xml" xmlns:xi="http://www.w3.org/2001/XInclude"/>
|
||||||
<xi:include href="Server.xml" xmlns:xi="http://www.w3.org/2001/XInclude"/>
|
<xi:include href="Server.xml" xmlns:xi="http://www.w3.org/2001/XInclude"/>
|
||||||
|
|
|
||||||
|
|
@ -54,6 +54,7 @@ publican_sources = [
|
||||||
'Protocol.xml',
|
'Protocol.xml',
|
||||||
'Xwayland.xml',
|
'Xwayland.xml',
|
||||||
'Compositors.xml',
|
'Compositors.xml',
|
||||||
|
'Color.xml',
|
||||||
'Client.xml',
|
'Client.xml',
|
||||||
'Server.xml'
|
'Server.xml'
|
||||||
]
|
]
|
||||||
|
|
|
||||||
Loading…
Add table
Add a link
Reference in a new issue