Re: Wayland compositor color management model

On Tue, 3 Oct 2023 10:58:31 -0700
Pierre-Anthony Lemieux <pal@sandflow.com> wrote:

> Hi Pekka,
> 
> Thanks for sharing the document.
> 
> Can you provide a link to the description of the parameterization of
> the "output image description"?

Hi Pierre,

"image description" is a term we invented as we didn't know of a
suitable word and "image state" felt like it was for something else.
That paper talking about ISO 22028-1 seems to call it "Color Image
Encoding".

Image description is anything and everything the Wayland
color-management protocol can carry that defines what the pixel values
mean up to appearance. It includes at least the colorimetry (how to
convert arbitrary RGB pixels to optical CIE XYZ), absolute luminance if
appropriate, the targeted/meaningful color volume (equivalent to MDCV),
HDR metadata if any, and for display-referred signals the reference
display and viewing conditions. Our parameterisation of the reference
display and reference viewing conditions are still missing, so we
probably need to imply them through the transfer characteristics at the
moment.

Alternatively, an image description can also be an ICC display class
profile.

The only definition for now is in the Wayland extension interfaces in
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/14
(see the "Changes" tab and expand the XML file)

wp_image_description_v1 interface is designed to be able to deliver
Wayland clients all the information of any kind of image description,
some details in several different forms, e.g. primaries as CICP and as
CIE xy. That allows delivering the highest level information possible
(CICP) while also allowing arbitrary data (CIE xy).

Clients (applications) have access to the output image descriptions and
to the compositor chosen surface (window) preferred image description.
What the preferred image description is, is up to each compositor on
their own. The output image description's relations are explained in the
compositor color management model document.

There are also interfaces for the opposite, for clients to create their
own image descriptions. Those interfaces are more split.

Our image description is still more of a concept than a
parameterisation.


Thanks,
pq


> On Fri, Sep 29, 2023 at 5:53 AM Pekka Paalanen
> <pekka.paalanen@collabora.com> wrote:
> >
> > Hi all,
> >
> > the recent discussions with Simon Thompson and others have given me
> > inspiration to think about how Wayland should account for in-display
> > image adjustments which lead me to write
> > https://gitlab.freedesktop.org/pq/color-and-hdr/-/merge_requests/35
> >
> > (Best viewed at
> > https://gitlab.freedesktop.org/pq/color-and-hdr/-/blob/bb44957a29c49232c3f94530e92617f6e8fc9d36/doc/color-management-model.md
> > )
> >
> > That concept may be useful also for the W3C, because it may well be
> > what Linux desktop OSs offer to browsers in terms of color support.
> >
> > It starts by stating that a Wayland compositor will only convert
> > display-referred signal to display-referred signal, but that is a
> > little bit of a lie, because I do believe we will also support HLG.
> > Therefore, when the image content or the monitor signal is in HLG, drop
> > the unnecessary display and viewing condition referrals.
> >
> > We take care to consider also the traditional color management (ICC)
> > use cases where exact light colorimetry must not be ruined with the
> > perceptional conversions that are otherwise desired.
> >
> > I hope this can provide what browsers need. Any comments are welcome.
> >
> >
> > Thanks,
> > pq
> >
> > ps. I picked my nick in the 90s, it has nothing to do with perceptual
> > quantizer. :-)