[RFC wayland-protocols] Color management protocol

[Niels Ole Salscheider]

Hello,

it has been some time since I proposed the first two RFCs for a color
management protocol in weston. You can find the old discussions here:

https://lists.freedesktop.org/archives/wayland-devel/2014-March/013951.html
https://lists.freedesktop.org/archives/wayland-devel/2014-October/017759.html

During the discussion of the second RFC it became clear that color correction
was out of scope for weston at that time.
In the meantime wayland-protocols was split from weston and libweston was
created. Several wayland compositors start to see everyday usage and wide-gamut
screens became more common so that color management becomes more important.

Therefore I think that the situation has changed and I'd like to propose this
protocol for inclusion in wayland-protocols again.
What do you think?

Ole

Niels Ole Salscheider (1):
  Add the color-management protocol

 Makefile.am|   1 +
 unstable/color-management/README   |   4 +
 .../color-management-unstable-v1.xml   | 136 +
 3 files changed, 141 insertions(+)
 create mode 100644 unstable/color-management/README
 create mode 100644 unstable/color-management/color-management-unstable-v1.xml

-- 
2.10.2

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[RFC wayland-protocols] Color management protocol

[Florian Höch]

[ Bunch of replies to different posts crammed into one, apologies in
advance. ]

Pekka Paalanen wrote:
> Would it not be simpler to just say "I'm doing calibration now, make
> sure nothing interferes"?

Sure, I just hope that "I'm doing calibration now, make sure nothing
interferes" still allows conventional application UI (e.g. using UI
frameworks like Gtk3, Qt etc) to be visible, because otherwise it would
effectively block users from interacting with said UI (going by your
comment "I also forgot to mention that surfaces with the
cms_calibration_surface role, when actually presented, would also
guarantee that nothing else will be shown on that specific output"
somehow sounds like it would not, but maybe I'm misunderstanding what
you mean by "output". I would certainly not be enthused if I had to
low-level re-implement parts of the UI I currently have - in fact I can
tell you right now that it would never, ever happen if it's not as
simple as writing for any of the common UI frameworks).

Graeme Gill wrote:
> Niels Ole Salscheider wrote:
>> My working view at the moment is that whatever is doing calibration
>> should be directly in charge of the full insane complexity of the
>> display hardware, and that even enumerating this, let alone offering
>> control over it, is not tractable. Which leaves us with two options:
>> the compositor runs calibration, or external calibration apps do not
>> run under a Wayland session and just drive DRM/KMS directly.
> 
> Really unattractive (i.e. a big obstacle) from a color management
> calibration/profiling application writers point of view.

Fully agree. On top of that, a "calibration/profiling/measurement"  app
is just a normal desktop application from a users' point of view, no
user will want or even expect such type of application to be any
different to what he/she is used to.

Graeme Gill wrote:
> Niels Ole Salscheider wrote:
>> This didn't make any sense when all display drivers were Xorg
>> components, but hey, we do have a universal API in DRM/KMS that you
>> can write applications directly towards, so I don't see why we should
>> bend over backwards making these compromises for special-purpose
>> clients which by definition do not interoperate with a regular desktop
>> environment.
> 
> Sorry, but from my perspective this is completely insane.
>
> I think that adding a couple of well understood API's doesn't
> compare to modifying a desktop application to have to, on the fly
> switch from a normal application context into configuring
> and then driving a (basically) raw frame buffer, convey all
> it's user interface to the frame buffer to run test patches,
> and then switch back again. And I don't know what you mean by
> "do not interoperate with a regular desktop environment". These
> are perfectly regular desktop applications that happen to have
> a special purpose. Casting them adrift from the normal desktop
> environment raises their difficulty into the "requires heroic effort"
> territory, due to huge breakage of cross platform application
> compatibility alone, and is directly contrary to the very
> idea of what a display server and the overlaying application UI
> toolkits are meant to provide!

Put bluntly, but I agree as well. A "calibration/profiling/measurement"
application is not more of a "special-purpose client" than, say, a CAD
application, a code editor, or an application that lets you create 3D
scenes of rotating bunnies wrapped around bunnies (scnr), ... etc.

Graeme Gill wrote:
> I'm also thinking it would really help a lot if you and
> others contributing to this thread were able
> to procure something like a X-Rite i1 display Pro,
> run up the manufacturer provided software on
> MSWindows or OS X to get a feel for what it does,
> then fire up DisplayCAL+ArgyllCMS on Linux/X11
> and take it for a spin.
> (Another path would be to obtain one of Richard's
>  ColorHug's, but I think seeing how the commercial
>  software operates as well, would add a broader perspective.)

Even watching some videos of a typical calibration/profiling workflow on
YouTube may already help.

[ Apologies if this post comes across more negative than I wanted it to
be. I'm certainly willing though to exercise the necessary patience and
open-ness to learn about other perspectives. ]

--
Florian Höch

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland-protocols] Color management protocol

[Niels Ole Salscheider]

Am Donnerstag, 1. Dezember 2016, 15:17:53 CET schrieb Graeme Gill:
> Niels Ole Salscheider wrote:
> 
> Hi,
> 
> > Then they use the "set_colorspace" request
> > to set the color space of their surface to the same color space in order
> > to
> > indicate that the compositor must not perform any additional color
> > conversion.
> that's one issue I have. This is a *really bad idea*,
> based on experience with its use on Apple OS X,
> and experience in designing other color management systems.
> 
> Use an explicit "color management off" flag instead.
> That clearly indicates what is intended, is not time
> sensitive (i.e. it's meaning is the same irrespective of
> what the device profile changes to in the future),
> doesn't demand that the client, application or file have the
> ability to identify or fetch the device profile, and is not
> subject to mistakes or confusion about whether the right
> profile has been set or whether profiles match, or whether
> pixel values are really being altered or not.

The first version of my proposal had such a flag. I removed it and replaced it 
by the described version based on feedback from Zoxc (zox...@gmail.com).

I can see advantages with both solutions. One advantage with the current 
proposal is that you can have a surface that covers multiple screens. In this 
case the compositor can still try its best to correct the colours for all but 
the main screen.

Back then I argued that this might not be good enough if you want to calibrate 
the monitor. But the consent was that this would require another protocol to 
disable all colour corrections anyway and that it could be developed at a 
later point.

I've CCed the list again because others might have an opinion on that...

> Cheers,
>   Graeme Gill.


___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland-protocols] Color management protocol

[Daniel Stone]

Hi Nils,

On 19 November 2016 at 16:29, Niels Ole Salscheider
 wrote:
> it has been some time since I proposed the first two RFCs for a color
> management protocol in weston. You can find the old discussions here:
>
> https://lists.freedesktop.org/archives/wayland-devel/2014-March/013951.html
> https://lists.freedesktop.org/archives/wayland-devel/2014-October/017759.html
>
> During the discussion of the second RFC it became clear that color correction
> was out of scope for weston at that time.
> In the meantime wayland-protocols was split from weston and libweston was
> created. Several wayland compositors start to see everyday usage and 
> wide-gamut
> screens became more common so that color management becomes more important.
>
> Therefore I think that the situation has changed and I'd like to propose this
> protocol for inclusion in wayland-protocols again.
> What do you think?

Yes, I think you're right, and it's time to start looking at it again.
Now Weston is a bit more mature/capable, the desktop environments have
caught up and are at the point where it makes sense for them to look
at it, and we have wayland-protocols rather than the old
weston/protocols/ dumping ground, it's probably the right time.

Cheers,
Daniel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland-protocols] Color management protocol

[Graeme Gill]

Niels Ole Salscheider wrote:

Hi,

> The first version of my proposal had such a flag. I removed it and replaced 
> it 
> by the described version based on feedback from Zoxc (zox...@gmail.com).

Do you have a link to the specifics ?

> I can see advantages with both solutions. One advantage with the current 
> proposal is that you can have a surface that covers multiple screens. In this 
> case the compositor can still try its best to correct the colours for all but 
> the main screen.

I'm not quite sure what you mean. Generally an application will have
specific reasons for wanting to do it's own color management - for
instance, perhaps it is previewing a CMYKOGlclm file, and wants to
treat out of gamut mapping and black point mapping in a particular way, etc.
I don't think the Wayland compositor is going to be expected to handle
CMYKOGlclm etc. input rasters, never mind all the requirements of specialist
application color management!

Which is not to say that compositor color management doesn't have its
place - it is ideal for applications that just want to use "RGB", and
not deal with specific display behavior.

> Back then I argued that this might not be good enough if you want to 
> calibrate 
> the monitor. But the consent was that this would require another protocol to 
> disable all colour corrections anyway and that it could be developed at a 
> later point.

I strongly disagree with this idea - disabling application-side color
management is a fundamental step in achieving end to end color management.
You don't have color management until you are able to profile the output device,
so this is not something that can be left until latter!

Graeme Gill.


___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland-protocols] Color management protocol

[Graeme Gill]

Niels Ole Salscheider wrote:

> Therefore I think that the situation has changed and I'd like to propose this
> protocol for inclusion in wayland-protocols again.
> What do you think?

Hi,
I'm prompted to look into the current state of color management
in Wayland, by Richard Hughes comment on the ArgyllCMS mailing list
recently that:

> About this; in the near future systems will be migrating from X11 to
> Wayland (Fedora 25 already defaults to Wayland, other distros will
> follow) and so setting X atoms is no longer going to work. Even with
> XWayland (the compatibility "wrapper" that provides an isolated
> xserver for the app) you can't use the root window as it's isolated
> from the other windows. I think most applications that want to know
> what profile to use are now using either libcolord, or more commonly,
> the colord DBus API.

What I take from this is that XWayland is lacking in its emulation
of existing X11 color management protocols (primarily due to lack
of underlying support in Wayland), and that currently the only
option for pure Wayland applications is to depend on system
specific work-arounds such as using Weston with colord. I can
therefore see that users that depend on color managed X11 applications
(such as photographers, desktop publishers, video editors etc.)
aren't going to be switching to Wayland based systems any
time soon.

Looking through the current Wayland color-management protocol
proposal, I think it is missing a really fundamental thing -
managing the output device color calibration state and color
profile. I guess the assumption is that this is being done
by colord, but my understanding is that colord is specific
to Gnome based systems, and certainly depends on DBus, which
Wayland does not. [ Please correct me if I've got any of this wrong. ]

It also seems fundamentally poor design to be using a parallel
protocol to manage the color of the graphics system, rather
than it being kept in sync with the elements being managed,
such as outputs and pixel rasters, etc. Certainly in X11 it is
all kept within the X11 protocol or its extensions.
If Wayland gets extended to be a remote protocol, then
the existence of in band protocols for color management
become even more important.

So as a broad outline, what I would regard as features of
a reasonable color management facility for a graphics
system such as Wayland are:

* That color management protocol's have two uses :- 1) configuring
  color management and 2) allowing applications to use color management.
  These two uses may need different security profiles.
  The assumption should be that color management applications
  used to create calibrations, profiles and configure the
  state of color management, are of equal importance to color
  managed applications that depend on a properly profiled and
  configured color management system, since you can't have latter
  with out the former.

* Color management of a graphics rendering system such as Wayland
  should be split into two levels (possibly two extensions) :-

  1) Core == output device management, which involves identifying output 
devices,
  controlling their calibration state (Video LUT), installing a color profile
  resources associated with that output device, and identifying which rendered
  pixels go to which output device(s). This is the most basic requirement, since
  this is the bare minimum for applications to be properly color managed. It
  is also a necessary resource for the second level to be able to operate.

  2) Enhanced == input space management, which assumes a graphics
  server rendering system capable of color management. This involves labeling
  an input raster with a color profile, and controlling the manner of
  rendering (i.e. rendering intent, maybe blending space ? etc.) This is useful
  for implementing default color management (e.g. as a means of coping
  with wide gamut displays when many applications are not color aware),
  or as a low developer overhead means of implementing basic color
  management in non color critical applications.

Translating these aims into a more concrete set of capabilities might
look like this:

Core:
Get corresponding CRTC regions for a given Surface.
Get corresponding Output(s) for a CRTC.
Get unique Monitor identifier for an Output (i.e. EDID)
Get/Set CRTC per channel lookup tables.
Clear/Set/Get ICC profile associated with an Output.

Event notifications:
- CRTC to surface mapping change
- Output to CRTC mapping change
- Monitor to Output connection change
- ICC profile associated with Output change

Enhanced:
Clear/Set/Get default color management source RGB ICC profile for a 
display.
Disable/Enable/UseDefault color management flag for a Surface.
Clear/Set/Get source RGB ICC profile for a Surface.
Set/Get source and destination rendering intents for a Surface.

Given that Wayland doesn't seem t

Re: [RFC wayland-protocols] Color management protocol

[The Rasterman]

On Fri, 2 Dec 2016 12:30:53 + Daniel Stone  said:

> Hi Nils,
> 
> On 19 November 2016 at 16:29, Niels Ole Salscheider
>  wrote:
> > it has been some time since I proposed the first two RFCs for a color
> > management protocol in weston. You can find the old discussions here:
> >
> > https://lists.freedesktop.org/archives/wayland-devel/2014-March/013951.html
> > https://lists.freedesktop.org/archives/wayland-devel/2014-October/017759.html
> >
> > During the discussion of the second RFC it became clear that color
> > correction was out of scope for weston at that time.
> > In the meantime wayland-protocols was split from weston and libweston was
> > created. Several wayland compositors start to see everyday usage and
> > wide-gamut screens became more common so that color management becomes more
> > important.
> >
> > Therefore I think that the situation has changed and I'd like to propose
> > this protocol for inclusion in wayland-protocols again.
> > What do you think?
> 
> Yes, I think you're right, and it's time to start looking at it again.
> Now Weston is a bit more mature/capable, the desktop environments have
> caught up and are at the point where it makes sense for them to look
> at it, and we have wayland-protocols rather than the old
> weston/protocols/ dumping ground, it's probably the right time.

i'm curious... is the intent to make it requird that all compositors support
color management (and thus have to support all the possible colorspaces
defined)... or are we going to go the path of:

99% of apps won't care so color correction is an optional extra and apps need
to query for the support then adapt appropriately (and always fall back to SRGB
as is defined as the default if it's not supported)?

what is the path/intent for this?

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland-protocols] Color management protocol

[Graeme Gill]

Carsten Haitzler (The Rasterman) wrote:

> i'm curious... is the intent to make it requird that all compositors support
> color management (and thus have to support all the possible colorspaces
> defined)... or are we going to go the path of:

I'd be happy if there was support for core color management (i.e. application
color management), before adding layers that depend on the core.

Graeme Gill.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland-protocols] Color management protocol

[The Rasterman]

On Thu, 8 Dec 2016 17:32:37 +1100 Graeme Gill  said:

> Carsten Haitzler (The Rasterman) wrote:
> 
> > i'm curious... is the intent to make it requird that all compositors support
> > color management (and thus have to support all the possible colorspaces
> > defined)... or are we going to go the path of:
> 
> I'd be happy if there was support for core color management (i.e. application
> color management), before adding layers that depend on the core.

but is the intent that compositors MUST support color management and
applications will fail entirely or fail to display even partly correctly if
compositor doesnt support color management or doesnt support the color
profile/space requested by the client? or will it be expected that apps need to
always be able to convert to sRGB for compatibility and then have added
colorspace capabilities if it's supported? what is the intent?

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland-protocols] Color management protocol

[Graeme Gill]

Carsten Haitzler (The Rasterman) wrote:

Hi,

> but is the intent that compositors MUST support color management and
> applications will fail entirely or fail to display even partly correctly if
> compositor doesnt support color management or doesnt support the color
> profile/space requested by the client?

My intent is directly the opposite.

An application could choose to fail if core color management is not
present, or fall back into a non-color managed mode. An application
that wants to use Enhance color management and finds it is not present,
could fall back to application color management (although it probably
wouldn't, because it doesn't want to work that hard), or fall back
into a non-color managed mode.

> or will it be expected that apps need to
> always be able to convert to sRGB for compatibility and then have added
> colorspace capabilities if it's supported? what is the intent?

I thought I'd explained this in the previous post ? - perhaps
I'm simply not understanding where you are coming from on this.

The intent is to enable proper color management. In general, only
the application will be able to do this to its own satisfaction,
so core color management is essential. Providing enhanced color
management is a convenience to applications that don't wish to
implement their own color management and are content with
quite limited set of capabilities, as well as making available
a facility to force default color management onto applications
that are not color aware.

If this doesn't make sense to you, then perhaps the best thing
would be for me to lay out the nuts and bolts of what's happening
in these different color management scenarios.

Cheers,

Graeme Gill.


___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland-protocols] Color management protocol

[Niels Ole Salscheider]

Am Freitag, 9. Dezember 2016, 12:02:07 CET schrieb Carsten Haitzler:
> On Thu, 8 Dec 2016 17:32:37 +1100 Graeme Gill  said:
> > Carsten Haitzler (The Rasterman) wrote:
> > > i'm curious... is the intent to make it requird that all compositors
> > > support color management (and thus have to support all the possible
> > > colorspaces> 
> > > defined)... or are we going to go the path of:
> > I'd be happy if there was support for core color management (i.e.
> > application color management), before adding layers that depend on the
> > core.
> 
> but is the intent that compositors MUST support color management and
> applications will fail entirely or fail to display even partly correctly if
> compositor doesnt support color management or doesnt support the color
> profile/space requested by the client? or will it be expected that apps need
> to always be able to convert to sRGB for compatibility and then have added
> colorspace capabilities if it's supported? what is the intent?

We can't make support for this protocol mandatory because color correction 
might be too much overhead for compositors for embedded devices.

But I would say that every compositor that does some sort of color correction 
should also implement the color management protocol.
If the protocol is not supported by the compositor you would assume that you 
have to output the colors in the device color space (or just ignore it if you 
do not care about accurate colors).
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland-protocols] Color management protocol

[Niels Ole Salscheider]

Am Donnerstag, 8. Dezember 2016, 13:33:20 CET schrieb Graeme Gill:
> Niels Ole Salscheider wrote:
> 
> Hi,
> 
> > The first version of my proposal had such a flag. I removed it and
> > replaced it by the described version based on feedback from Zoxc
> > (zox...@gmail.com).
> Do you have a link to the specifics ?

Most of the discussion happened on IRC back then. It should be in the logs 
but...

> > I can see advantages with both solutions. One advantage with the current
> > proposal is that you can have a surface that covers multiple screens. In
> > this case the compositor can still try its best to correct the colours
> > for all but the main screen.
> 
> I'm not quite sure what you mean. Generally an application will have
> specific reasons for wanting to do it's own color management - for
> instance, perhaps it is previewing a CMYKOGlclm file, and wants to
> treat out of gamut mapping and black point mapping in a particular way, etc.
> I don't think the Wayland compositor is going to be expected to handle
> CMYKOGlclm etc. input rasters, never mind all the requirements of
> specialist application color management!

This is of course something that the client application has to do. It would 
query the main output for its surface, do the conversions to that color space 
and then attach the output color space to the surface.

The compositor now must not touch the parts of the surface on the main output 
(where the color spaces match). But it could still try to convert from the 
color space of the main output to that of a secondary screen if the surface 
covers two screens with different color profiles.

This might of course cause artifacts when one of the screens has a too small 
gamut but still seems better than ignoring this.

But then again most people that work with professional applications would not 
make them cover multiple screens, I guess. Therefore I'm not opposed to adding 
a flag that indicates that the application wants to disable color corrections 
completely for that surface, independent of the output.

> Which is not to say that compositor color management doesn't have its
> place - it is ideal for applications that just want to use "RGB", and
> not deal with specific display behavior.

Very simple applications would just keep the attached sRGB color space and 
maybe place images on subsurfaces with the embedded color space from the image 
attached.

Applications that care a bit more about color correction (but do not have 
professional needs) could convert all their colors to the blending color space 
of the compositor. I'd expect this blending color space to be linear if the 
compositor cares about good colors.
This would have the advantage that the compositor does not have to do the 
conversion "application output color space -> blending color space".

> > Back then I argued that this might not be good enough if you want to
> > calibrate the monitor. But the consent was that this would require
> > another protocol to disable all colour corrections anyway and that it
> > could be developed at a later point.
> 
> I strongly disagree with this idea - disabling application-side color
> management is a fundamental step in achieving end to end color management.
> You don't have color management until you are able to profile the output
> device, so this is not something that can be left until latter!
> 
> Graeme Gill.
> 
> 
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel


___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland-protocols] Color management protocol

[Niels Ole Salscheider]

Am Donnerstag, 8. Dezember 2016, 15:51:12 CET schrieb Graeme Gill:
> Niels Ole Salscheider wrote:
> > Therefore I think that the situation has changed and I'd like to propose
> > this protocol for inclusion in wayland-protocols again.
> > What do you think?
> 
> Hi,
>   I'm prompted to look into the current state of color management
> in Wayland, by Richard Hughes comment on the ArgyllCMS mailing list
> 
> recently that:
> > About this; in the near future systems will be migrating from X11 to
> > Wayland (Fedora 25 already defaults to Wayland, other distros will
> > follow) and so setting X atoms is no longer going to work. Even with
> > XWayland (the compatibility "wrapper" that provides an isolated
> > xserver for the app) you can't use the root window as it's isolated
> > from the other windows. I think most applications that want to know
> > what profile to use are now using either libcolord, or more commonly,
> > the colord DBus API.
> 
> What I take from this is that XWayland is lacking in its emulation
> of existing X11 color management protocols (primarily due to lack
> of underlying support in Wayland), and that currently the only
> option for pure Wayland applications is to depend on system
> specific work-arounds such as using Weston with colord. I can
> therefore see that users that depend on color managed X11 applications
> (such as photographers, desktop publishers, video editors etc.)
> aren't going to be switching to Wayland based systems any
> time soon.
> 
> Looking through the current Wayland color-management protocol
> proposal, I think it is missing a really fundamental thing -
> managing the output device color calibration state and color
> profile. I guess the assumption is that this is being done
> by colord, but my understanding is that colord is specific
> to Gnome based systems, and certainly depends on DBus, which
> Wayland does not. [ Please correct me if I've got any of this wrong. ]

It is (currently) up to the compositor to decide how to implement this. The 
compositor could come with its own settings for the output color profiles or 
query some other program. This might be colord, but it could also be 
kolormanager, or something else.

> It also seems fundamentally poor design to be using a parallel
> protocol to manage the color of the graphics system, rather
> than it being kept in sync with the elements being managed,
> such as outputs and pixel rasters, etc. Certainly in X11 it is
> all kept within the X11 protocol or its extensions.
> If Wayland gets extended to be a remote protocol, then
> the existence of in band protocols for color management
> become even more important.

Yes, with the protocol I proposed there is a (small) time window after 
changing the output color space where the application might still display 
surfaces with the old color space...

> So as a broad outline, what I would regard as features of
> a reasonable color management facility for a graphics
> system such as Wayland are:
> 
> * That color management protocol's have two uses :- 1) configuring
>   color management and 2) allowing applications to use color management.
>   These two uses may need different security profiles.
>   The assumption should be that color management applications
>   used to create calibrations, profiles and configure the
>   state of color management, are of equal importance to color
>   managed applications that depend on a properly profiled and
>   configured color management system, since you can't have latter
>   with out the former.
> 
> * Color management of a graphics rendering system such as Wayland
>   should be split into two levels (possibly two extensions) :-
> 
>   1) Core == output device management, which involves identifying output
> devices, controlling their calibration state (Video LUT), installing a
> color profile resources associated with that output device, and identifying
> which rendered pixels go to which output device(s). This is the most basic
> requirement, since this is the bare minimum for applications to be properly
> color managed. It is also a necessary resource for the second level to be
> able to operate.
> 
>   2) Enhanced == input space management, which assumes a graphics
>   server rendering system capable of color management. This involves
> labeling an input raster with a color profile, and controlling the manner
> of rendering (i.e. rendering intent, maybe blending space ? etc.) This is
> useful for implementing default color management (e.g. as a means of coping
> with wide gamut displays when many applications are not color aware), or as
> a low developer overhead means of implementing basic color management in
> non color critical applications.
> 
> Translating these aims into a more concrete set of capabilities might
> look like this:
> 
> Core:
>   Get corresponding CRTC regions for a given Surface.
>   Get corresponding Output(s) for a CRTC.
>   Get unique Monitor identifier for an Output (i.e. EDID)
>  

Re: [RFC wayland-protocols] Color management protocol

[The Rasterman]

On Fri, 09 Dec 2016 14:06:46 +0100 Niels Ole Salscheider
 said:

> Am Freitag, 9. Dezember 2016, 12:02:07 CET schrieb Carsten Haitzler:
> > On Thu, 8 Dec 2016 17:32:37 +1100 Graeme Gill  said:
> > > Carsten Haitzler (The Rasterman) wrote:
> > > > i'm curious... is the intent to make it requird that all compositors
> > > > support color management (and thus have to support all the possible
> > > > colorspaces> 
> > > > defined)... or are we going to go the path of:
> > > I'd be happy if there was support for core color management (i.e.
> > > application color management), before adding layers that depend on the
> > > core.
> > 
> > but is the intent that compositors MUST support color management and
> > applications will fail entirely or fail to display even partly correctly if
> > compositor doesnt support color management or doesnt support the color
> > profile/space requested by the client? or will it be expected that apps need
> > to always be able to convert to sRGB for compatibility and then have added
> > colorspace capabilities if it's supported? what is the intent?
> 
> We can't make support for this protocol mandatory because color correction 
> might be too much overhead for compositors for embedded devices.

well graeme disagrees and effectively thinks it should be. :)

> But I would say that every compositor that does some sort of color correction 
> should also implement the color management protocol.
> If the protocol is not supported by the compositor you would assume that you 
> have to output the colors in the device color space (or just ignore it if you 
> do not care about accurate colors).
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel


-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland-protocols] Color management protocol

[The Rasterman]

On Fri, 09 Dec 2016 14:38:37 +0100 Niels Ole Salscheider
 said:

> Am Donnerstag, 8. Dezember 2016, 15:51:12 CET schrieb Graeme Gill:
> > Niels Ole Salscheider wrote:
> > > Therefore I think that the situation has changed and I'd like to propose
> > > this protocol for inclusion in wayland-protocols again.
> > > What do you think?
> > 
> > Hi,
> > I'm prompted to look into the current state of color management
> > in Wayland, by Richard Hughes comment on the ArgyllCMS mailing list
> > 
> > recently that:
> > > About this; in the near future systems will be migrating from X11 to
> > > Wayland (Fedora 25 already defaults to Wayland, other distros will
> > > follow) and so setting X atoms is no longer going to work. Even with
> > > XWayland (the compatibility "wrapper" that provides an isolated
> > > xserver for the app) you can't use the root window as it's isolated
> > > from the other windows. I think most applications that want to know
> > > what profile to use are now using either libcolord, or more commonly,
> > > the colord DBus API.
> > 
> > What I take from this is that XWayland is lacking in its emulation
> > of existing X11 color management protocols (primarily due to lack
> > of underlying support in Wayland), and that currently the only
> > option for pure Wayland applications is to depend on system
> > specific work-arounds such as using Weston with colord. I can
> > therefore see that users that depend on color managed X11 applications
> > (such as photographers, desktop publishers, video editors etc.)
> > aren't going to be switching to Wayland based systems any
> > time soon.
> > 
> > Looking through the current Wayland color-management protocol
> > proposal, I think it is missing a really fundamental thing -
> > managing the output device color calibration state and color
> > profile. I guess the assumption is that this is being done
> > by colord, but my understanding is that colord is specific
> > to Gnome based systems, and certainly depends on DBus, which
> > Wayland does not. [ Please correct me if I've got any of this wrong. ]
> 
> It is (currently) up to the compositor to decide how to implement this. The 
> compositor could come with its own settings for the output color profiles or 
> query some other program. This might be colord, but it could also be 
> kolormanager, or something else.
> 
> > It also seems fundamentally poor design to be using a parallel
> > protocol to manage the color of the graphics system, rather
> > than it being kept in sync with the elements being managed,
> > such as outputs and pixel rasters, etc. Certainly in X11 it is
> > all kept within the X11 protocol or its extensions.
> > If Wayland gets extended to be a remote protocol, then
> > the existence of in band protocols for color management
> > become even more important.
> 
> Yes, with the protocol I proposed there is a (small) time window after 
> changing the output color space where the application might still display 
> surfaces with the old color space...

wouldn't it be best not to explicitly ask for an output colorspace and just
provide the colorspace of your buffer and let the compositor decide? e.g. if
your window is on top, or it's the largest one, or it's focused,then the
compositor MAY switch the colorspace of that monitor to match your surface's
buffer colorspace, and if it goes into the background or whatever, switch back?
it can (and likely should) emulato other colorspaced then.

e.g. if buffer is adobe rgb, then switch display to work in adobe rgb but
re-render everything else that is sRGB into adobe argb space... there might be
a slight "flicker" so to speak as maybe some banding appears in some gradients
of SRGB windows or colors are ever so slightly off, but the compositor is
optimizing for the surface it thinks it most important. i really don't like the
idea of applications explicitly controlling screen colorspace. simple being
able to list colorspaces available, know which might be native or emulated, and
then say which colorspace their buffer has. this way colorspace is tired
directly to the buffer and the compositor can avoid these glitches (like time
difference between switching screen colorspace and buffers actually being
provided in that colorspace).

> > So as a broad outline, what I would regard as features of
> > a reasonable color management facility for a graphics
> > system such as Wayland are:
> > 
> > * That color management protocol's have two uses :- 1) configuring
> >   color management and 2) allowing applications to use color management.
> >   These two uses may need different security profiles.
> >   The assumption should be that color management applications
> >   used to create calibrations, profiles and configure the
> >   state of color management, are of equal importance to color
> >   managed applications that depend on a properly profiled and
> >   configured color management system, since you can't have latter
> >   with out the former.
> > 
> > * Col

Re: [RFC wayland-protocols] Color management protocol

[The Rasterman]

On Fri, 09 Dec 2016 14:29:14 +0100 Niels Ole Salscheider
 said:

> Am Donnerstag, 8. Dezember 2016, 13:33:20 CET schrieb Graeme Gill:
> > Niels Ole Salscheider wrote:
> > 
> > Hi,
> > 
> > > The first version of my proposal had such a flag. I removed it and
> > > replaced it by the described version based on feedback from Zoxc
> > > (zox...@gmail.com).
> > Do you have a link to the specifics ?
> 
> Most of the discussion happened on IRC back then. It should be in the logs 
> but...
> 
> > > I can see advantages with both solutions. One advantage with the current
> > > proposal is that you can have a surface that covers multiple screens. In
> > > this case the compositor can still try its best to correct the colours
> > > for all but the main screen.
> > 
> > I'm not quite sure what you mean. Generally an application will have
> > specific reasons for wanting to do it's own color management - for
> > instance, perhaps it is previewing a CMYKOGlclm file, and wants to
> > treat out of gamut mapping and black point mapping in a particular way, etc.
> > I don't think the Wayland compositor is going to be expected to handle
> > CMYKOGlclm etc. input rasters, never mind all the requirements of
> > specialist application color management!
> 
> This is of course something that the client application has to do. It would 
> query the main output for its surface, do the conversions to that color space 
> and then attach the output color space to the surface.
> 
> The compositor now must not touch the parts of the surface on the main output 
> (where the color spaces match). But it could still try to convert from the 
> color space of the main output to that of a secondary screen if the surface 
> covers two screens with different color profiles.
> 
> This might of course cause artifacts when one of the screens has a too small 
> gamut but still seems better than ignoring this.
> 
> But then again most people that work with professional applications would not 
> make them cover multiple screens, I guess. Therefore I'm not opposed to
> adding a flag that indicates that the application wants to disable color
> corrections completely for that surface, independent of the output.

why not simply let the compositor decide. if a surface spans multile screens it
may have to emulate on another screen (egh one screen can do adobe arg, another
is ye-olde sRGB). this is simply a matter of letting the compositor know what
colorspace the rgb values are in so it can "do the appropriate thing". :)

> > Which is not to say that compositor color management doesn't have its
> > place - it is ideal for applications that just want to use "RGB", and
> > not deal with specific display behavior.
> 
> Very simple applications would just keep the attached sRGB color space and 
> maybe place images on subsurfaces with the embedded color space from the
> image attached.
> 
> Applications that care a bit more about color correction (but do not have 
> professional needs) could convert all their colors to the blending color
> space of the compositor. I'd expect this blending color space to be linear if
> the compositor cares about good colors.
> This would have the advantage that the compositor does not have to do the 
> conversion "application output color space -> blending color space".

if compositor just lists what colorspaces it can do, which happen to have
native hardware support (i.e. the display panel itself is capable of it), then
client can choose whatever works best, and compositor just "does its best" too
which may mean adjusting dislpay gammut or output transforms at the gpu level
or via side-bad protocols with the display panel itself if that were to exist.

> > > Back then I argued that this might not be good enough if you want to
> > > calibrate the monitor. But the consent was that this would require
> > > another protocol to disable all colour corrections anyway and that it
> > > could be developed at a later point.
> > 
> > I strongly disagree with this idea - disabling application-side color
> > management is a fundamental step in achieving end to end color management.
> > You don't have color management until you are able to profile the output
> > device, so this is not something that can be left until latter!
> > 
> > Graeme Gill.
> > 
> > 
> > ___
> > wayland-devel mailing list
> > wayland-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/wayland-devel
> 
> 
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel


-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland-protocols] Color management protocol

[The Rasterman]

On Fri, 9 Dec 2016 15:30:40 +1100 Graeme Gill  said:

> Carsten Haitzler (The Rasterman) wrote:
> 
> Hi,
> 
> > but is the intent that compositors MUST support color management and
> > applications will fail entirely or fail to display even partly correctly if
> > compositor doesnt support color management or doesnt support the color
> > profile/space requested by the client?
> 
> My intent is directly the opposite.
> 
> An application could choose to fail if core color management is not
> present, or fall back into a non-color managed mode. An application
> that wants to use Enhance color management and finds it is not present,
> could fall back to application color management (although it probably
> wouldn't, because it doesn't want to work that hard), or fall back
> into a non-color managed mode.
> 
> > or will it be expected that apps need to
> > always be able to convert to sRGB for compatibility and then have added
> > colorspace capabilities if it's supported? what is the intent?
> 
> I thought I'd explained this in the previous post ? - perhaps
> I'm simply not understanding where you are coming from on this.

you didn't explain before if the point is for this to be mandatory or optional.

above you basically say it has to be mandatory as applications will then fail
to run (at least some set of them might).

when you add extra features like new colorspace support, people writing apps
and toolkits nee to know what the expectation is. can they just assume it will
work, or do they need to have a fallback path on their side.

compositor writers need to know too. if color management is mandatory then
their compositor is basically broken until they add it.

> The intent is to enable proper color management. In general, only
> the application will be able to do this to its own satisfaction,
> so core color management is essential. Providing enhanced color
> management is a convenience to applications that don't wish to
> implement their own color management and are content with
> quite limited set of capabilities, as well as making available
> a facility to force default color management onto applications
> that are not color aware.

i don't see a difference between enhanced and core. color management means:

1. being able to report what colorspace is "default" on the display right now
(and what may be able to be enabled possible at request).
2. being able to report what colorspaces are supported at all (either natively
by the display or by emulation)
3. the ability for a client to define a specific colorspace for a buffer. (the
choice of the colorspace of the display itself should be left to the
compositor).

the only difference is the set of colorspaces wanted by client and by supported
by compositor. core and enhanced are arbitrary labels. what matters is a
common colorspace. right now in wayland it's all sRGB so everyone agrees (i'm
ignoring yuv etc. buffer formats. just talking RGB ones).

so the questions are:

  * if all of these above are missing: what happens?
  * if the list of colorspaces natively supported by the screen does not have a
common set of colorspaces the client wants: what happens?
  * if the list of all colorspaces (native or emulated) by the compositor does
not have a common set with the client: what happens?

should a client fall back to sRGB is that the intent and otherwise get enhanced
display if color management is there? should a client just give up and exit or
display nothing?

you say the latter. a client can choose to fail entirely, which imho leads to a
far poorer outcome for the user. the vast majority of users out there in the
world have a non-calibrated dumb monitor or maybe don't even have a choice
in screen since it's built in (tablet, phone, laptop, watch ... fridge) and
that's all they will ever have. if this is just intended for enhanced support
then i think this is good.

> If this doesn't make sense to you, then perhaps the best thing
> would be for me to lay out the nuts and bolts of what's happening
> in these different color management scenarios.

what i want to know if how mandatory will this be, as most users will never
have a scenario where their display can do more than "dumb" sRGB and any
compositor claiming to support colorspaces will have to convert down to sRGB
anyway, and if clients start exiting because the compositor is being honest and
saying that that colorspace cant be supported, then this will eventually lead
to compositors lying and claiming all these colorspaces work/are native to stop
apps exiting, and so now all you do is add overhead to work around client apps
that are just behaving badly.

if this is mandatory as you say, then i dislike this protocol very much. if
it's optional then i think it's good.

> Cheers,
> 
> Graeme Gill.
> 
> 
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel


-- 
- Codito

Re: [RFC wayland-protocols] Color management protocol

[Niels Ole Salscheider]

On Saturday, 10 December 2016, 11:48:32 CET, Carsten Haitzler wrote:
> On Fri, 09 Dec 2016 14:38:37 +0100 Niels Ole Salscheider
> 
>  said:
> > Am Donnerstag, 8. Dezember 2016, 15:51:12 CET schrieb Graeme Gill:
> > > Niels Ole Salscheider wrote:
> > > > Therefore I think that the situation has changed and I'd like to
> > > > propose
> > > > this protocol for inclusion in wayland-protocols again.
> > > > What do you think?
> > > 
> > > Hi,
> > > 
> > >   I'm prompted to look into the current state of color management
> > > 
> > > in Wayland, by Richard Hughes comment on the ArgyllCMS mailing list
> > > 
> > > recently that:
> > > > About this; in the near future systems will be migrating from X11 to
> > > > Wayland (Fedora 25 already defaults to Wayland, other distros will
> > > > follow) and so setting X atoms is no longer going to work. Even with
> > > > XWayland (the compatibility "wrapper" that provides an isolated
> > > > xserver for the app) you can't use the root window as it's isolated
> > > > from the other windows. I think most applications that want to know
> > > > what profile to use are now using either libcolord, or more commonly,
> > > > the colord DBus API.
> > > 
> > > What I take from this is that XWayland is lacking in its emulation
> > > of existing X11 color management protocols (primarily due to lack
> > > of underlying support in Wayland), and that currently the only
> > > option for pure Wayland applications is to depend on system
> > > specific work-arounds such as using Weston with colord. I can
> > > therefore see that users that depend on color managed X11 applications
> > > (such as photographers, desktop publishers, video editors etc.)
> > > aren't going to be switching to Wayland based systems any
> > > time soon.
> > > 
> > > Looking through the current Wayland color-management protocol
> > > proposal, I think it is missing a really fundamental thing -
> > > managing the output device color calibration state and color
> > > profile. I guess the assumption is that this is being done
> > > by colord, but my understanding is that colord is specific
> > > to Gnome based systems, and certainly depends on DBus, which
> > > Wayland does not. [ Please correct me if I've got any of this wrong. ]
> > 
> > It is (currently) up to the compositor to decide how to implement this.
> > The
> > compositor could come with its own settings for the output color profiles
> > or query some other program. This might be colord, but it could also be
> > kolormanager, or something else.
> > 
> > > It also seems fundamentally poor design to be using a parallel
> > > protocol to manage the color of the graphics system, rather
> > > than it being kept in sync with the elements being managed,
> > > such as outputs and pixel rasters, etc. Certainly in X11 it is
> > > all kept within the X11 protocol or its extensions.
> > > If Wayland gets extended to be a remote protocol, then
> > > the existence of in band protocols for color management
> > > become even more important.
> > 
> > Yes, with the protocol I proposed there is a (small) time window after
> > changing the output color space where the application might still display
> > surfaces with the old color space...
> 
> wouldn't it be best not to explicitly ask for an output colorspace and just
> provide the colorspace of your buffer and let the compositor decide? e.g. if
> your window is on top, or it's the largest one, or it's focused,then the
> compositor MAY switch the colorspace of that monitor to match your
> surface's buffer colorspace, and if it goes into the background or
> whatever, switch back? it can (and likely should) emulato other colorspaced
> then.

I think there is a misconception here. For normal applications it would work 
like this:
surface color space -> blending colorspace (where the compositor does 
blending) -> output color space.
If the application is fullscreen then the compositor does not need to do 
blending and can just do the surface color space -> output color space 
conversion.

But Graeme talked about professional applications that want to do color 
management on their own because they have more complex needs.
These application would query the output color space of the screen that they 
are currently on and do all conversions on their own.
These applications would not want the compositor to do anything to the colors 
and indicate this (implicitly) by setting the surface color space to the 
output colorspace.

> e.g. if buffer is adobe rgb, then switch display to work in adobe rgb but
> re-render everything else that is sRGB into adobe argb space... there might
> be a slight "flicker" so to speak as maybe some banding appears in some
> gradients of SRGB windows or colors are ever so slightly off, but the
> compositor is optimizing for the surface it thinks it most important. i
> really don't like the idea of applications explicitly controlling screen
> colorspace. simple being able to list colorspaces available, know whic

Re: [RFC wayland-protocols] Color management protocol

[Niels Ole Salscheider]

On Friday, 9 December 2016, 11:20:14 CET, Bill Spitzak wrote:
> On Fri, Dec 9, 2016 at 5:29 AM, Niels Ole Salscheider
> 
>  wrote:
> > Applications that care a bit more about color correction (but do not have
> > professional needs) could convert all their colors to the blending color
> > space of the compositor. I'd expect this blending color space to be
> > linear if the compositor cares about good colors.
> > This would have the advantage that the compositor does not have to do the
> > conversion "application output color space -> blending color space".
> 
> Actually it is quite likely that the compositor may use a "blending
> space" that is *not* the preferred colorspace of the buffers. For
> instance just using OpenGL sRGB sampling for the input and output
> textures will cause a linear "blending space" while all the buffers
> are using sRGB gamma. Even on the CPU it is reasonably efficient to do
> this conversion as part of the composite, especially if you are
> willing to have some inaccuracy in the effective power functions.

Maybe I should reword it then. The intention of allowing to query the blending 
space was to tell applications the preferred color space of a surface. That 
is, if they do any color management they should create surfaces with that 
color space to minimize computing time.

Anyway, this preferred space should probably not be sRGB if the compositor 
cares about accurate colors. This is because there are many monitors that have 
wider gamuts and you would clip the colors at that point.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland-protocols] Color management protocol

[The Rasterman]

On Sat, 10 Dec 2016 09:50:53 +0100 Niels Ole Salscheider
 said:

> On Saturday, 10 December 2016, 11:48:32 CET, Carsten Haitzler wrote:
> > On Fri, 09 Dec 2016 14:38:37 +0100 Niels Ole Salscheider
> > 
> >  said:
> > > Am Donnerstag, 8. Dezember 2016, 15:51:12 CET schrieb Graeme Gill:
> > > > Niels Ole Salscheider wrote:
> > > > > Therefore I think that the situation has changed and I'd like to
> > > > > propose
> > > > > this protocol for inclusion in wayland-protocols again.
> > > > > What do you think?
> > > > 
> > > > Hi,
> > > > 
> > > > I'm prompted to look into the current state of color management
> > > > 
> > > > in Wayland, by Richard Hughes comment on the ArgyllCMS mailing list
> > > > 
> > > > recently that:
> > > > > About this; in the near future systems will be migrating from X11 to
> > > > > Wayland (Fedora 25 already defaults to Wayland, other distros will
> > > > > follow) and so setting X atoms is no longer going to work. Even with
> > > > > XWayland (the compatibility "wrapper" that provides an isolated
> > > > > xserver for the app) you can't use the root window as it's isolated
> > > > > from the other windows. I think most applications that want to know
> > > > > what profile to use are now using either libcolord, or more commonly,
> > > > > the colord DBus API.
> > > > 
> > > > What I take from this is that XWayland is lacking in its emulation
> > > > of existing X11 color management protocols (primarily due to lack
> > > > of underlying support in Wayland), and that currently the only
> > > > option for pure Wayland applications is to depend on system
> > > > specific work-arounds such as using Weston with colord. I can
> > > > therefore see that users that depend on color managed X11 applications
> > > > (such as photographers, desktop publishers, video editors etc.)
> > > > aren't going to be switching to Wayland based systems any
> > > > time soon.
> > > > 
> > > > Looking through the current Wayland color-management protocol
> > > > proposal, I think it is missing a really fundamental thing -
> > > > managing the output device color calibration state and color
> > > > profile. I guess the assumption is that this is being done
> > > > by colord, but my understanding is that colord is specific
> > > > to Gnome based systems, and certainly depends on DBus, which
> > > > Wayland does not. [ Please correct me if I've got any of this wrong. ]
> > > 
> > > It is (currently) up to the compositor to decide how to implement this.
> > > The
> > > compositor could come with its own settings for the output color profiles
> > > or query some other program. This might be colord, but it could also be
> > > kolormanager, or something else.
> > > 
> > > > It also seems fundamentally poor design to be using a parallel
> > > > protocol to manage the color of the graphics system, rather
> > > > than it being kept in sync with the elements being managed,
> > > > such as outputs and pixel rasters, etc. Certainly in X11 it is
> > > > all kept within the X11 protocol or its extensions.
> > > > If Wayland gets extended to be a remote protocol, then
> > > > the existence of in band protocols for color management
> > > > become even more important.
> > > 
> > > Yes, with the protocol I proposed there is a (small) time window after
> > > changing the output color space where the application might still display
> > > surfaces with the old color space...
> > 
> > wouldn't it be best not to explicitly ask for an output colorspace and just
> > provide the colorspace of your buffer and let the compositor decide? e.g. if
> > your window is on top, or it's the largest one, or it's focused,then the
> > compositor MAY switch the colorspace of that monitor to match your
> > surface's buffer colorspace, and if it goes into the background or
> > whatever, switch back? it can (and likely should) emulato other colorspaced
> > then.
> 
> I think there is a misconception here. For normal applications it would work 
> like this:
> surface color space -> blending colorspace (where the compositor does 
> blending) -> output color space.
> If the application is fullscreen then the compositor does not need to do 
> blending and can just do the surface color space -> output color space 
> conversion.

actually... all the major toolkits and apps work in ARGB premul (which is SRGB
with gamma 2.2 or whatever - the non-linear one). they actually work natively
in that space so they are producing what i have, for short, called "sRGB
buffers" (sARGB premul?). so this is currently the native colorspace for all
wayland compositors, client buffers AND for actual monitors.

what we're talking about here is clients providing buffers in ANOTHER RGB
colorspace. this is exactly the same as YUV (actually there's BT601 and BT709
YUV/YCbCr colorspace depending on SD vs HD, and in fact there's also now a
BT2020 for UHD. in fact this is a problem in wayland right now as there way i
know of to distinguish the colorspace of a YUV buffer - is

Re: [RFC wayland-protocols] Color management protocol

[Graeme Gill]

Niels Ole Salscheider wrote:

> But I would say that every compositor that does some sort of color correction 
> should also implement the color management protocol.

> If the protocol is not supported by the compositor you would assume that you 
> have to output the colors in the device color space (or just ignore it if you 
> do not care about accurate colors).

I want to see the latter supported before the former.

Graeme Gill.

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland-protocols] Color management protocol

[Graeme Gill]

Niels Ole Salscheider wrote:
> Am Donnerstag, 8. Dezember 2016, 13:33:20 CET schrieb Graeme Gill:

Hi,

>> I'm not quite sure what you mean. Generally an application will have
>> specific reasons for wanting to do it's own color management - for
>> instance, perhaps it is previewing a CMYKOGlclm file, and wants to
>> treat out of gamut mapping and black point mapping in a particular way, etc.
>> I don't think the Wayland compositor is going to be expected to handle
>> CMYKOGlclm etc. input rasters, never mind all the requirements of
>> specialist application color management!
> 
> This is of course something that the client application has to do. It would 
> query the main output for its surface, do the conversions to that color space 
> and then attach the output color space to the surface.

Right. So a protocol for querying the profile of each output for its surface is
a base requirement.

> The compositor now must not touch the parts of the surface on the main output 
> (where the color spaces match). But it could still try to convert from the 
> color space of the main output to that of a secondary screen if the surface 
> covers two screens with different color profiles.

Not as a base requirement. The application needs to be able to
do it's own color management, which means color managing for
every output the surface goes to. So the base requirement
has no rendering requirement for a composer - it's just
about signalling the required information to the client application.

> But then again most people that work with professional applications would not 
> make them cover multiple screens, I guess.

People using color managed applications expect color management to work as
best it can across multiple screens.

> Therefore I'm not opposed to adding 
> a flag that indicates that the application wants to disable color corrections 
> completely for that surface, independent of the output.

This is only something that becomes a question at the next
level, where there is an expectation that the composer
has some degree of color management capability.

>> Which is not to say that compositor color management doesn't have its
>> place - it is ideal for applications that just want to use "RGB", and
>> not deal with specific display behavior.
> 
> Very simple applications would just keep the attached sRGB color space and 
> maybe place images on subsurfaces with the embedded color space from the 
> image 
> attached.

That works only in the case that the composer supports the image colorspaces.
This may well be the case for some applications (i.e. web browsers), but
I imagine it may not be desirable to insist that all composers supporting
a color management capability, support a full range of colorspaces (N - color 
in general).

> Applications that care a bit more about color correction (but do not have 
> professional needs) could convert all their colors to the blending color 
> space 
> of the compositor. I'd expect this blending color space to be linear if the 
> compositor cares about good colors.

It's not clear to me that any application that is interested in good
color would trust it to blending operations.

I'd also imagine that there is a class of applications wishing to get the
compositor to deal with gross display differences (Wide gamut vs.
sRGB-like for instance) but is not interested enough in exactly what's going
on color wise to be aware of the distinctions between linear light space
compositing and other approaches.

Cheers,

Graeme Gill.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland-protocols] Color management protocol

[Graeme Gill]

Niels Ole Salscheider wrote:
> Am Donnerstag, 8. Dezember 2016, 15:51:12 CET schrieb Graeme Gill:

>> Looking through the current Wayland color-management protocol
>> proposal, I think it is missing a really fundamental thing -
>> managing the output device color calibration state and color
>> profile. I guess the assumption is that this is being done
>> by colord, but my understanding is that colord is specific
>> to Gnome based systems, and certainly depends on DBus, which
>> Wayland does not. [ Please correct me if I've got any of this wrong. ]

> It is (currently) up to the compositor to decide how to implement this. The 
> compositor could come with its own settings for the output color profiles or 
> query some other program. This might be colord, but it could also be 
> kolormanager, or something else.

1) This doesn't address how this information is communicated
   to a Wayland application.

2) Expecting color management applications to deal with
   configuring the compositor in a platform dependent
   way, is expecting far too much. I for one am not
   about to add multiple platform dependent back
   ends (multiple flavors of Linux, BSD's, Android,
   etc.) to my tools to do this, and no other major
   platform expects it (i.e. none of MSWindows, OS X
   or X11 based systems have this requirement.)

The correct approach to avoiding such issues is simply
to make both aspects Wayland (extension) protocols, so
that Wayland color management and color sensitive applications
have the potential to work across all Wayland systems,
rather than being at best balkanized, or at worst, not
supported.

Graeme Gill.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland-protocols] Color management protocol

[The Rasterman]

On Mon, 12 Dec 2016 17:57:08 +1100 Graeme Gill  said:

> Niels Ole Salscheider wrote:
> > Am Donnerstag, 8. Dezember 2016, 13:33:20 CET schrieb Graeme Gill:
> 
> Hi,
> 
> >> I'm not quite sure what you mean. Generally an application will have
> >> specific reasons for wanting to do it's own color management - for
> >> instance, perhaps it is previewing a CMYKOGlclm file, and wants to
> >> treat out of gamut mapping and black point mapping in a particular way,
> >> etc. I don't think the Wayland compositor is going to be expected to handle
> >> CMYKOGlclm etc. input rasters, never mind all the requirements of
> >> specialist application color management!
> > 
> > This is of course something that the client application has to do. It would 
> > query the main output for its surface, do the conversions to that color
> > space and then attach the output color space to the surface.
> 
> Right. So a protocol for querying the profile of each output for its surface
> is a base requirement.

i totally disagree. the compositor should simply provide available colorspaces
(and generally only provide those that hardware can do). what screen they apply
to is unimportant.

if the colorspace is native to that display or possible, the compositor will do
NO CONVERSION of your pixel data and display directly (and instead convert sRGB
data into that colorspace). if your surface spans 2 screens the compositor may
convert some to the colorspace of a monitor if it does not support that
colorspace. choose the colorspace (as a client) that matches your data best.
compositor will do a "best effort".

this way client doesnt need to know about outputs, which outputs it spans etc.
and compositor will pick up the pieces. let me give some more complex examples:

compositor has a mirroring mode where it can mirror a window across multiple
screens. some screens can or cannot do color management. what do you do now?
compositor may display your window in a pager that is duplicated across
multiple screens and thus the content of that window should be rendered
correctly. what happens when the colorspace changes on the fly (you recalbrate
the screen or output driving hardware). you expect applications to directly
control this and have to respond to this and redraw content all the time?

this can be far simpler:

1. list of supported colorspaces (bonus points if flags say if its able to be
native or is emulated).
2. colorspace attached to buffer by client.

that's it.

> > The compositor now must not touch the parts of the surface on the main
> > output (where the color spaces match). But it could still try to convert
> > from the color space of the main output to that of a secondary screen if
> > the surface covers two screens with different color profiles.
> 
> Not as a base requirement. The application needs to be able to
> do it's own color management, which means color managing for
> every output the surface goes to. So the base requirement
> has no rendering requirement for a composer - it's just
> about signalling the required information to the client application.
> 
> > But then again most people that work with professional applications would
> > not make them cover multiple screens, I guess.
> 
> People using color managed applications expect color management to work as
> best it can across multiple screens.
> 
> > Therefore I'm not opposed to adding 
> > a flag that indicates that the application wants to disable color
> > corrections completely for that surface, independent of the output.
> 
> This is only something that becomes a question at the next
> level, where there is an expectation that the composer
> has some degree of color management capability.
> 
> >> Which is not to say that compositor color management doesn't have its
> >> place - it is ideal for applications that just want to use "RGB", and
> >> not deal with specific display behavior.
> > 
> > Very simple applications would just keep the attached sRGB color space and 
> > maybe place images on subsurfaces with the embedded color space from the
> > image attached.
> 
> That works only in the case that the composer supports the image colorspaces.
> This may well be the case for some applications (i.e. web browsers), but
> I imagine it may not be desirable to insist that all composers supporting
> a color management capability, support a full range of colorspaces (N - color
> in general).
> 
> > Applications that care a bit more about color correction (but do not have 
> > professional needs) could convert all their colors to the blending color
> > space of the compositor. I'd expect this blending color space to be linear
> > if the compositor cares about good colors.
> 
> It's not clear to me that any application that is interested in good
> color would trust it to blending operations.
> 
> I'd also imagine that there is a class of applications wishing to get the
> compositor to deal with gross display differences (Wide gamut vs.
> sRGB-like for instance) but is not in

Re: [RFC wayland-protocols] Color management protocol

[The Rasterman]

On Mon, 12 Dec 2016 18:18:21 +1100 Graeme Gill  said:

> Niels Ole Salscheider wrote:
> > Am Donnerstag, 8. Dezember 2016, 15:51:12 CET schrieb Graeme Gill:
> 
> >> Looking through the current Wayland color-management protocol
> >> proposal, I think it is missing a really fundamental thing -
> >> managing the output device color calibration state and color
> >> profile. I guess the assumption is that this is being done
> >> by colord, but my understanding is that colord is specific
> >> to Gnome based systems, and certainly depends on DBus, which
> >> Wayland does not. [ Please correct me if I've got any of this wrong. ]
> 
> > It is (currently) up to the compositor to decide how to implement this. The 
> > compositor could come with its own settings for the output color profiles
> > or query some other program. This might be colord, but it could also be 
> > kolormanager, or something else.
> 
> 1) This doesn't address how this information is communicated
>to a Wayland application.
> 
> 2) Expecting color management applications to deal with
>configuring the compositor in a platform dependent
>way, is expecting far too much. I for one am not
>about to add multiple platform dependent back
>ends (multiple flavors of Linux, BSD's, Android,
>etc.) to my tools to do this, and no other major
>platform expects it (i.e. none of MSWindows, OS X
>or X11 based systems have this requirement.)
> 
> The correct approach to avoiding such issues is simply
> to make both aspects Wayland (extension) protocols, so
> that Wayland color management and color sensitive applications
> have the potential to work across all Wayland systems,
> rather than being at best balkanized, or at worst, not
> supported.

"not supported" == sRGB (gamma). render appropriately. most displays are not
capable of wide gammuts so you'll HAVE to handle this case no matter what.
either compositor will fake it and reduce your colors down to sRGB, or your
apps produce sRGB by default and have code paths for extended colorspace
support *IF* it exists AND different colorspaces are natively supported by the
display hardware.


-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland-protocols] Color management protocol

[Graeme Gill]

Carsten Haitzler (The Rasterman) wrote:
> On Fri, 9 Dec 2016 15:30:40 +1100 Graeme Gill  said:

>> I thought I'd explained this in the previous post ? - perhaps
>> I'm simply not understanding where you are coming from on this.
> 
> you didn't explain before if the point is for this to be mandatory or 
> optional.

I'm not sure exactly what you mean by "this".

I've suggested two color management extensions, one building on
the other. By being an extension, I assume that neither one is
mandatory, although "core" would be a dependence of "enhanced".

> above you basically say it has to be mandatory as applications will then fail
> to run (at least some set of them might).

That's not at all what I said. I said that applications have the
option of falling back to more basic approaches :-
enhance back to core, core back to none.

> when you add extra features like new colorspace support, people writing apps
> and toolkits nee to know what the expectation is. can they just assume it will
> work, or do they need to have a fallback path on their side.

I've not mentioned any new colorspace support, so I'm not
sure what you are talking about.

> compositor writers need to know too. if color management is mandatory then
> their compositor is basically broken until they add it.

Naturally a compositor that supports an extension, would
would have to implement it!

> i don't see a difference between enhanced and core.

Hmm. They are quite distinct.

 core: The application either implements its own CMM (lcms or
  ArgyllCMS icclib/imdi etc.), or uses a system provided CMM
  (i.e. ColorSync, WCS, AdobeCMM etc.).

 enchanced: The compositor implements some level of CMM itself,
  using one of the above libraries, GPU etc.

 core: The application requires information from the graphics
  system (via Wayland in this particular discussion), namely
  the profile for the display corresponding to each
  pixel region.

 enhanced: The compositor is provided with source colorspace
  profiles by the application.

 core: The application uses its CMM to transform source colorspaces
  to the display colorspaces, and sends the pixels to the graphics system.

 enhanced: The compositor uses its CMM to transform the pixels provided
  by the application in the provided source colorspaces to the display
  colorspaces.

> color management means:
> 
> 1. being able to report what colorspace is "default" on the display right now
> (and what may be able to be enabled possible at request).

I'm not sure what you mean by "enabled". A display colorspaces is just 
information
that is needed by the CMM, so it is either known and available to what needs
it, or not known or not available to what needs it.

> 2. being able to report what colorspaces are supported at all (either natively
> by the display or by emulation)

Not needed for core color management - all that is required is
to be able to send pixels in the native display space to the display.

> 3. the ability for a client to define a specific colorspace for a buffer. (the
> choice of the colorspace of the display itself should be left to the
> compositor).

Not needed for core color management - the application deals
with source color spaces internally.

To reiterate:

1) Core color management support is essential because you can't assume that
  a CMM implemented in the compostor has all the capabilities that every
  application requires - particularly if it is a color critical application.

2) Core color management support is essential to allow color management 
applications
  such as color profilers work. Without color profilers, there are no accurate
  color profiles for your display, and color critical applications won't be 
viable.

If you want Wayland to be on parity with existing systems (MSWin, OS X, X11),
then you need core color management support.

> the only difference is the set of colorspaces wanted by client and by 
> supported
> by compositor. core and enhanced are arbitrary labels.

No. See above.

> what matters is a
> common colorspace. right now in wayland it's all sRGB so everyone agrees (i'm
> ignoring yuv etc. buffer formats. just talking RGB ones).

That's not how CMM's work. The common color space is the profile connection
space, which is based on CIE XYZ.

> so the questions are:
> 
>   * if all of these above are missing: what happens?
>   * if the list of colorspaces natively supported by the screen does not have 
> a
> common set of colorspaces the client wants: what happens?
>   * if the list of all colorspaces (native or emulated) by the compositor does
> not have a common set with the client: what happens?

Only questions for enhanced color management, and since this isn't
required by color critical applications, a relaxed level of support
is likely to be useful.

> what i want to know if how mandatory will this be, as most users will never
> have a scenario where their display can do more than "dumb" sRGB and any
> compositor claiming to support colorspaces wil

Re: [RFC wayland-protocols] Color management protocol

[Graeme Gill]

Carsten Haitzler (The Rasterman) wrote:

> well graeme disagrees and effectively thinks it should be. :)

I said no such thing!

Graeme Gill.

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland-protocols] Color management protocol

[Graeme Gill]

Carsten Haitzler (The Rasterman) wrote:

> wouldn't it be best not to explicitly ask for an output colorspace and just
> provide the colorspace of your buffer and let the compositor decide? e.g. if
> your window is on top, or it's the largest one, or it's focused,then the
> compositor MAY switch the colorspace of that monitor to match your surface's
> buffer colorspace, and if it goes into the background or whatever, switch 
> back?
> it can (and likely should) emulato other colorspaced then.

That doesn't seem like color management. Ultimately you arrive
at the native display space, so if things are to look as intended,
something (application or compositor) should transform from
a non-native spaces into the native space.

At a practical level, if it is expected that the compositor
deals with transparency (which I assume it does), then I'd
suggest something simple - compositing in output device space
(Isn't that what current Wayland compositors are doing ?),
or as a refinement, compositing in a per-channel light
linearised space, that is reversible at the bit level.

Bottom line is that a color critical application won't
use compositor transparency for anything it cares about.

> e.g. if buffer is adobe rgb, then switch display to work in adobe rgb but
> re-render everything else that is sRGB into adobe argb space... there might be
> a slight "flicker" so to speak as maybe some banding appears in some gradients
> of SRGB windows or colors are ever so slightly off, but the compositor is
> optimizing for the surface it thinks it most important.

Sounds cumbersome. It's certainly not how existing systems work.

> i really don't like the
> idea of applications explicitly controlling screen colorspace.

I'm not sure what you mean by that. Traditionally applications render
to the display colorspace. Changing the display setup (i.e. switching
display colorspace emulation) is a user action, complicated only by the
need to make the corresponding change to the display profile, and re-rendering
anything that depends on the display profile.

Graeme Gill.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland-protocols] Color management protocol

[Graeme Gill]

Niels Ole Salscheider wrote:

> Maybe I should reword it then. The intention of allowing to query the 
> blending 
> space was to tell applications the preferred color space of a surface. That 
> is, if they do any color management they should create surfaces with that 
> color space to minimize computing time.

Sounds overly complex for a first cut.

> Anyway, this preferred space should probably not be sRGB if the compositor 
> cares about accurate colors. This is because there are many monitors that 
> have 
> wider gamuts and you would clip the colors at that point.

See my previous suggestion - use a linearised light output display space
for compositing - it's simple, fast, and there are no gamut issues.

Graeme Gill.

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland-protocols] Color management protocol

[The Rasterman]

On Tue, 13 Dec 2016 17:46:25 +1100 Graeme Gill  said:

> Carsten Haitzler (The Rasterman) wrote:
> 
> > wouldn't it be best not to explicitly ask for an output colorspace and just
> > provide the colorspace of your buffer and let the compositor decide? e.g. if
> > your window is on top, or it's the largest one, or it's focused,then the
> > compositor MAY switch the colorspace of that monitor to match your surface's
> > buffer colorspace, and if it goes into the background or whatever, switch
> > back? it can (and likely should) emulato other colorspaced then.
> 
> That doesn't seem like color management. Ultimately you arrive
> at the native display space, so if things are to look as intended,
> something (application or compositor) should transform from
> a non-native spaces into the native space.
> 
> At a practical level, if it is expected that the compositor
> deals with transparency (which I assume it does), then I'd
> suggest something simple - compositing in output device space
> (Isn't that what current Wayland compositors are doing ?),

a display may not have a single native colorspace. it may be able to switch.
embedded devices can do this as the display panel may have extra control lines
for switching to a different display gammut/profile. it may be done at the gfx
card output level too... so it can change on the fly.

yes. compositors right now work in display colorspace. they do no conversions.
eventually they SHOULD to display correctly. to do so they need a color profile
for the display.

it may be that a window spans 8 different screens all with different profiles.
then what? currently the image looks a bit different on each display. with a
proper color correcting compositor it can make them all look the same. if you
want apps to be able to provide "raw in screen colorspace pixels" this is going
to be horrible especially as windows span multilpe screens. if i mmove the
window around the client has drawn different parts of its buffer with different
colorspaces/profiles in mind and then has to keep redrawing to adjust as it
moves. you'll be ablew to see "trails" of incorrect coloring around the
boundaries of the screens untl the client catches up.

the compositor SHOULD do any color correction needed at this point. if you want
PROPER color correction the compositor at a MINIMUM needs to be able to report
the color profile of a screen even if it does no correcting. yes you may have
multiple screens. i really dislike the above scenario of incorrect pixel tails
because this goes against the whole philosophy of "every frame is perfect". you
cannot do this given your proposal. it can only be done if the compositor
handles the color correction and the clients just provide the colorspace being
used for their pixel data.

> or as a refinement, compositing in a per-channel light
> linearised space, that is reversible at the bit level.
> 
> Bottom line is that a color critical application won't
> use compositor transparency for anything it cares about.

i'm totally ignoring the case of having alpha. yes. blending in gamma space is
"wrong". but it's fast. :)

> > e.g. if buffer is adobe rgb, then switch display to work in adobe rgb but
> > re-render everything else that is sRGB into adobe argb space... there might
> > be a slight "flicker" so to speak as maybe some banding appears in some
> > gradients of SRGB windows or colors are ever so slightly off, but the
> > compositor is optimizing for the surface it thinks it most important.
> 
> Sounds cumbersome. It's certainly not how existing systems work.
> 
> > i really don't like the
> > idea of applications explicitly controlling screen colorspace.
> 
> I'm not sure what you mean by that. Traditionally applications render
> to the display colorspace. Changing the display setup (i.e. switching
> display colorspace emulation) is a user action, complicated only by the
> need to make the corresponding change to the display profile, and re-rendering
> anything that depends on the display profile.

being able to  modify what the screen colorspace is in any way is what i
dislike. only the compositor should affect this based on it's own decisions.

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland-protocols] Color management protocol

[The Rasterman]

On Tue, 13 Dec 2016 17:14:21 +1100 Graeme Gill  said:

> Carsten Haitzler (The Rasterman) wrote:
> > On Fri, 9 Dec 2016 15:30:40 +1100 Graeme Gill  said:
> 
> >> I thought I'd explained this in the previous post ? - perhaps
> >> I'm simply not understanding where you are coming from on this.
> > 
> > you didn't explain before if the point is for this to be mandatory or
> > optional.
> 
> I'm not sure exactly what you mean by "this".

this == support for color correction protocol AND actually the support for
providing the real colorspace of the monitor, providing non SRGB pixel data by
clients in another colorspace (eg adobe) and it MUST work or apps will
literally fall over.

at the end of the day there will be some extension and then some form of
guidance to developers. e.g. you can guarantee this will work, or "this may or
may not work. deal with it".

> I've suggested two color management extensions, one building on
> the other. By being an extension, I assume that neither one is
> mandatory, although "core" would be a dependence of "enhanced".

well there are extensions that are managed outside of wayland as a project.
these obviously are not mandatory. the more core it becomes the more it is
likely "mandatory".

> > above you basically say it has to be mandatory as applications will then
> > fail to run (at least some set of them might).
> 
> That's not at all what I said. I said that applications have the
> option of falling back to more basic approaches :-
> enhance back to core, core back to none.

yes. my bad. i misread the replies and quotes. i thought you said "not at all"
to the "clients should fall back" path.

> > when you add extra features like new colorspace support, people writing apps
> > and toolkits nee to know what the expectation is. can they just assume it
> > will work, or do they need to have a fallback path on their side.
> 
> I've not mentioned any new colorspace support, so I'm not
> sure what you are talking about.

not a format. a colorspce. R numbers are still R, as are G and B. it's just
that they point to different "real life spectrum" colors and so they need to be
transformed from one colorspace (sRGB to adobe RGB or adobe to sRGB).

> > compositor writers need to know too. if color management is mandatory then
> > their compositor is basically broken until they add it.
> 
> Naturally a compositor that supports an extension, would
> would have to implement it!
> 
> > i don't see a difference between enhanced and core.
> 
> Hmm. They are quite distinct.
> 
>  core: The application either implements its own CMM (lcms or
>   ArgyllCMS icclib/imdi etc.), or uses a system provided CMM
>   (i.e. ColorSync, WCS, AdobeCMM etc.).
>  enchanced: The compositor implements some level of CMM itself,
>   using one of the above libraries, GPU etc.
> 
>  core: The application requires information from the graphics
>   system (via Wayland in this particular discussion), namely
>   the profile for the display corresponding to each
>   pixel region.

i really do not think this is needed. simply a list of available colorspaces
would be sufficient. application then provide data in the colorspace of it's
choice given what is supported by the compositor and the input data it has...

>  enhanced: The compositor is provided with source colorspace
>   profiles by the application.

i again don't see why this is needed.

>  core: The application uses its CMM to transform source colorspaces
>   to the display colorspaces, and sends the pixels to the graphics system.
> 
>  enhanced: The compositor uses its CMM to transform the pixels provided
>   by the application in the provided source colorspaces to the display
>   colorspaces.

again - we're just arguing who does the transform. i don't see the point. the
compositor will have a list of colorspaces it can display (either A screen can
display this OR can be configured to display in this colorspace, ... OR the
compositor can software transform pixels in this colorspace to whatever is
necessary to display correctly).

the client simply chooses what colorspace to provide buffers in. it chooses the
one that is best for it.

> > color management means:
> > 
> > 1. being able to report what colorspace is "default" on the display right
> > now (and what may be able to be enabled possible at request).
> 
> I'm not sure what you mean by "enabled". A display colorspaces is just
> information that is needed by the CMM, so it is either known and available to
> what needs it, or not known or not available to what needs it.

a colorspace that is enabled is when the display output for that screen maps
RGB values directly to that given colorspace. i.e. the common default is sRGB.
the display may be also able to switch to adobe rgb at the flip of a switch or
by request from the host system (via data lines). it may be fixed and only one
colorspace is every able to be displayed.

> > 2. being able to report what colorspaces are supported at all (either
> > natively by t

Re: [RFC wayland-protocols] Color management protocol

[Graeme Gill]

Carsten Haitzler (The Rasterman) wrote:
> On Mon, 12 Dec 2016 18:18:21 +1100 Graeme Gill  said:

>> The correct approach to avoiding such issues is simply
>> to make both aspects Wayland (extension) protocols, so
>> that Wayland color management and color sensitive applications
>> have the potential to work across all Wayland systems,
>> rather than being at best balkanized, or at worst, not
>> supported.
> 
> "not supported" == sRGB (gamma). 

No, not supported = native device response = not color managed.

> render appropriately.
> most displays are not
> capable of wide gammuts so you'll HAVE to handle this case no matter what.

I've no idea what you mean.

> either compositor will fake it and reduce your colors down to sRGB, or your
> apps produce sRGB by default and have code paths for extended colorspace
> support *IF* it exists AND different colorspaces are natively supported by the
> display hardware.

No compositor is involved. If the application doesn't know
the output display profile, then it can't do color management.

Graeme Gill.

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland-protocols] Color management protocol

[Graeme Gill]

Carsten Haitzler (The Rasterman) wrote:
> On Mon, 12 Dec 2016 17:57:08 +1100 Graeme Gill  said:

>> Right. So a protocol for querying the profile of each output for its surface
>> is a base requirement.
> 
> i totally disagree. the compositor should simply provide available colorspaces
> (and generally only provide those that hardware can do). what screen they 
> apply
> to is unimportant.

Please read my earlier posts. No (sane) compositor can implement CMM
capabilities to a color critical applications requirements,
so color management without any participation of a compositor
is a core requirement.

> if the colorspace is native to that display or possible, the compositor will 
> do
> NO CONVERSION of your pixel data and display directly (and instead convert 
> sRGB
> data into that colorspace).

Relying on an artificial side effect (the so called "null color transform")
to implement the ability to directly control what is displayed, is a poor
approach, as I've explained at length previously.

> if your surface spans 2 screens the compositor may
> convert some to the colorspace of a monitor if it does not support that
> colorspace. choose the colorspace (as a client) that matches your data best.
> compositor will do a "best effort".

No compositor should be involved for core support. The application
should be able to render appropriately to each portion of the span.

> this way client doesnt need to know about outputs, which outputs it spans etc.
> and compositor will pick up the pieces. let me give some more complex 
> examples:

That only works if the client doesn't care about color management very much -
i.e. it's not a color critical application. I'd hope that the intended use of
Wayland is wider in scope than that.

> compositor has a mirroring mode where it can mirror a window across multiple
> screens.

Sure, and in that case the user has a choice about which screen is
properly color managed. Nothing new there - the same currently
applies on X11, OS X, MSWin. Anyone doing color critical work
will not run in such modes, or will just use the color managed screen.

> some screens can or cannot do color management.

Nothing to do with screens - core color management is up to
the application, and all it needs is to know the display profile.

> what happens when the colorspace changes on the fly (you recalbrate
> the screen or output driving hardware). you expect applications to directly
> control this and have to respond to this and redraw content all the time?

Yep, same as any other sort of re-rendering event (i.e. exactly what happens 
with
current systems - nothing new here.)

> this can be far simpler:
> 
> 1. list of supported colorspaces (bonus points if flags say if its able to be
> native or is emulated).
> 2. colorspace attached to buffer by client.
> 
> that's it.

If you don't care so much about color, yes. i.e. this is
what I call "Enhanced" color management, rather than core.
It doesn't have to be as flexible or as accurate, but it has
the benefit of being easy to use for applications that don't care
as much, or currently aren't color managed at all.

Graeme Gill.


___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland-protocols] Color management protocol

[The Rasterman]

On Wed, 14 Dec 2016 18:49:14 +1100 Graeme Gill  said:

> Carsten Haitzler (The Rasterman) wrote:
> > On Mon, 12 Dec 2016 17:57:08 +1100 Graeme Gill  said:
> 
> >> Right. So a protocol for querying the profile of each output for its
> >> surface is a base requirement.
> > 
> > i totally disagree. the compositor should simply provide available
> > colorspaces (and generally only provide those that hardware can do). what
> > screen they apply to is unimportant.
> 
> Please read my earlier posts. No (sane) compositor can implement CMM
> capabilities to a color critical applications requirements,
> so color management without any participation of a compositor
> is a core requirement.

oh course it can. client provides 30bit (10bit per rgb) buffers for example and
compositor can remap. from the provided colorspace for that buffer to the real
display colorspace.

> > if the colorspace is native to that display or possible, the compositor
> > will do NO CONVERSION of your pixel data and display directly (and instead
> > convert sRGB data into that colorspace).
> 
> Relying on an artificial side effect (the so called "null color transform")
> to implement the ability to directly control what is displayed, is a poor
> approach, as I've explained at length previously.

but that is EXACTLY what you have detailed to rely on for color managed
applications. for core color management you say that the client knows the
colorspace/profile/mappings of the monitor and renders appropriately and
expects its pixel values to be presented 1:1 without remapping on the screen
because it knows the colorspace...

> > if your surface spans 2 screens the compositor may
> > convert some to the colorspace of a monitor if it does not support that
> > colorspace. choose the colorspace (as a client) that matches your data best.
> > compositor will do a "best effort".
> 
> No compositor should be involved for core support. The application
> should be able to render appropriately to each portion of the span.

then no need for any extension. :) compositor HAs to be involved to at least
tell you the colorspace of the monitor... as the screen is its resource.

> > this way client doesnt need to know about outputs, which outputs it spans
> > etc. and compositor will pick up the pieces. let me give some more complex
> > examples:
> 
> That only works if the client doesn't care about color management very much -
> i.e. it's not a color critical application. I'd hope that the intended use of
> Wayland is wider in scope than that.

how does it NOT work? let me give a really simple version of this.

you have a YUV buffer. some screens can display yuv, some cannot. you want to
know which screens support yuv and know where your surface is mapped to which
screens so you can render some of your buffer (some regions) in yuv and some
in rgb (i'm assuming packed YUVxYUVxYUVx and RGBxRGBxRGBx layout here for
example)... you wish to move all color correct rendering, clipping that correct
(yuv vs rgb) rendering client-side and have the compositor just not care.

this leads to the artifacts i was mentioning. just this one will be a LOT more
obvious.

> > compositor has a mirroring mode where it can mirror a window across multiple
> > screens.
> 
> Sure, and in that case the user has a choice about which screen is
> properly color managed. Nothing new there - the same currently
> applies on X11, OS X, MSWin. Anyone doing color critical work
> will not run in such modes, or will just use the color managed screen.

the point of wayland is to be "every frame is perfect". this breaks that.

> > some screens can or cannot do color management.
> 
> Nothing to do with screens - core color management is up to
> the application, and all it needs is to know the display profile.

i mean they are able to display wider gammut of color beyond the limited sRGB
range that is common.

> > what happens when the colorspace changes on the fly (you recalbrate
> > the screen or output driving hardware). you expect applications to directly
> > control this and have to respond to this and redraw content all the time?
> 
> Yep, same as any other sort of re-rendering event (i.e. exactly what happens
> with current systems - nothing new here.)

and this leads to imperfect frames.

> > this can be far simpler:
> > 
> > 1. list of supported colorspaces (bonus points if flags say if its able to
> > be native or is emulated).
> > 2. colorspace attached to buffer by client.
> > 
> > that's it.
> 
> If you don't care so much about color, yes. i.e. this is
> what I call "Enhanced" color management, rather than core.
> It doesn't have to be as flexible or as accurate, but it has
> the benefit of being easy to use for applications that don't care
> as much, or currently aren't color managed at all.

how not? a colorspace/profile can be a full transform with r/g/b points in
space... not just a simple enum with only fixed values (well thats how i'm
imagining it). in this case the api's tell the client 

Re: [RFC wayland-protocols] Color management protocol

[The Rasterman]

On Wed, 14 Dec 2016 18:27:13 +1100 Graeme Gill  said:

> Carsten Haitzler (The Rasterman) wrote:
> > On Mon, 12 Dec 2016 18:18:21 +1100 Graeme Gill  said:
> 
> >> The correct approach to avoiding such issues is simply
> >> to make both aspects Wayland (extension) protocols, so
> >> that Wayland color management and color sensitive applications
> >> have the potential to work across all Wayland systems,
> >> rather than being at best balkanized, or at worst, not
> >> supported.
> > 
> > "not supported" == sRGB (gamma). 
> 
> No, not supported = native device response = not color managed.

and for most displays that is sRGB.

> > render appropriately.
> > most displays are not
> > capable of wide gammuts so you'll HAVE to handle this case no matter what.
> 
> I've no idea what you mean.

most displays have "horrible color response". they are sRGB. they cannot
display a wider part of the color spectrum. some professional monitors/displays
can do this. eg 98% of abobe RGB for example.

either way monitors tend to have slightly different color reproduction and most
are "not that good" so basically sRGB. the compositor then is effectively
saying "unmanaged == sRGB, but it may really be anything so don't be fussy".

> > either compositor will fake it and reduce your colors down to sRGB, or your
> > apps produce sRGB by default and have code paths for extended colorspace
> > support *IF* it exists AND different colorspaces are natively supported by
> > the display hardware.
> 
> No compositor is involved. If the application doesn't know
> the output display profile, then it can't do color management.

it can assume sRGB.

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland-protocols] Color management protocol

[Graeme Gill]

Carsten Haitzler (The Rasterman) wrote:
> On Tue, 13 Dec 2016 17:14:21 +1100 Graeme Gill  said:

> this == support for color correction protocol AND actually the support for
> providing the real colorspace of the monitor, providing non SRGB pixel data by
> clients in another colorspace (eg adobe) and it MUST work or apps will
> literally fall over.

That's not a scheme I'm recommending.

> at the end of the day there will be some extension and then some form of
> guidance to developers. e.g. you can guarantee this will work, or "this may or
> may not work. deal with it".

Sure.

> well there are extensions that are managed outside of wayland as a project.
> these obviously are not mandatory. the more core it becomes the more it is
> likely "mandatory".

Sure.

> not a format. a colorspce. R numbers are still R, as are G and B. it's just
> that they point to different "real life spectrum" colors and so they need to 
> be
> transformed from one colorspace (sRGB to adobe RGB or adobe to sRGB).

My point stands. I've not mentioned new colorspaces.

> i really do not think this is needed. simply a list of available colorspaces
> would be sufficient. application then provide data in the colorspace of it's
> choice given what is supported by the compositor and the input data it has...

And I think it is core, for all the reasons I've listed.

>>  enhanced: The compositor is provided with source colorspace
>>   profiles by the application.
> 
> i again don't see why this is needed.

Hmm. How else does the compositor know how to transform from
the given colorspace to the display colorspace ?

> again - we're just arguing who does the transform.

It's not "just", it's the point.

> i don't see the point. the
> compositor will have a list of colorspaces it can display (either A screen can
> display this OR can be configured to display in this colorspace, ... OR the
> compositor can software transform pixels in this colorspace to whatever is
> necessary to display correctly).

I don't know how many different ways I can explain the same thing. The 
compositor
can't know how to transform color in all the ways an application may need
to transform color. I think it is unlikely for instance, that you are
proposing that the compositor support full N-Color, device links, ICC-Max
support, etc., or the infinity of ways that haven't been invented yet to
transform between color spaces. So the core color management requirement
is that the application be able to transform into the device colorspace itself.

> the client simply chooses what colorspace to provide buffers in. it chooses 
> the
> one that is best for it.

A core requirement is that the client be able to know what output device
colorspace each pixel is destined for, and provide a buffer that the
compositor doesn't touch (i.e. it has no source colorspace label
other than don't touch these pixels").

> a colorspace that is enabled is when the display output for that screen maps
> RGB values directly to that given colorspace. i.e. the common default is sRGB.

No. No color transformation by the compositor, so no colorspace.

> the display may be also able to switch to adobe rgb at the flip of a switch or
> by request from the host system (via data lines). it may be fixed and only one
> colorspace is every able to be displayed.

A color critical user won't put up with such things - they expect to
be in control over what's happening, and if a system has proper
color management (core + enhanced), there is absolutely no
reason for them to run the display in anything other than it's native gamut.

> then it's a list of 1 colorspace: "sRGB" :) wehich is the current 
> default/state
> of play in wayland anyway.

No, it's a list of N output display colorspaces, one for each display.

> then you need no colormanagement at all.

As explained, yes, core color management needs support -
control over VideoLUT state, plus registration of the output
display colorspaces + knowledge of which output the different
parts of a surface map to.

> just assume sRGB (gamma2.2 or
> whatever). zero colormanagement protocol or support needed. totally up to
> client. the compositor MIGHT know its colorspace/profile and report it here
> without sRGB listed then. thats how you know you only have 1 colorspace.

I'm not sure _what_ you are talking about. sRGB doesn't come into it.

> thus why i asked if apps will be expected to be able to fallback and DIY
> client-side (and present sRGB).

It's not a fallback, it's core (basic) color management.

> how we're talking about color profiling tools that want to create a color
> mapping/profile for that display so colors display correctly. you need a
> colorimiter to measure output of course to do this.

Yes, and ?

> this could be nothing more than a "1:1 do nothing" colorspace. that means R,G
> and B values are transmitted with no changes. changing the content of your
> buffer sends different signals that the colorimiter can read and thus be used
> to create 

Re: [RFC wayland-protocols] Color management protocol

[The Rasterman]

On Wed, 14 Dec 2016 23:23:59 +1100 Graeme Gill  said:

> Carsten Haitzler (The Rasterman) wrote:
> > On Tue, 13 Dec 2016 17:14:21 +1100 Graeme Gill  said:
> 
> > this == support for color correction protocol AND actually the support for
> > providing the real colorspace of the monitor, providing non SRGB pixel data
> > by clients in another colorspace (eg adobe) and it MUST work or apps will
> > literally fall over.
> 
> That's not a scheme I'm recommending.

ok. that's fine. i'm happy with that.

...snip...

> > not a format. a colorspce. R numbers are still R, as are G and B. it's just
> > that they point to different "real life spectrum" colors and so they need
> > to be transformed from one colorspace (sRGB to adobe RGB or adobe to sRGB).
> 
> My point stands. I've not mentioned new colorspaces.

if it's RGB or YUV (YCbCr) it's the same thing. just vastly different color
mechanisms. color correction in RGB space is actually the same as in YUV. it's
different spectrum points in space that the primaries point to.

 color management require introducing such things. BT.601, BT.709, BT.2020.
the compositor MUST KNOW which colorspace the YUV data uses to get it correct.
i'm literally starting at datasheets of some hardware and you have to tell it
to use BT.601 or 709 equation when dealing with YUV. otherwise the video data
will look wrong. colors will be off. in fact BT.709 == sRGB.

now here comes the problem... each hardware plane yuv may be assigned to MAY
have a different colorspace. they also then get affected by the color
reproduction of the screen at the other end.

you HAVE to provide the colorspace information so the compositor CAN assign you
to the correct hw plane OR configure the plane correctly OR configure the
yuv->rgb conversion hardware to be correct.

this is no different to RGB space but you don't tend to find hardware
specifically helping you out (yes gpu + shader can do a transform fast. i'm
talking hw layers or dedicated acceleration units that have existed for yuv
for a long time).

any list of colorspaces IMHO should also include the yuv colorspaces where/if
possible. if a colorspace is not supported by the compositor then the appjust
needs to take a "best effort". the default colorspace today could be considered
BT.709/sRGB. also you could say "it's null transform" colorspace. i.e. you know
nothing so don't try colorcorrect.

> > i really do not think this is needed. simply a list of available colorspaces
> > would be sufficient. application then provide data in the colorspace of it's
> > choice given what is supported by the compositor and the input data it
> > has...
> 
> And I think it is core, for all the reasons I've listed.
> 
> >>  enhanced: The compositor is provided with source colorspace
> >>   profiles by the application.
> > 
> > i again don't see why this is needed.
> 
> Hmm. How else does the compositor know how to transform from
> the given colorspace to the display colorspace ?

my point was i don't think it's needed to split this up.

compositor lists available colorspaces. a list of 1 sRGB or null-transform or
adobe-rgb(with transform matrix), wide-gammut, etc. means thathat is the one
and only output supported.

> > again - we're just arguing who does the transform.
> 
> It's not "just", it's the point.

not as i see it. given a choice of output colorspaces the client can choose to
do its own conversion, OR if it's colorspace of preference is supported by the
compositor then choose to pass the data in that colorspace to the compositor
and have the compositor do it.

> > i don't see the point. the
> > compositor will have a list of colorspaces it can display (either A screen
> > can display this OR can be configured to display in this colorspace, ... OR
> > the compositor can software transform pixels in this colorspace to whatever
> > is necessary to display correctly).
> 
> I don't know how many different ways I can explain the same thing. The
> compositor can't know how to transform color in all the ways an application
> may need to transform color. I think it is unlikely for instance, that you are
> proposing that the compositor support full N-Color, device links, ICC-Max
> support, etc., or the infinity of ways that haven't been invented yet to
> transform between color spaces. So the core color management requirement
> is that the application be able to transform into the device colorspace
> itself.

*sigh* and THAT IS WHY i keep saying that the client can choose to do it's own!
BUT this is not going to be perfect across multiple screens unless all screens
share the same colorspace/profile. let's say:

1 screen is a professional grade monitor with wide gammut rgb output.
1 screen is a $50 thing i picked up from the bargain basement bin at walmart.

dumb compositor example:

compositor reports 2 colorspaces:
  null transform RGB
  BT.709 YUV

smart compositor:

compositor reports 5 colorspaces:
  null transform RGB
  wide gammut RGB
  sRGB
  BT.709 YUV
  BT.601 

Re: [RFC wayland-protocols] Color management protocol

[Pekka Paalanen]

On Wed, 14 Dec 2016 18:49:14 +1100
Graeme Gill  wrote:

> Carsten Haitzler (The Rasterman) wrote:
> > On Mon, 12 Dec 2016 17:57:08 +1100 Graeme Gill  
> > said:  
> 
> >> Right. So a protocol for querying the profile of each output for its 
> >> surface
> >> is a base requirement.  
> > 
> > i totally disagree. the compositor should simply provide available 
> > colorspaces
> > (and generally only provide those that hardware can do). what screen they 
> > apply
> > to is unimportant.  
> 
> Please read my earlier posts. No (sane) compositor can implement CMM
> capabilities to a color critical applications requirements,
> so color management without any participation of a compositor
> is a core requirement.

Hi,

that is a very strange requirement, and architecturally it is a big
step backwards.

Applications are never in direct control of the display hardware. If
they need to be, they need to be written directly on DRM/KMS, not
Wayland. That way you truly get what you want: no compositor to mess
with your colors, and no fighting between different apps demanding
different display confgurations. If you really have applications this
color critical, then you'd better do exactly this or provide/audit the
compositor yourself.

In every other case, there is a display server *with a compositor*
between the application and the display. The compositor will
necessarily copy and translate pixel values from one format to another,
if not from color space to another.

The compositor is also in control of the display hardware: color lookup
tables, color transformation matrices, hardware overlays and direct
scanout of client buffers at opportunity. Scanout hardware can often do
color transformations on its own, with a method that might be unknown
to anyone but the vendor. All of these depend on the hardware whether
and which of them are available. What you are proposing necessarily
leads to moving the control of all of these into Wayland clients. It
may have been so with X11 where any client can change any display
setting any time it wants, but I cannot see that happening on Wayland.

If the pixels go through a display server, you have no choice but to
trust the display server to do the right thing. So the real question
is: "How do you let the compositor do the right thing?"
Not: "How do I bypass the compositor?"

You cannot take the compositor out of the equation unless you don't
have a compositor at all.


Here are some other points:

- Blending will only be an issue if a color-managed window has
  non-opaque pixels. If the application cares about the end result, it
  should not have non-opaque pixels, because not only it cannot know
  *how* they will be blended, it also cannot know *what* they will be
  blended with.

- You do not know which parts of a window are shown on which outputs.
  Some parts may be shown on multiple outputs at the same time. There
  is no provision for clients to provide a buffer separately for each
  output (you could add that as an extension). Therefore the same
  buffer content must be applicable to any and all outputs in the
  system. Unless all outputs have identical color profiles, this
  necessarily means the compositor must convert while compositing.

- Different compositors will always have different levels of color
  management support. You might want the color management protocol
  extension(s) to implicitly or explicitly indicate the level, perhaps
  even validation/auditing certificates. (Think about, say,
  professionally calibrated workstations where all the hardware, the
  drivers, the compositor and settings have been verified and locked
  down.)

- Calibration (i.e. modifying compositor configuration) must
  necessarily be a separate interface from the ones used by
  applications that only want to present color-managed content.
  Conflating it all into a single interface will cause problems with
  privilege separation and encourage usage patterns where different
  applications cannot work at the same time because they will be
  fighting over who gets to set the current configuration.


Thanks,
pq


pgpkfvlXjzgEN.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland-protocols] Color management protocol

[Pekka Paalanen]

On Mon, 12 Dec 2016 18:18:21 +1100
Graeme Gill  wrote:

> 2) Expecting color management applications to deal with
>configuring the compositor in a platform dependent
>way, is expecting far too much. I for one am not
>about to add multiple platform dependent back
>ends (multiple flavors of Linux, BSD's, Android,
>etc.) to my tools to do this, and no other major
>platform expects it (i.e. none of MSWindows, OS X
>or X11 based systems have this requirement.)

Indeed.

Applications have no right to be configuring *anything* in a desktop
compositor.

Configuring the compositor is an action with global effects, and
therefore must be privileged. It is usually reserved for the desktop
environment's configuration utilities that the user will be using
manually.


Thanks,
pq


pgpClvCNpLG5a.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland-protocols] Color management protocol

[Graeme Gill]

Carsten Haitzler (The Rasterman) wrote:
> On Tue, 13 Dec 2016 17:46:25 +1100 Graeme Gill  said:

> a display may not have a single native colorspace. it may be able to switch.
> embedded devices can do this as the display panel may have extra control lines
> for switching to a different display gammut/profile. it may be done at the gfx
> card output level too... so it can change on the fly.

That's not a typical situation though, but nothing special would be
happening - a new profile may be installed by the user as well,
in which case an application should re-render to accommodate
the change.

> yes. compositors right now work in display colorspace. they do no conversions.
> eventually they SHOULD to display correctly. to do so they need a color 
profile
> for the display.

For enhanced color management yes. But core comes first, and is necessary
for many color critical applications, because the compositor will never
have the color transformations they require.

> it may be that a window spans 8 different screens all with different profiles.
> then what?

As I've explained several times, what happens is that the application
is aware of this, and transforms each region appropriately - just
as they currently do on X11/OS X/MSWin systems.

> currently the image looks a bit different on each display.

That would be because you haven't implemented color management support
yet, making it possible for applications to implement color management.

> with a
> proper color correcting compositor it can make them all look the same.

As will a color aware application given appropriate color management support.

> if you
> want apps to be able to provide "raw in screen colorspace pixels" this is 
going
> to be horrible especially as windows span multilpe screens.

The code is already there to do all that in color critical application.

> if i mmove the
> window around the client has drawn different parts of its buffer with 
different
> colorspaces/profiles in mind and then has to keep redrawing to adjust as it
> moves.

Yes.

> you'll be ablew to see "trails" of incorrect coloring around the
> boundaries of the screens untl the client catches up.

It's damage, just like any other, and color critical users using
color critical applications will take "trails" over wrong color
anytime. No "trails" and wrong color = a system they can't use.

> the compositor SHOULD do any color correction needed at this point.

Not at all. That's a way to do it under some circumstances yes, but
it's not satisfactory for all.

> if you want
> PROPER color correction the compositor at a MINIMUM needs to be able to report
> the color profile of a screen even if it does no correcting.

Yes - exactly what I'm suggesting as core color management support.

> yes you may have
> multiple screens. i really dislike the above scenario of incorrect pixel tails
> because this goes against the whole philosophy of "every frame is perfect".

"Every pixel being perfect" except they are the wrong color, isn't perfect.

There are multiple ways of doing the best thing possible - you can't re-render
a frame in the compositor if it doesn't have the pixels needed to render it,
so you can 1) not re-render until the application provides the pixels
needed 2) Render the wrong color pixels until the application catches up
or 3) (if the compositor has some color management capability and
the application sets it up) get it to do an approximate correction to
the pixels until the application catches up with the correct color.

> you
> cannot do this given your proposal. it can only be done if the compositor
> handles the color correction and the clients just provide the colorspace being
> used for their pixel data.

And a compositor can't know how to transform color in the way some
applications require. This trumps such goals.

> i'm totally ignoring the case of having alpha. yes. blending in gamma space is
> "wrong". but it's fast. :)

Sure.

>> I'm not sure what you mean by that. Traditionally applications render
>> to the display colorspace. Changing the display setup (i.e. switching
>> display colorspace emulation) is a user action, complicated only by the
>> need to make the corresponding change to the display profile, and 
re-rendering
>> anything that depends on the display profile.
>
> being able to  modify what the screen colorspace is in any way is what i
> dislike.

That's the reality of how displays work. The user presses a button on the
front that says "emulate sRGB" or "native" or "Preset 1" or something else.

> only the compositor should affect this based on it's own decisions.

And color critical users will scream bloody murder at anything related
to color that isn't under their control, if it affects the accuracy or scope
of the color workflow.

>> No, not supported = native device response = not color managed.
>
> and for most displays that is sRGB.

Not in the slightest. Having (ahem!) profiled a few displays, none of them
are exactly sRGB. Some may asp

Re: [RFC wayland-protocols] Color management protocol

[Niels Ole Salscheider]

I feel like the discussion drifts off a bit. You (Graeme) obviously know much 
more about color management than I do. But as Pekka already pointed out there 
are a few constraints that originate in the design decisions of wayland and 
are quite different to these of X11. We can't change these constraints but 
have to find a solution that works well with them:

- A normal application CANNOT control the hardware directly (it can't program 
LUTs, for example).

- A normal application CANNOT alter global settings of the compositor (like 
setting color profiles for the outputs). This can only be done by the 
compositor or a few trusted applications. The user will just have to use the 
settings dialog provided with the compositor. Because of that it does not 
matter if this is implementation dependent.

- You DO NOT know which parts of a surface are shown on which screen.

- We aim to be pixel-perfect.

I think these constraints mean that we must let the compositor take part in 
the color correction, at least if more than one screen is involved. If we do 
so, we should also be able to expect that the compositor can handle a bit more 
complicated cases (e. g. an arbitrary number of different surfaces with 
different color profiles).

When I proposed this protocol my focus was on applications that may not be 
color managed currently. I thought for example about web browsers or simple 
image viewers where I would view (but not edit) photos.
Your focus is obviously on professional applications. I think both use cases 
are equally important and we should not treat one as an afterthought of the 
other.

I would be glad if we could come up with a solution that works for both under 
these constraints.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland-protocols] Color management protocol

[James Feeney]

> as Pekka already pointed out there 
> are a few constraints that originate in the design decisions of wayland and 
> are quite different to [those] of X11. We can't change these constraints but 
> have to find a solution that works well with them: ...

I'm more of a bystander to this discussion.  It would be really nice to have a
shared working document, to follow along, showing
1) a list of Wayland design requirements and constraints for color, and
2) a complete list steps needed to process an image, from source to display,
3) distinguishing issues like color gamut from color encoding.

From there, it would be much easier for people to see where "standard interface"
lines are being drawn, to see what steps are being handled by the compositor vs
an application, to see what steps are automatic and which steps must be manually
configured, and to distinguish what *should be* happening, and to see whether
anything was "missing", in the processing chain.

It is unfortunate that we are all still "stuck in the stone age", exchanging
black and white text documents with email, without the tools needed to draw and
view nice graphics for block diagrams and such.  It is what it is.  Still, some
clever use of ordered lists can go a long way to creating an understandable
sequence with groupings.

Would someone knowledgeable be willing to draft a "Wayland Pixel Perfect Color
Processing Chain" working document and post it somewhere conspicuously?  I'm
thinking that someone already knows enough to just rattle this off, from memory?

Or, is that document already posted somewhere?
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland-protocols] Color management protocol

[The Rasterman]

On Sun, 18 Dec 2016 16:25:13 +0100 Niels Ole Salscheider
 said:

> I feel like the discussion drifts off a bit. You (Graeme) obviously know much 
> more about color management than I do. But as Pekka already pointed out there 
> are a few constraints that originate in the design decisions of wayland and 
> are quite different to these of X11. We can't change these constraints but 
> have to find a solution that works well with them:
> 
> - A normal application CANNOT control the hardware directly (it can't program 
> LUTs, for example).
> 
> - A normal application CANNOT alter global settings of the compositor (like 
> setting color profiles for the outputs). This can only be done by the 
> compositor or a few trusted applications. The user will just have to use the 
> settings dialog provided with the compositor. Because of that it does not 
> matter if this is implementation dependent.
> 
> - You DO NOT know which parts of a surface are shown on which screen.
> 
> - We aim to be pixel-perfect.
> 
> I think these constraints mean that we must let the compositor take part in 
> the color correction, at least if more than one screen is involved. If we do 
> so, we should also be able to expect that the compositor can handle a bit
> more complicated cases (e. g. an arbitrary number of different surfaces with 
> different color profiles).

bingo. and while we're at it we should solve our yuv colorspace issues too
(same as rgb. currently bt601, bt709 and bt2020 need supporting).

> When I proposed this protocol my focus was on applications that may not be 
> color managed currently. I thought for example about web browsers or simple 
> image viewers where I would view (but not edit) photos.
> Your focus is obviously on professional applications. I think both use cases 
> are equally important and we should not treat one as an afterthought of the 
> other.
> 
> I would be glad if we could come up with a solution that works for both under 
> these constraints.
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel


-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland-protocols] Color management protocol

[Graeme Gill]

Pekka Paalanen wrote:
> On Wed, 14 Dec 2016 18:49:14 +1100
> Graeme Gill  wrote:

>> Please read my earlier posts. No (sane) compositor can implement CMM
>> capabilities to a color critical applications requirements,
>> so color management without any participation of a compositor
>> is a core requirement.

> that is a very strange requirement, and architecturally it is a big
> step backwards.

Since Wayland doesn't currently implement any color management support,
I'm not following how it can be a step backwards.

> Applications are never in direct control of the display hardware.

But applications have to be in control over the display content.
Content includes color.

> If
> they need to be, they need to be written directly on DRM/KMS, not
> Wayland.

I'm not sure why you think that, unless you are telling me
that applications can't send rasters to the display via Wayland.

> That way you truly get what you want: no compositor to mess
> with your colors, and no fighting between different apps demanding
> different display confgurations.

Messing with colors is not a requirement of the compositor. It can
leave them alone, just like it currently does. And I've
not mentioned display configurations.

> If you really have applications this
> color critical, then you'd better do exactly this or provide/audit the
> compositor yourself.

That's an extreme position to take - no other graphics system
(i.e. X11, OS X, MSWindows) has such a requirement for supporting
color managed applications.

> In every other case, there is a display server *with a compositor*
> between the application and the display. The compositor will
> necessarily copy and translate pixel values from one format to another,
> if not from color space to another.

And I'm pointing out that you cannot assume that a compositor will be capable
of translating from one colorspace to another in a way that the application
requires, so a means of allowing the application to provide color
values in display colorspace is a requirement. It's not that difficult,
the compositor just has to avoid messing with them, as well as
working as a communication point for display profile information.

> The compositor is also in control of the display hardware: color lookup
> tables, color transformation matrices, hardware overlays and direct
> scanout of client buffers at opportunity. Scanout hardware can often do
> color transformations on its own, with a method that might be unknown
> to anyone but the vendor. All of these depend on the hardware whether
> and which of them are available.

Which is why protocols for controlling the hardware should
ideally go via Wayland, so that applications who's job
is to setup that hardware can work.

> What you are proposing necessarily
> leads to moving the control of all of these into Wayland clients.

Yes - that's their job. Wayland or operating system management tools
don't have the expertise to manage such things - they don't know how
to create calibration curves or profiles etc.

> It
> may have been so with X11 where any client can change any display
> setting any time it wants, but I cannot see that happening on Wayland.

Wayland is useless unless there is a way to manage it. Which means
that it should have channels for administrative tools to configure it.

> If the pixels go through a display server, you have no choice but to
> trust the display server to do the right thing. So the real question
> is: "How do you let the compositor do the right thing?"
> Not: "How do I bypass the compositor?"

I didn't ask to bypass the compositor - you are the one assuming that.

I merely asked that core color management provide a means hat allows the
application to provide display colorspace values, and that the compositor
not mess with them.

> Here are some other points:
> 
> - Blending will only be an issue if a color-managed window has
>   non-opaque pixels. If the application cares about the end result, it
>   should not have non-opaque pixels, because not only it cannot know
>   *how* they will be blended, it also cannot know *what* they will be
>   blended with.

Yes, agreed. I pointed this out in a previous email.

> - You do not know which parts of a window are shown on which outputs.

Right. So that information needs to be communicated to the application,
just like it currently is on systems like X11, OS X and MSWin.

>   Some parts may be shown on multiple outputs at the same time.

Right, so since there is no hardware path for providing different
color managed value to each display, the best that can be done
in such hardware mirroring situations is to prioritize the color
management to the user designated display of highest priority.

>   There
>   is no provision for clients to provide a buffer separately for each
>   output (you could add that as an extension).

None is needed.

>   Therefore the same
>   buffer content must be applicable to any and all outputs in the
>   system.

This doesn't follow. Different parts o

Re: [RFC wayland-protocols] Color management protocol

[Graeme Gill]

Niels Ole Salscheider wrote:
> I feel like the discussion drifts off a bit. You (Graeme) obviously know much 
> more about color management than I do. But as Pekka already pointed out there 
> are a few constraints that originate in the design decisions of wayland and 
> are quite different to these of X11. We can't change these constraints but 
> have to find a solution that works well with them:

> - A normal application CANNOT control the hardware directly (it can't program 
> LUTs, for example).

Right, so it is not a normal application, it's a management application
that has the privileges to do so.

> - A normal application CANNOT alter global settings of the compositor (like 
> setting color profiles for the outputs). This can only be done by the 
> compositor or a few trusted applications.

Right - and therefore those trusted applications need to include
color management applications.

> The user will just have to use the 
> settings dialog provided with the compositor. Because of that it does not 
> matter if this is implementation dependent.

Hmm. I'm not sure what you mean by "settings dialog provided with the 
compositor".
Sounds like an application. For color management, the user often needs
specialist tools to create calibrations, profiles, and to manage the
system color configuration. That's what standardized API's are
meant to provide, a means of mixing and matching tools so that
systems don't have to be monolithic.

> - You DO NOT know which parts of a surface are shown on which screen.

So that needs to be fixed for color aware applications to be able to provide
display colorspace values.

> - We aim to be pixel-perfect.

Great. But perfect means the correct color as well. So mechanisms to
provide correct color are needed if you are to achieve perfection.

> I think these constraints mean that we must let the compositor take part in 
> the color correction, at least if more than one screen is involved.

I don't think this is either desirable, adequate, or necessary. For
some levels of color management I agree it will be desirable and
adequate, which is what my "Enhanced" extension sketched out, as
a variation of your extension. But the reality is that no compositor
can have all the required mechanisms to convert colors in the way
that demanding color critical applications may require. So it
shouldn't handicap Wayland in ways that none of the alternatives
are handicapped, but provide a mechanism for applications
to do it the way they need. It's shouldn't be hard. There are only two
things asked of the compositor :- provide the application the Surface
to Output region information it already has internally, and convey
the color values to the display(s).

> If we do 
> so, we should also be able to expect that the compositor can handle a bit 
> more 
> complicated cases (e. g. an arbitrary number of different surfaces with 
> different color profiles).

Providing source color profiles may satisfy many simple color management
requirements, but it won't satisfy all. This is only a problem if
there is no "escape" mechanism to work around such limitations.

> When I proposed this protocol my focus was on applications that may not be 
> color managed currently. I thought for example about web browsers or simple 
> image viewers where I would view (but not edit) photos.

Yes, I understand. This is an important class of color management usage.

> Your focus is obviously on professional applications. I think both use cases 
> are equally important and we should not treat one as an afterthought of the 
> other.

Right. I agree, but technically I think one builds on the other.

> I would be glad if we could come up with a solution that works for both under 
> these constraints.

I sketched out two extensions. Please critique and/or refine and/or contrast
them with other alternatives

Graeme Gill.

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland-protocols] Color management protocol

[The Rasterman]

On Sat, 17 Dec 2016 21:16:41 +1100 Graeme Gill  said:

> Carsten Haitzler (The Rasterman) wrote:
>  > On Tue, 13 Dec 2016 17:46:25 +1100 Graeme Gill 
>  > said:
> 
>  > a display may not have a single native colorspace. it may be able to
>  > switch. embedded devices can do this as the display panel may have extra
>  > control lines for switching to a different display gammut/profile. it may
>  > be done at the gfx card output level too... so it can change on the fly.
> 
> That's not a typical situation though, but nothing special would be
> happening - a new profile may be installed by the user as well,
> in which case an application should re-render to accommodate
> the change.

the user at most should be interacting with compositor settings/tools to
configure a specific profile for a display (let's assume a fixed profile for
that screen), so a compositor tool to tell the compositor the profile changed
(pressed a button on the monitor to change it). when they alter the compositor,
then compositor can tell applications.

>  > yes. compositors right now work in display colorspace. they do no
>  > conversions. eventually they SHOULD to display correctly. to do so they
>  > need a color profile for the display.
> 
> For enhanced color management yes. But core comes first, and is necessary
> for many color critical applications, because the compositor will never
> have the color transformations they require.

they will have to have them, or then not support that colorspace at all.

>  > it may be that a window spans 8 different screens all with different
>  > profiles. then what?
> 
> As I've explained several times, what happens is that the application
> is aware of this, and transforms each region appropriately - just
> as they currently do on X11/OS X/MSWin systems.

not in wayland. not acceptable. the app will never know which windows it is on.
as i have said - could be wrapped around a sphere or a room full of bunnies
bouncing about across 8 screens.

>  > with a
>  > proper color correcting compositor it can make them all look the same.
> 
> As will a color aware application given appropriate color management support.

it can't if it doesn't know how a window or buffer is transformed or mapped to
screens.

> The code is already there to do all that in color critical application.

then they get to pick a colorspace and render to that. attahc that to the
buffer. compositor will do whatever it wants. e.g. if that buffer is on the
screen it matches it'd do no transform. maybe it does no transforms at all. and
simply hovers some indicator above the serface telling you if the surface
colorspace matches the screens colorspace or not. maybe compositor disallows
the window to be moved off the screen that matches the colorspace. that can be
configured via the compositor.

>  > if i mmove the
>  > window around the client has drawn different parts of its buffer with
>  > different colorspaces/profiles in mind and then has to keep redrawing to
>  > adjust as it moves.
> 
> Yes.

and now you just hit "unacceptable in wayland land" space. which is why i tell
you that this is not acceptable.

>  > you'll be ablew to see "trails" of incorrect coloring around the
>  > boundaries of the screens untl the client catches up.
> 
> It's damage, just like any other, and color critical users using
> color critical applications will take "trails" over wrong color
> anytime. No "trails" and wrong color = a system they can't use.

and totally unacceptable for wayland space. so a big fat no to that kind of
design.

>  > the compositor SHOULD do any color correction needed at this point.
> 
> Not at all. That's a way to do it under some circumstances yes, but
> it's not satisfactory for all.

it is up to the compositor. if the goal is to make colors visibly as uniform as
is possible given the displays that exist then it should. not all compositors
will. they may do things differently like above. maybe limit location of a
window/surface or place an indicator above a window when it is fully on the
correct screen for its color profile, and/or they may transform colorspaces.

>  > if you want
>  > PROPER color correction the compositor at a MINIMUM needs to be able to
>  > report the color profile of a screen even if it does no correcting.
> 
> Yes - exactly what I'm suggesting as core color management support.

but it doesnt have to tell you which screen it is nor tell you which screen
your window is on. it's an option of 1 of various colorspaces to be able to use
given a specific compositor.

>  > yes you may have
>  > multiple screens. i really dislike the above scenario of incorrect pixel
>  > tails because this goes against the whole philosophy of "every frame is
>  > perfect".
> 
> "Every pixel being perfect" except they are the wrong color, isn't perfect.

IF the compositor is doing the transformce of colorspaces, then you can acheive
perfect pixels.

> There are multiple ways of doing the best thing possible - you can't re-rende

Re: [RFC wayland-protocols] Color management protocol

[Graeme Gill]

Carsten Haitzler (The Rasterman) wrote:
> On Sat, 17 Dec 2016 21:16:41 +1100 Graeme Gill  said:

>> That's not a typical situation though, but nothing special would be
>> happening - a new profile may be installed by the user as well,
>> in which case an application should re-render to accommodate
>> the change.
> 
> the user at most should be interacting with compositor settings/tools to
> configure a specific profile for a display (let's assume a fixed profile for
> that screen), so a compositor tool to tell the compositor the profile changed
> (pressed a button on the monitor to change it). when they alter the 
> compositor,
> then compositor can tell applications.

"Compositor tool" == color management application, such as ArgyllCMS "dispwin 
-I"!

>>  > yes. compositors right now work in display colorspace. they do no
>>  > conversions. eventually they SHOULD to display correctly. to do so they
>>  > need a color profile for the display.
>>
>> For enhanced color management yes. But core comes first, and is necessary
>> for many color critical applications, because the compositor will never
>> have the color transformations they require.
> 
> they will have to have them, or then not support that colorspace at all.

There's nothing "have to" about it. It's technically impossible for
a compositor to satisfy every applications color management requirements,
because they could be defined by the application, if it has sufficiently
specialized needs.

And I'm not sure what you mean by "supporting a colorspace".
A source colorspace is supported if a device profile exists for it that the CMM
knows how to handle. But that is not the complete story, because there
is then the details of how that profile is to be used, i.e. the
details of how it should be linked to the output profile.

> not in wayland. not acceptable. the app will never know which windows it is 
> on.
> as i have said - could be wrapped around a sphere or a room full of bunnies
> bouncing about across 8 screens.

It's also not acceptable that color be wrong. So how about trying to
come up with a solution, rather than saying "Wayland hasn't been
designed for that requirement up to now, so it can't be done" ?

> it can't if it doesn't know how a window or buffer is transformed or mapped to
> screens.

So provide mechanism for it to know!

>> The code is already there to do all that in color critical application.
> 
> then they get to pick a colorspace and render to that.

There is no colorspace to pick - a display has a characteristic
behavior. There is no choice in it, short of tweaking it's controls,
altering its calibration, or changing one of its settings.

> attahc that to the
> buffer.

Different display devices have different characteristics, hence
different profiles. So one choice will not work for a surface that
spans multiple displays.

> compositor will do whatever it wants. e.g. if that buffer is on the
> screen it matches it'd do no transform. maybe it does no transforms at all. 
> and
> simply hovers some indicator above the serface telling you if the surface
> colorspace matches the screens colorspace or not. maybe compositor disallows
> the window to be moved off the screen that matches the colorspace. that can be
> configured via the compositor.

The user will want to configure their windows as they see fit, including
moving images from one display to the other. There needs to be a mechanism
to allow color accurate display when this happens.

> and now you just hit "unacceptable in wayland land" space. which is why i tell
> you that this is not acceptable.

Wrong color is unacceptable too. So how do you solve it ?
(And it's a solved problem on all other systems. Why do
you want to cripple Wayland ?)

>> It's damage, just like any other, and color critical users using
>> color critical applications will take "trails" over wrong color
>> anytime. No "trails" and wrong color = a system they can't use.
> 
> and totally unacceptable for wayland space. so a big fat no to that kind of
> design.

So Wayland is a big fat no for anything that requires accurate color ?
Wow. And I though Wayland was intended to ultimately replace X11.
Apparently not!

>> Yes - exactly what I'm suggesting as core color management support.
> 
> but it doesnt have to tell you which screen it is nor tell you which screen
> your window is on. it's an option of 1 of various colorspaces to be able to 
> use
> given a specific compositor.

I don't see how this can work, except for limited color accuracy requirements.
Pick a small colorspace with a common gamut, and the full gamut of all displays
can't be used. Pick a large gamut and clipping policy can't be managed.

>> "Every pixel being perfect" except they are the wrong color, isn't perfect.
> 
> IF the compositor is doing the transformce of colorspaces, then you can 
> acheive
> perfect pixels.

No you can't, if the compositor doesn't have the information or algorithms
to do the transformation. This is absolutely 

Re: [RFC wayland-protocols] Color management protocol

[The Rasterman]

On Mon, 19 Dec 2016 17:01:50 +1100 Graeme Gill  said:



at this point i'm going to summarize this. this might be more helpful than
continuing point by point rebuttals as i sense that there's something missing
in this conversation:

summary of what i think should be the case (or roughly):

1. if colorspace/profile with buffer from client matches screen compositor
SHOULD do nothing with the pixels unless it has to (eg has to blend them with
content below or otherwise do effects etc. designated by its layout policy).
2. if null colorspace then compositors generally agree to ALSO not touch pixels
and transform them unless it has to blend them etc. like #1, but irrespective
of the output
3. if colorspace/profile does NOT match the display then compositor can either
a) transform colors to get them correct on another display or b) leave them
along and just leave things as they are and perhaps let the user know that the
colors for that window/surface may be wrong on that display, or limit the
screens that display that buffer based on context.

how to clients select a colorspace? compositor sends available colorspaces to
client (maybe send per surface actually?). client picks one and renders content
given that colorspace/profile and presents that to the compositor for display.
compositor may update colorspaces that are available at any time.

colorspaces/profiles should be nominal colorspace with a whole bunch of numbers
detailing adjustments/mappings to do exact color correction for that
colorspace. if i have 2 sRGB monitors i may get 2 sRGB colorspaces each with
different transform constants/gamma lut tables etc.



-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland-protocols] Color management protocol

[Niels Ole Salscheider]

On Monday, 19 December 2016, 13:08:13 CET, Graeme Gill wrote:
> Niels Ole Salscheider wrote:
> > I feel like the discussion drifts off a bit. You (Graeme) obviously know
> > much more about color management than I do. But as Pekka already pointed
> > out there are a few constraints that originate in the design decisions of
> > wayland and are quite different to these of X11. We can't change these
> > constraints but have to find a solution that works well with them:
> > 
> > - A normal application CANNOT control the hardware directly (it can't
> > program LUTs, for example).
> 
> Right, so it is not a normal application, it's a management application
> that has the privileges to do so.
> 
> > - A normal application CANNOT alter global settings of the compositor
> > (like
> > setting color profiles for the outputs). This can only be done by the
> > compositor or a few trusted applications.
> 
> Right - and therefore those trusted applications need to include
> color management applications.

Yes, exactly. But these are things that do not use the "normal" wayland 
protocols but are initiated by the compositor.
In practice this will mean that a compositor will use LCMS / ArgyllCMS / ... 
and the corresponding tools to accomplish these goals. The compositor might 
use them as libraries, or maybe have a private D-Bus interface for them.
But it will be the compositor that initiates any action.

> > The user will just have to use the
> > settings dialog provided with the compositor. Because of that it does not
> > matter if this is implementation dependent.
> 
> Hmm. I'm not sure what you mean by "settings dialog provided with the
> compositor". Sounds like an application. For color management, the user
> often needs specialist tools to create calibrations, profiles, and to
> manage the system color configuration. That's what standardized API's are
> meant to provide, a means of mixing and matching tools so that
> systems don't have to be monolithic.

Developers of compositors and CMS can (and probably should) standardize such 
an interface (for example a library API or a D-Bus interface). But this is out 
of scope for the wayland protocol.

> > - You DO NOT know which parts of a surface are shown on which screen.
> 
> So that needs to be fixed for color aware applications to be able to provide
> display colorspace values.

That will be rather difficult in general.

> > - We aim to be pixel-perfect.
> 
> Great. But perfect means the correct color as well. So mechanisms to
> provide correct color are needed if you are to achieve perfection.

I totally agree. That's why I started this discussion.

> > I think these constraints mean that we must let the compositor take part
> > in
> > the color correction, at least if more than one screen is involved.
> 
> I don't think this is either desirable, adequate, or necessary. For
> some levels of color management I agree it will be desirable and
> adequate, which is what my "Enhanced" extension sketched out, as
> a variation of your extension. But the reality is that no compositor
> can have all the required mechanisms to convert colors in the way
> that demanding color critical applications may require. So it
> shouldn't handicap Wayland in ways that none of the alternatives
> are handicapped, but provide a mechanism for applications
> to do it the way they need. It's shouldn't be hard. There are only two
> things asked of the compositor :- provide the application the Surface
> to Output region information it already has internally, and convey
> the color values to the display(s).
> 
> > If we do
> > so, we should also be able to expect that the compositor can handle a bit
> > more complicated cases (e. g. an arbitrary number of different surfaces
> > with different color profiles).
> 
> Providing source color profiles may satisfy many simple color management
> requirements, but it won't satisfy all. This is only a problem if
> there is no "escape" mechanism to work around such limitations.

I understand that you cannot satisfy all requirements by having ONLY a simple 
color conversion to output color space in the compositor.

But are there transformations from input to output color space that cannot be 
expressed as a (complex) transformation from input to intermediate space (by 
the application) and then another transformation from intermediate to output 
color space? At least as long as the intermediate color space does not clip 
any color values.
I really do not know the answer to that and I will trust you on this.

> > When I proposed this protocol my focus was on applications that may not be
> > color managed currently. I thought for example about web browsers or
> > simple
> > image viewers where I would view (but not edit) photos.
> 
> Yes, I understand. This is an important class of color management usage.
> 
> > Your focus is obviously on professional applications. I think both use
> > cases are equally important and we should not treat one as an
> > afterthough

Re: [RFC wayland-protocols] Color management protocol

[Pekka Paalanen]

Hi,

could you keep the CC list intact, please.

On Mon, 19 Dec 2016 12:37:14 +1100
Graeme Gill  wrote:

> Pekka Paalanen wrote:
> > On Wed, 14 Dec 2016 18:49:14 +1100
> > Graeme Gill  wrote:  
> 
> >> Please read my earlier posts. No (sane) compositor can implement CMM
> >> capabilities to a color critical applications requirements,
> >> so color management without any participation of a compositor
> >> is a core requirement.  
> 
> > that is a very strange requirement, and architecturally it is a big
> > step backwards.  
> 
> Since Wayland doesn't currently implement any color management support,
> I'm not following how it can be a step backwards.

It is step towards "clients are in control and the compositor does not
know what is happening". That is, a step towards X11 design and away
from Wayland design principles.


> > It
> > may have been so with X11 where any client can change any display
> > setting any time it wants, but I cannot see that happening on Wayland.  
> 
> Wayland is useless unless there is a way to manage it. Which means
> that it should have channels for administrative tools to configure it.

Indeed: Administrative tools. These are part of the compositor or the
desktop environment distribution. They have the privileges to configure
the compositor.

However, in this thread we are talking about arbitrary applications,
not administrative tools.

Administrative tools must always be written to interface with the
compositor, they cannot go changing things behind the compositor,
because then the compositor will lose track of the setting and
malfunction will happen.

We very deliberately avoid defining any "standard" Wayland interfaces
for configuring a compositor, because every compositor is different.
With X11, you had the one single X server implementation and no other.
On Wayland, every compositor is an individual, just like every X11
window manager is.

I do not want to waste time in designing a "standard configuration
interface" when the realistic expectation is that none of the major
DEs' compositor will be implementing it. They already have their own
tailor-made ways. As a case study one could look at the feature set of
xrandr tool.

If you want a standard interface, you have to get the buy-in from the
major DE projects first. One can write a protocol spec and throw it
into wayland-protocols, but whether anyone will implement it is another
matter.

> > If the pixels go through a display server, you have no choice but to
> > trust the display server to do the right thing. So the real question
> > is: "How do you let the compositor do the right thing?"
> > Not: "How do I bypass the compositor?"  
> 
> I didn't ask to bypass the compositor - you are the one assuming that.
> 
> I merely asked that core color management provide a means hat allows the
> application to provide display colorspace values, and that the compositor
> not mess with them.

That is one of the things you said you want. You also said that:
"Which is why protocols for controlling the hardware should ideally go
via Wayland, so that applications who's job is to setup that hardware
can work."

Those are two very very different things.

The first one I agree. The second one I strongly object unless it
originates from more than one DE project and is kept non-essential for
correct operation. Please, do not conflate them.

> > - You do not know which parts of a window are shown on which outputs.  
> 
> Right. So that information needs to be communicated to the application,
> just like it currently is on systems like X11, OS X and MSWin.

No, it will not. The application cannot keep up with window moves
re-rendering the regions and the compositor cannot wait for the
application to catch up. Adding features that cannot be implemented
without introducing glitches was fine with X11, but it is not ok in
Wayland.

In this case, it is possible to achieve the goal without introducing
such glitches.

> > - Calibration (i.e. modifying compositor configuration)  
> 
> No, calibration in this context is setting the CRTC per channel
> lookup tables (RAMDAC contents).

That *is* compositor configuration. There is no other entity to
maintain it. See the reference to libinput configuration below as an
example of another similar case.

> >   must
> >   necessarily be a separate interface from the ones used by
> >   applications that only want to present color-managed content.  
> 
> Sure. Which is what I suggested.

You have mentioned configuration being separate maybe once or twice,
yet in every turn you have been promoting configuration as a necessary
part in conjuction with the public color-managed content interfaces,
conflating the two into one, hence my objection.

> >   Conflating it all into a single interface will cause problems with
> >   privilege separation and encourage usage patterns where different
> >   applications cannot work at the same time because they will be
> >   fighting over who gets to set the current configuration

Re: [RFC wayland-protocols] Color management protocol

[James Feeney]

On 12/19/2016 03:04 AM, Pekka Paalanen wrote:
> We very deliberately avoid defining any "standard" Wayland interfaces
> for configuring a compositor, because every compositor is different.
> With X11, you had the one single X server implementation and no other.
> On Wayland, every compositor is an individual, just like every X11
> window manager is.
> 
> I do not want to waste time in designing a "standard configuration
> interface" when the realistic expectation is that none of the major
> DEs' compositor will be implementing it. They already have their own
> tailor-made ways. As a case study one could look at the feature set of
> xrandr tool.

At first glance, that comes across as off-point and shirking responsibility,
where Weston boastfully promotes itself as "*the* reference implementation of a
Wayland compositor, and a useful compositor in its own right".

Where is *Weston's* "pixel perfect" Color Management System?

Unless the argument is convincingly made that *nothing* will ever be required
from the Wayland protocol in order for any compositor to implement a "pixel
perfect" CMS, on its own, then 'deliberately avoid[ing] defining any "standard"
Wayland interfaces for configuring a compositor' is just "throwing a monkey
wrench" into the conversation.

To convincingly make that argument, create the Weston "pixel perfect" CMS, and
demonstrate that nothing CMS related was required from the Wayland protocol.

What is the design outline of that Wayland-protocol-free CMS?
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland-protocols] Color management protocol

[Jason Gerecke]

On Mon, Dec 19, 2016 at 7:04 AM, James Feeney  wrote:
> On 12/19/2016 03:04 AM, Pekka Paalanen wrote:
>> We very deliberately avoid defining any "standard" Wayland interfaces
>> for configuring a compositor, because every compositor is different.
>> With X11, you had the one single X server implementation and no other.
>> On Wayland, every compositor is an individual, just like every X11
>> window manager is.
>>
>> I do not want to waste time in designing a "standard configuration
>> interface" when the realistic expectation is that none of the major
>> DEs' compositor will be implementing it. They already have their own
>> tailor-made ways. As a case study one could look at the feature set of
>> xrandr tool.
>
> At first glance, that comes across as off-point and shirking responsibility,
> where Weston boastfully promotes itself as "*the* reference implementation of 
> a
> Wayland compositor, and a useful compositor in its own right".
>
> Where is *Weston's* "pixel perfect" Color Management System?
>
> Unless the argument is convincingly made that *nothing* will ever be required
> from the Wayland protocol in order for any compositor to implement a "pixel
> perfect" CMS, on its own, then 'deliberately avoid[ing] defining any 
> "standard"
> Wayland interfaces for configuring a compositor' is just "throwing a monkey
> wrench" into the conversation.
>
> To convincingly make that argument, create the Weston "pixel perfect" CMS, and
> demonstrate that nothing CMS related was required from the Wayland protocol.
>
> What is the design outline of that Wayland-protocol-free CMS?

I can certainly see where you're coming from, as I too had similar
thoughts when getting my feet wet with with protocol design for tablet
input events. What it basically comes down to is that standardized
Wayland protocols are intended for providing features to "general
purpose" applications. Standardized protocols are not generally used
for configuring compositors for multiple reasons, e.g. recognizing
that not every compositor will want to offer the same configuration
options in the same way (read: feature-creep of configuration
interfaces with ever-more-niche options that only matter to single
compositors), and concerns about random applications changing settings
(read: sensitive/priviliged operations and applications "fighting"
each other to apply conflicting configs).

There is no "standard configuration interface" for something even so
basic as configuring input devices. It sure feels like shirking
responsibility, but its a conscious design decision to try and avoid
some of the pain points that we lived with in X.

Its possible to separate concerns of usage from configuration without
"throwing a monkey wrench" into the conversation. Its just necessary
to be mindful that defining (standard) Wayland interfaces is not
necessarily always the appropriate design decision. I'm just a
hobbyist photographer whose done casual reading about color management
and use a second-hand colorimeter and can't wait to see some color
management come to Wayland. But it will be necessary to figure out
exactly how to deal with its complexities in a way that is compatible
with Wayland's fundamental design decisions.

Jason
---
Now instead of four in the eights place /
you’ve got three, ‘Cause you added one  /
(That is to say, eight) to the two, /
But you can’t take seven from three,/
So you look at the sixty-fours
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland-protocols] Color management protocol

[Graeme Gill]

Niels Ole Salscheider wrote:

> Yes, exactly. But these are things that do not use the "normal" wayland 
> protocols but are initiated by the compositor.

I'm not sure what you mean by that. Why should the compositor launch
applications ? The user should launch applications they want to
use in the normal fashion they launch applications!

> In practice this will mean that a compositor will use LCMS / ArgyllCMS / ... 
> and the corresponding tools to accomplish these goals. The compositor might 
> use them as libraries, or maybe have a private D-Bus interface for them.
> But it will be the compositor that initiates any action.

Not going to happen. They are not libraries, they are full blown,
complex applications. And they can't use D-Bus, because Wayland
doesn't use D-Bus. Think of (a future) remote Wayland as a test case.
How does a the remote user calibrate, profile and install the
a profile at a remote display they are sitting at ?
To work anywhere a Wayland application works, they
need to be Wayland applications, using the Wayland protocol.
(And the user will rightfully want to be able to choose
 which color management tools they use, not be locked into
 whatever the compositor provides - if it provides anything
 at all that is, something I rather doubt.)

> Developers of compositors and CMS can (and probably should) standardize such 
> an interface

And that is exactly what I want to happen.

>  (for example a library API or a D-Bus interface).

Using different mechanisms for communication raises
a host of issues about support and coordination of
Wayland and color management actions.

> But this is out of scope for the wayland protocol.

Why is that so, given that compositor at the end of the Wayland
protocol has the job of managing graphics hardware ?

>>> - You DO NOT know which parts of a surface are shown on which screen.
>>
>> So that needs to be fixed for color aware applications to be able to provide
>> display colorspace values.
> 
> That will be rather difficult in general.

I simply don't understand why. Wayland already has some of that
information available, in a less precise way :- it has
enter and leave events when a surface starts overlapping
or ceases to overlap a scanout region of an output.
All that is needed is the region information to
go along with those events.

> I understand that you cannot satisfy all requirements by having ONLY a simple 
> color conversion to output color space in the compositor.
> 
> But are there transformations from input to output color space that cannot be 
> expressed as a (complex) transformation from input to intermediate space (by 
> the application) and then another transformation from intermediate to output 
> color space? At least as long as the intermediate color space does not clip 
> any color values.
> I really do not know the answer to that and I will trust you on this.

Yes. The ICC PCS mix-and-match model has some notable limitations -
in fact it verges on conceptually broken, because it's not possible
to do real gamut mapping because the source gamut is divorced from
the destination gamut when the transformations are created.
The PRMG approach is sort of a fudgy workaround, but can't solve
the problem. See
 for a discussion
that touches on this.

So if an application is content to use pre-computed ICC A2B and B2A
transforms, and put up with the limitations of mix-and-match
intent selection and operation (perhaps it is satisfied by
colorimetric with profile default clipping, or generalized
gamut compression), then this is perfectly fine, and covers
a lot of ground. But I don't think a color management
solution should prevent an application doing better than
this if it wishes to go to the trouble, nor do I think
that Wayland should have limitations that preceding systems
don't have. Doing better than this means constructing overall
device to device transforms (source space to display space) where it
can use real gamut mappings, and can compute
higher precision transforms by inverting the A2B table
of the output profile rather than using the lower precision
pre-computed B2A table, etc. Or maybe some detail of the
compositor CMM doesn't work properly (CMM's have differences
and bugs), so an ability to implement its own CMM
is highly desirable. On top of that, calibration and
profiling applications need to be able to set display
values to do their job. So all this adds up to some means
of passing color values unchanged (or perhaps with an application
determined device to device conversion, which could be set to null)
from the application to the display.

>> I sketched out two extensions. Please critique and/or refine and/or contrast
>> them with other alternatives
> 
> Apart from one thing you already have your core profile as far as the wayland 
> protocol is concerned.

You mean the display ICC profile ? How is that set though ?

> The one thing missing from a wayland protocol perspective is t

Re: [RFC wayland-protocols] Color management protocol

[Graeme Gill]

Pekka Paalanen wrote:

> could you keep the CC list intact, please.

Sorry - no. I don't like getting spammed with multiple copies
of the same email, so I don't do it to other people.

>> Since Wayland doesn't currently implement any color management support,
>> I'm not following how it can be a step backwards.
> 
> It is step towards "clients are in control and the compositor does not
> know what is happening". That is, a step towards X11 design and away
> from Wayland design principles.

It depends on what you mean by "control". Wayland can't operate
without applications providing the content, and color is part of
content.

>> Wayland is useless unless there is a way to manage it. Which means
>> that it should have channels for administrative tools to configure it.
> 
> Indeed: Administrative tools. These are part of the compositor or the
> desktop environment distribution. They have the privileges to configure
> the compositor.

And how are management functions that can't reasonably be contained
in the compositor handled then ?
A compositor is _not_ going to come with display color calibration
and profiling functionality - it's too complex and specialized.
The user will insist on being able to choosing such tools anyway.

> However, in this thread we are talking about arbitrary applications,
> not administrative tools.

There is no difference, apart from any privilege needed.

> Administrative tools must always be written to interface with the
> compositor, they cannot go changing things behind the compositor,
> because then the compositor will lose track of the setting and
> malfunction will happen.

Sorry - I'm not following. You mean that the compositor doesn't
pay any attention to the Wayland protocol ?

> We very deliberately avoid defining any "standard" Wayland interfaces
> for configuring a compositor, because every compositor is different.
> With X11, you had the one single X server implementation and no other.
> On Wayland, every compositor is an individual, just like every X11
> window manager is.

What is the point of Wayland then ? If it doesn't standardize
a protocol so that applications can be written once to
that protocol and will run on all systems that conform
to that protocol, why bother with it at all ?

> I do not want to waste time in designing a "standard configuration
> interface" when the realistic expectation is that none of the major
> DEs' compositor will be implementing it. They already have their own
> tailor-made ways. As a case study one could look at the feature set of
> xrandr tool.

Please point out the "tailor-made ways" they all have of
supporting color management then!

And you are mistaken if you think that color management tool
or application authors like myself are about to create N different
versions of our applications for each of the different
compositors different "tailor-made ways"! Life is simply
too short.

So the future is pretty clear - if Wayland doesn't accommodate
color management, then no applications or users of color
applications are ever going to use Wayland. No
Scribus, Krita, GIMP, Inkscape or Darktable for Wayland.
No Photographers, Videographers or Desktop publishers using
Wayland.

> If you want a standard interface, you have to get the buy-in from the
> major DE projects first. One can write a protocol spec and throw it
> into wayland-protocols, but whether anyone will implement it is another
> matter.

Go right ahead and build the barriers to supporting Wayland higher then.

> That is one of the things you said you want. You also said that:
> "Which is why protocols for controlling the hardware should ideally go
> via Wayland, so that applications who's job is to setup that hardware
> can work."
> 
> Those are two very very different things.

Yes, but they are related by both being about supporting
color management, and the fact the color profile for
a display depends on its calibration state.

> The first one I agree. The second one I strongly object unless it
> originates from more than one DE project and is kept non-essential for
> correct operation. Please, do not conflate them.

Setting VideoLUTs has been standard in display systems almost
forever. Find a way of implementing support in Wayland, so
that color management can happen in Wayland.

> No, it will not. The application cannot keep up with window moves
> re-rendering the regions and the compositor cannot wait for the
> application to catch up. Adding features that cannot be implemented
> without introducing glitches was fine with X11, but it is not ok in
> Wayland.

If the founding principles of Wayland turn out to be based on faulty
assumptions, then you need to either revisit those principles
or abandon Wayland.

> That *is* compositor configuration. There is no other entity to
> maintain it. See the reference to libinput configuration below as an
> example of another similar case.

It's display configuration, which is (presumably) the compositors
job to help the user manage.

Re: [RFC wayland-protocols] Color management protocol

[Graeme Gill]

Jason Gerecke wrote:
> On Mon, Dec 19, 2016 at 7:04 AM, James Feeney  wrote:

>> What is the design outline of that Wayland-protocol-free CMS?
> 
> I can certainly see where you're coming from, as I too had similar
> thoughts when getting my feet wet with with protocol design for tablet
> input events. What it basically comes down to is that standardized
> Wayland protocols are intended for providing features to "general
> purpose" applications. Standardized protocols are not generally used
> for configuring compositors for multiple reasons, e.g. recognizing
> that not every compositor will want to offer the same configuration
> options in the same way (read: feature-creep of configuration
> interfaces with ever-more-niche options that only matter to single
> compositors), and concerns about random applications changing settings
> (read: sensitive/priviliged operations and applications "fighting"
> each other to apply conflicting configs).

Input events are nowhere as closely related to the rendering
systems as color management is though. Color management is
to do with the actual pixel values, the way that pixels
get rendered by (say) a GPU (if there is a compositor
implementation of a CMM), the way the pixels get routed
to displays, the setup of the pipeline from frame buffer
to display, and the communication to and from the display
itself. Nor is this compositor specific - many applications
have color management goals, and all applications and the
desktop benefit from a mechanism to manage display
characteristics when faced with the wide gamut problem,
and it is desirable that all Wayland compositors support
some level of color management.

> There is no "standard configuration interface" for something even so
> basic as configuring input devices. It sure feels like shirking
> responsibility, but its a conscious design decision to try and avoid
> some of the pain points that we lived with in X.

That's all fine if it is something that is 1) clearly separate
from rendering and the display and 2) that there is a mechanism
(say a standard server boilerplate) to setup specific standardized
extra services related to the desktop, rather than merely shifting
pain points from one area to another.

> Its possible to separate concerns of usage from configuration without
> "throwing a monkey wrench" into the conversation. Its just necessary
> to be mindful that defining (standard) Wayland interfaces is not
> necessarily always the appropriate design decision. I'm just a
> hobbyist photographer whose done casual reading about color management
> and use a second-hand colorimeter and can't wait to see some color
> management come to Wayland.

Might be waiting a while at the current rate. Don't delete your
X11 server just yet.

> But it will be necessary to figure out
> exactly how to deal with its complexities in a way that is compatible
> with Wayland's fundamental design decisions.

Or be prepared to re-visit Wayland's fundamental design decisions
if they turn out to be based on a false premise.

Graeme Gill.

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland-protocols] Color management protocol

[Pekka Paalanen]

On Mon, 19 Dec 2016 08:04:48 -0700
James Feeney  wrote:

> On 12/19/2016 03:04 AM, Pekka Paalanen wrote:
> > We very deliberately avoid defining any "standard" Wayland interfaces
> > for configuring a compositor, because every compositor is different.
> > With X11, you had the one single X server implementation and no other.
> > On Wayland, every compositor is an individual, just like every X11
> > window manager is.
> > 
> > I do not want to waste time in designing a "standard configuration
> > interface" when the realistic expectation is that none of the major
> > DEs' compositor will be implementing it. They already have their own
> > tailor-made ways. As a case study one could look at the feature set of
> > xrandr tool.  
> 
> At first glance, that comes across as off-point and shirking responsibility,
> where Weston boastfully promotes itself as "*the* reference implementation of 
> a
> Wayland compositor, and a useful compositor in its own right".
> 
> Where is *Weston's* "pixel perfect" Color Management System?
> 
> Unless the argument is convincingly made that *nothing* will ever be required
> from the Wayland protocol in order for any compositor to implement a "pixel
> perfect" CMS, on its own, then 'deliberately avoid[ing] defining any 
> "standard"
> Wayland interfaces for configuring a compositor' is just "throwing a monkey
> wrench" into the conversation.
> 
> To convincingly make that argument, create the Weston "pixel perfect" CMS, and
> demonstrate that nothing CMS related was required from the Wayland protocol.
> 
> What is the design outline of that Wayland-protocol-free CMS?

Hi,

it sounds like you too are conflating configuration with the public
interface to deliver color-managed content.

Wayland protocol must grow extensions to let applications tell the
compositor what kind of content they provide for color management
purposes, and probably also let the applications know which color
management features the compositor supports. A very related and useful
part of this is letting the applications know what kind of outputs the
compositor is using and what their calibration/color profile currently
is, but even more importantly, what kind or which color
profile/space/... definitions it can handle.

That is exactly where Niels started, and he started in the right end
of things. The questions to discuss are how do you represent a color
profile/whatever and how do you attach one with a wl_surface or a
wl_buffer, and how should a compositor process that; what guarantees
must a compositor make if it advertises some features; what information
does the compositor need to expose; etc. The important bit is that the
compositor's global state is read-only in this interface.

What I do not want to see as an integral part of this effort is a
compositor configuration interface, where a client can *change* how the
compositor operates globally, what the color data associated with an
output is, or how the hardware is configured. Why? Because it will take
literally many years to design and agree on. I don't want to block the
design and implementation of the application interface on that.

I hope I finally made that crystal clear.

Yes, you also need tools and interfaces for calibration and
configuration.

At this time, calibration needs to be considered on the level of how to
present a calibration image, so that you know what a measurement device
is measuring. Whether that should be integrated into the normal Wayland
interface applications usually use is an open question, but at first
hand I would advice against it: it may require resetting the hardware
state, which is a global operation, and hence needs to be privileged.
It is reasonable to design it as a Wayland interface rather than any
other, because it relies on presenting an image through Wayland.

Applying compositor configuration OTOH has no reason to be a Wayland
interface. You are not presenting anything through it, you are making
settings that are at most per-output, and there you do not gain
anything from using Wayland as the transport. I bet there will be
compositors which are configured by editing a settings file, for
instance. I would not want to deny them from implementing any kind of
color management support.

Every compositor is an individual. If you cannot design the public
interface for applications without also designing the configuration
interface and requiring everyone to implement both, it will take a very
long time to be adopted, if ever. The different DE and compositor
projects are not unanimous on how you map a normal window which is a
fundamental basic operation of all window systems, how could they ever
agree on a configuration interface?

Since the people demanding that everything must be
application-controlled from the start and that the compositor must do
nothing and know nothing are seasoned CMS developers (I presume), I
suspect they are trying to force the X11 model of doing CMS upon
Wayland. Is it really impossible to separ

Re: [RFC wayland-protocols] Color management protocol

[Pekka Paalanen]

On Tue, 20 Dec 2016 15:17:31 +1100
Graeme Gill  wrote:

> Pekka Paalanen wrote:
> >> Since Wayland doesn't currently implement any color management support,
> >> I'm not following how it can be a step backwards.  
> > 
> > It is step towards "clients are in control and the compositor does not
> > know what is happening". That is, a step towards X11 design and away
> > from Wayland design principles.  
> 
> It depends on what you mean by "control". Wayland can't operate
> without applications providing the content, and color is part of
> content.

When I was talking about configuration, your reply talks about content
delivery. We are continuously talking past each other. I talk about one
thing, you deliberately interpret me talking about the other thing, so
that you can make me look silly. I'm tired of correcting that in every
turn.

Clients control what they send to the compositor: that is content
delivery.

Configuration controls compositor's global settings, like CRTC CLUT
values.

This difference is fundamental to any kind of Wayland protocol design.
And it is DIFFERENT from X11 on purpose.

> >> Wayland is useless unless there is a way to manage it. Which means
> >> that it should have channels for administrative tools to configure it.  
> > 
> > Indeed: Administrative tools. These are part of the compositor or the
> > desktop environment distribution. They have the privileges to configure
> > the compositor.  
> 
> And how are management functions that can't reasonably be contained
> in the compositor handled then ?
> A compositor is _not_ going to come with display color calibration
> and profiling functionality - it's too complex and specialized.
> The user will insist on being able to choosing such tools anyway.

Why would you not let compositors use the CMS libraries people have
developed?

Or are all today's CMS implementations so intimitely written to the X11
model that they simply cannot work at all? That would be very sad, but
also something that requires work on them, not only on Wayland and
compositors.

Maybe the CMS implementations should be primarily used by the
compositors rather than applications then.

> > However, in this thread we are talking about arbitrary applications,
> > not administrative tools.  
> 
> There is no difference, apart from any privilege needed.

This is where we disagree, and that prevents us from making any
progress.


Thanks,
pq


pgp8atNFoo05F.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland-protocols] Color management protocol

[Kai-Uwe]

Am 20.12.2016 um 10:08 schrieb Pekka Paalanen:
> Niels had an extremely good point that compositors *can* do all the
> hard stuff too, by using the libraries the CMS experts have written.
> This is not the X11 where you cannot add these features and
> dependencies to the X server.

That's not correct. Keith Packard and other people rejected the idea of
adding a new XCMS layer in the X server. He said color conversion
belongs into the window manager. So we are using today the X property
system to communicate between applications, compositors and
configuration libraries/systemsettings dialogs (beside the
Xinerama/XRandR gamma table APIs).

IMO the main difference to wayland is that: we do not know a similar
inherent transport mechanism for meta data like Xatom is for X11. (I
share Graemes position, that the meta data communication path should
match that of wayland in order to remain compatible. I do not like the
idea to randomly add different mechanism as wayland extents
capabilities. Most relevant image file formats had adopted some way to
attach meta data. Otherwise workflows are not flexible enough.) That
meta data communication path has __not__ necessarily the need to
configure wayland.

Kai-Uwe
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland-protocols] Color management protocol

[Kai-Uwe]

Am 20.12.2016 um 03:38 schrieb Graeme Gill:
> Niels Ole Salscheider wrote:
>> What MIGHT be possible is that an application provides the complete surface 
>> in 
>> all color spaces of all outputs so that the compositor can use the parts it 
>> needs.
> 
> Yes, that's an interesting thought.

It appears to be expensive to me. [But there might be tricks like area
events to signal repaint demand.]

> Another thought that avoids
> the application having to know the exact surface to output mapping
> would be for the application to provide a device link for
> each output (I'm currently thinking through the implications
> of such an approach.)

Device Link ICC profile solve the desire to completely describe a
conversion inside the display encoding (3*precision_of_choice).

A device link could be used to
* provide a relatively simple means for injecting values to the GPU
shaders. ( That needs to carefully define a compatibility subset. Device
links can have lots of features like all other ICC profile classes,
which are hard to reimplement. Close to what we see in compositors are
3D LUT support. Extending that by curves makes a lot of sense to support
the desired gamma 1.0 blending spaces: e.g. matrix/shaper curves[ICC
v2], parametric curves[ICC v4] + 3D LUTs[mtf2 ICC v2] || [mAB ICC v4]. )
* compositors can read plain values from the device link profile without
any conversion by a ICC CMM
* applications gain a lot of flexibility, like support for effects etc.
* a agent could take over the device link creation for all applications,
which do not know about howto

on the downside:
* clients need to see output changes to supply a matching ICC device
link for the new/changed device
* device links work not for n > number of display channels (cmyk is
impossible that way). The n-channels (n >= 4) clients need still
information about outputs + window regions.

> Both ideas have similar issues -
> you really want the per output pixels or device links to
> be provided by the application on demand - i.e. when a surface
> first overlaps an output, so that it doesn't have to pre-compute
> pixels or device links for all possible outputs, even if they
> never get used. This has interactivity implications. I think

Pressing the monitor simulates a new space or adding a new hot monitor
triggers a similar update demand.

Maybe the device link is kind of a extension for later implementation.

Kai-Uwe
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland-protocols] Color management protocol

[Richard Hughes]

On 20 December 2016 at 07:22, Graeme Gill  wrote:
> Or be prepared to re-visit Wayland's fundamental design decisions
> if they turn out to be based on a false premise.

I don't think that's fair. I think Wayland is the opportunity to upset
the status quo with color management and do correctly what what never
possible with X11.

Lets be honest for a moment. How many applications support color
management on the Linux desktop? We're asking application authors to
understand things like blending spaces, source and destination
profiles, vcgt, overlapping windows on different crtc's and horrible
concepts like that.

As a framework guy, _and_ an app developer I just want to tag one
surface with a colorspace and then let the compositor figure out all
the grotty details. Anything more and the application author will just
decide it's not worth the bother. To calibrate we just ask for a
surface that's not going to be tampered with, but we don't want to
optimize for this super-uncommon case.

Concepts like _ICC_PROFILE are not going to happen in Wayland, and I
really thing a "late" bound color workflow is what Wayland should be
working towards. We can't live in the 1990's any longer.

Richard.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland-protocols] Color management protocol

[Pekka Paalanen]

On Tue, 20 Dec 2016 13:05:10 +0100
Kai-Uwe  wrote:

> Am 20.12.2016 um 10:08 schrieb Pekka Paalanen:
> > Niels had an extremely good point that compositors *can* do all the
> > hard stuff too, by using the libraries the CMS experts have written.
> > This is not the X11 where you cannot add these features and
> > dependencies to the X server.  
> 
> That's not correct. Keith Packard and other people rejected the idea of
> adding a new XCMS layer in the X server. He said color conversion
> belongs into the window manager. So we are using today the X property
> system to communicate between applications, compositors and
> configuration libraries/systemsettings dialogs (beside the
> Xinerama/XRandR gamma table APIs).

Oh nice. So indeed, CMS belongs in the compositor too (not only
clients), because it is the window manager in the Wayland architecture.

But yes, I did mean to include also political decisions on what belongs
where.

> IMO the main difference to wayland is that: we do not know a similar
> inherent transport mechanism for meta data like Xatom is for X11. (I
> share Graemes position, that the meta data communication path should
> match that of wayland in order to remain compatible. I do not like the
> idea to randomly add different mechanism as wayland extents
> capabilities. Most relevant image file formats had adopted some way to
> attach meta data. Otherwise workflows are not flexible enough.) That
> meta data communication path has __not__ necessarily the need to
> configure wayland.

Meta-data is fine. Totally fine. That's what we do need in Wayland, and
that is what Niels has been working on.

Global configuration (e.g. programming display CLUTs) is a completely
different thing. That is my clash with Graeme.

After thinking about my last reply to Graeme, I have become more
convinced that compositors must be full-fledged CMS users, not only
applications. Now the question becomes: what do you need from Wayland,
so that the application side instance of CMS can relay the necessary
information to the compositor-side CMS, so that the compositor can do
the right thing? And vice versa.

When one integrates a CMS in a compositor, you no longer need to
expose configuration (hardware configuration, like CLUT programming)
via any protocol. The compositor talks directly with the CMS and if the
compositor can set e.g. CLUTs, CMS can tell it what to set.

I am assuming that the compositor can interface with a CMS by calling
into a library offered by the CMS. If that interfacing was previously
done over X11, then you have to write that library. It will be more
efficient too, since you don't have to serialize and deserialize, and
asynchronicity (problems) appear only when you want to.

I'm slowly starting to suspect that CMS designers need a slight paradigm
shift: the compositor is meant to integrate with the CMS, instead of
the CMS given low-level access to the hardware bypassing the window
manager. CMS is no longer something that can be bolted on externally,
like it is in X11. Embrace the idea of integration, and I belive and
hope that it will pay off as a much more reliable architecture and
polished user interfaces. Some of what used to go over X11 would
probably be much better as a library ABI, but in X11 times it was not
possible because X11 implied separate processes.

Btw. in X11, how do CMS integrate/interface with compositing managers?
Who does the colorspace etc. conversions? How do you control blending
spaces? How have you implemented GPU-accelerated color mapping?

The compositor internal interfaces can and should be used for what
Xinerama, RandR and whatever you have been using to configure an X
server through X11. This time, the compositor needs to load and
interface with the CMS.


As to what you really need from Wayland, there are two ways that are
perhaps even complementary:

1. The one Niels started with: a standard protocol extension that is
   used manually.

2. The approach what e.g. libEGL uses: if you have a particular CMS
   implementation, and the compositor initializes the CMS, the CMS can
   hook up it's very own Wayland protocol extensions. When a client
   initializes the same CMS, the CMS looks up the
   CMS-implementation-specific extension from the Wayland display, and
   uses it. This way everything about the Wayland protocol extension is
   actually private to the CMS implementation. The cost is that you
   need a library ABI in the CMS, one for compositors and one for
   clients.

A "benefit" of option 2 is that you don't have to go through the
Wayland upstream review process but only your own.


Thanks,
pq


pgp5ua0p4wtIg.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland-protocols] Color management protocol

[Kai-Uwe]

Am 20.12.2016 um 14:08 schrieb Pekka Paalanen:
> On Tue, 20 Dec 2016 13:05:10 +0100
> Kai-Uwe  wrote:
> Oh nice. So indeed, CMS belongs in the compositor too (not only
> clients), because it is the window manager in the Wayland architecture.

The compositor has at least access to the gamma table API and output
dimension information, which matches Graemes base CM

> But yes, I did mean to include also political decisions on what belongs
> where.

To have the most common client surface/buffer ICC profile -> wayland
case covered is a good political signal.

> After thinking about my last reply to Graeme, I have become more
> convinced that compositors must be full-fledged CMS users, not only
> applications. Now the question becomes: what do you need from Wayland,
> so that the application side instance of CMS can relay the necessary
> information to the compositor-side CMS, so that the compositor can do
> the right thing? And vice versa.

base CM
* set/get graphics card gamma table curves
  * profiler and CMS
* set/get the compositor ICC device profile per output
  * profiler and CMS
* CM off-switch per client surface/buffer
  * useful for early color binding
  * profiling
* get output dimensions and notified about changes
  * help profilers with UI layout
  * early color binding
* get output EDID and notified about changes
  * identify monitor
  * preselect profiles in UIs for a monitor
  * configuration and online ICC Taxi DB
  * ICC profile generation from EDID

advanced CM:
* set document/surface/buffer source ICC profile
  * set and forget - great for most clients
* set document/surface/buffer <-> output ICC device link profile
  * very advanced
  * reduces even further the need for early color binding
  * movie tools like blender, video players etc.
  * use custom CMM with own gamut mapping algorithm
  * use effects
  * adapt to viewing environment ...
* set a CMS of choice inside the compositor to replace lcms if needed.

> When one integrates a CMS in a compositor, you no longer need to
> expose configuration (hardware configuration, like CLUT programming)
> via any protocol. The compositor talks directly with the CMS and if the
> compositor can set e.g. CLUTs, CMS can tell it what to set.

only for the content channels <= display channels and content precision
is <= surface precision

I doubt that we can always know, what is needed for a CMS hungry /
demanding client.

> I am assuming that the compositor can interface with a CMS by calling
> into a library offered by the CMS. If that interfacing was previously
> done over X11, then you have to write that library. It will be more
> efficient too, since you don't have to serialize and deserialize, and
> asynchronicity (problems) appear only when you want to.

Making this selectable similar to XDG desktop file selectors for DE's.
Is there a path to install such libraries into? What is the API to
interface with? I guess ArgyllCMS, Oyranos CMS and others might be
interested. DE integrators, administrators and users are switching those
on a regular basis, but need now to de-/install packages.

> I'm slowly starting to suspect that CMS designers need a slight paradigm
> shift: the compositor is meant to integrate with the CMS, instead of
> the CMS given low-level access to the hardware bypassing the window
> manager. CMS is no longer something that can be bolted on externally,
> like it is in X11. Embrace the idea of integration, and I belive and
> hope that it will pay off as a much more reliable architecture and
> polished user interfaces.

Agreed to the extent that clients can pass enough precision and channels
to the compositor CMS. (I was never able to handle e.g. CMYK, 6-channel
or HDR content inside the compositor.)

> Some of what used to go over X11 would
> probably be much better as a library ABI, but in X11 times it was not
> possible because X11 implied separate processes.
> 
> Btw. in X11, how do CMS integrate/interface with compositing managers?

KolorServer:
* kded daemon + D-Bus messages <-> KWin core
https://userbase.kde.org/Color_Management

CompICC:
* plug-in to Compiz, is part of the main process with access to
most(all?) internals
http://www.oyranos.org/FOSDEM2012/ColourManagementInCompositors2012.pdf

> Who does the colorspace etc. conversions?

ICC profiles -> CMM (lcms or others) -> 3D texture

> How do you control blending spaces?

ugly monitor color space blending, its a known limitation

> How have you implemented GPU-accelerated color mapping?

Yes, for instant and CPU relaxing color conversions, both of the above
implementations use shaders with OpenGL 3D textures.

For gamma 1.0 handling to work, the shaders need to accept in-and output
curves. Otherwise there is really ugly color banding as can be seen in
cameraRAW displaying through the above KDE/Compiz color servers.

> The compositor internal interfaces can and should be used for what
> Xinerama, RandR and whatever you have been using to configure an X
> server through X11.

Re: [RFC wayland-protocols] Color management protocol

[Daniel Stone]

Hi Graeme,

On 17 December 2016 at 10:16, Graeme Gill  wrote:
>> then no need for any extension. :) compositor HAs to be involved to at
>> least
>> tell you the colorspace of the monitor... as the screen is its resource.
>
> As I've explained a few times, and extension is needed to provide
> the Output region information for each surface, as well as each
> outputs color profile, as well as be able to set each Outputs
> per channel VideoLUT tables for calibration.

That's one way of looking at it, yes. But no, the exact thing you're
describing will never occur for any reason. If you'd like to take a
step back and explain your reasoning, as well as the alternate
solutions you've discarded, then that's fine, but otherwise, with a
firm and resolute 'no, never' to this point, we're at a dead end.

Cheers,
Daniel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland-protocols] Color management protocol

[Chris Murphy]

On Tue, Dec 20, 2016 at 10:02 AM, Daniel Stone  wrote:
> Hi Graeme,
>
> On 17 December 2016 at 10:16, Graeme Gill  wrote:
>>> then no need for any extension. :) compositor HAs to be involved to at
>>> least
>>> tell you the colorspace of the monitor... as the screen is its resource.
>>
>> As I've explained a few times, and extension is needed to provide
>> the Output region information for each surface, as well as each
>> outputs color profile, as well as be able to set each Outputs
>> per channel VideoLUT tables for calibration.
>
> That's one way of looking at it, yes. But no, the exact thing you're
> describing will never occur for any reason. If you'd like to take a
> step back and explain your reasoning, as well as the alternate
> solutions you've discarded, then that's fine, but otherwise, with a
> firm and resolute 'no, never' to this point, we're at a dead end.

We can't have multiple white points on the display at the same time;
it causes incomplete user adaptation and breaks color matching
everywhere in the workflow. The traditional way to make sure there is
only one white point for all programs is manipulating the video card
LUTs. It's probably not the only way to do it. But if it's definitely
not possible (for reasons I'm not really following) for a privileged
display calibration program to inject LUT data, and restore it at boot
up time as well as wake from sleep, then another way to make certain
there's normalized color rendering on the display is necessary.

The holy grail is as Richard Hughes describes, late binding color
transforms. In effect every pixel that will go to a display is going
to be transformed. Every button, every bit of white text, for every
application. There is no such thing as opt in color management, the
dumbest program in the world will have its pixels intercepted and
transformed to make sure it does not really produce 255,255,255
(deviceRGB) white on the user display.

The consequences for a single dumb program, for even 2 seconds,
showing up on screen with 255,255,255 white on an uncalibrated display
is the user's white point adaptation is clobbered for at least 10
minutes, possibly 30 or more minutes. And it doesn't just affect the
other things they're viewing on the display, it will impact their
ability to reliably evaluate printed materials in the same
environment.

So the traditional way of making absolutely certain no program can
hose the workflow is this crude lever in the video card. If you can
come up with an equivalently sure fire reliable s that doesn't demand
that the user draw up a list of "don't ever run these programs" while
doing color critical work, then great. Otherwise, there's going to
need to be a way to access the crude calibration lever in the video
card. Even though crude, this use case is exactly what it's designed
for.


-- 
Chris Murphy
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland-protocols] Color management protocol

[Daniel Stone]

Hi,
I'm going to be very blunt here, because the attitude, arrogance, lack
of respect and civility, and general unwillingness to see a point
demonstrated by multiple people in this thread is perhaps the worst
I've ever seen on this list.

I recommend you re-read Pekka's emails a couple of times until they
sink in. It is clear that you are extremely experienced in colour
management; more so than most in this discussion. It is equally clear
that you do not understand Wayland as a system, its fundamental design
principles, nor the things modern desktops do to invalidate pretty
much every single assumption that your arguments are resting on. Pekka
was kind enough to point them out, but they don't seem to have sunk
in. If you reduce Wayland's capabilities to that of X11, then some of
your suggestions may be less wildly unsuitable, but on the other hand,
we might as well be using X11 if that were the case.

On 20 December 2016 at 04:17, Graeme Gill  wrote:
> Pekka Paalanen wrote:
>>> Wayland is useless unless there is a way to manage it. Which means
>>> that it should have channels for administrative tools to configure it.
>>
>> Indeed: Administrative tools. These are part of the compositor or the
>> desktop environment distribution. They have the privileges to configure
>> the compositor.
>
> And how are management functions that can't reasonably be contained
> in the compositor handled then ?
> A compositor is _not_ going to come with display color calibration
> and profiling functionality - it's too complex and specialized.
> The user will insist on being able to choosing such tools anyway.

Let's say that the target here is a user for whom absolute colour
correctness is so critical, that they have deeply specialised
applications and hardware, monitors most people have never heard of,
secondary measurement and calibration hardware, and have sunk a great
deal of time into specifically configuring this.

For such a user to pick a compositor which was actively bad at colour
management would be rank stupidity.

If you don't trust the compositor you're using to do the thing which
is above all else most important to you, maybe pick something else?

I also invite you to read up on 'the platform problem', which might as
well specifically be describing this thread:
https://lwn.net/Articles/443531/

>> We very deliberately avoid defining any "standard" Wayland interfaces
>> for configuring a compositor, because every compositor is different.
>> With X11, you had the one single X server implementation and no other.
>> On Wayland, every compositor is an individual, just like every X11
>> window manager is.
>
> What is the point of Wayland then ?

Why are you here then?

I appreciate parts of this thread have been frustrating, but the fact
you're participating in these discussions whilst slating Wayland as
poorly-designed crap that will never take off, suggests that a) you
don't actually understand it (objectively true, by this thread), or b)
deliberately saying these kinds of things to get a rise out of people.
Neither are a good look, so please grow up.

>> I do not want to waste time in designing a "standard configuration
>> interface" when the realistic expectation is that none of the major
>> DEs' compositor will be implementing it. They already have their own
>> tailor-made ways. As a case study one could look at the feature set of
>> xrandr tool.
>
> Please point out the "tailor-made ways" they all have of
> supporting color management then!
>
> And you are mistaken if you think that color management tool
> or application authors like myself are about to create N different
> versions of our applications for each of the different
> compositors different "tailor-made ways"! Life is simply
> too short.
>
> So the future is pretty clear - if Wayland doesn't accommodate
> color management, then no applications or users of color
> applications are ever going to use Wayland. No
> Scribus, Krita, GIMP, Inkscape or Darktable for Wayland.
> No Photographers, Videographers or Desktop publishers using
> Wayland.

This is risible hyperbole, and total rubbish.

You're painting a false dichotomy where either people use external
tools to allow colour-critical users to compensate for the damage
their known-bad compositors do, or there is no chance of ever having
colour management ever. If only there was a third option.

>> If you want a standard interface, you have to get the buy-in from the
>> major DE projects first. One can write a protocol spec and throw it
>> into wayland-protocols, but whether anyone will implement it is another
>> matter.
>
> Go right ahead and build the barriers to supporting Wayland higher then.

This thread perhaps demonstrates why many projects which would
otherwise care about colour management have such difficulty supporting
colour management correctly.

>> The first one I agree. The second one I strongly object unless it
>> originates from more than one DE project and is kept non-essential for
>> corre

Re: [RFC wayland-protocols] Color management protocol

[Daniel Stone]

Hi Chris,

On 20 December 2016 at 18:11, Chris Murphy  wrote:
> On Tue, Dec 20, 2016 at 10:02 AM, Daniel Stone  wrote:
>> On 17 December 2016 at 10:16, Graeme Gill  wrote:
>>> As I've explained a few times, and extension is needed to provide
>>> the Output region information for each surface, as well as each
>>> outputs color profile, as well as be able to set each Outputs
>>> per channel VideoLUT tables for calibration.
>>
>> That's one way of looking at it, yes. But no, the exact thing you're
>> describing will never occur for any reason. If you'd like to take a
>> step back and explain your reasoning, as well as the alternate
>> solutions you've discarded, then that's fine, but otherwise, with a
>> firm and resolute 'no, never' to this point, we're at a dead end.
>
> We can't have multiple white points on the display at the same time;
> it causes incomplete user adaptation and breaks color matching
> everywhere in the workflow. The traditional way to make sure there is
> only one white point for all programs is manipulating the video card
> LUTs. It's probably not the only way to do it. But if it's definitely
> not possible (for reasons I'm not really following) for a privileged
> display calibration program to inject LUT data, and restore it at boot
> up time as well as wake from sleep, then another way to make certain
> there's normalized color rendering on the display is necessary.

Right: 'ensure whitepoint consistency' is an entirely worthwhile goal,
and I think everyone agrees on the point. 'Give clients absolute
control over display hardware LUT + CTM' is one way of achieving that
goal, but not a first-order goal in itself.

The reason applications can't drive the LUT is because, as you say,
there's not always just one. If there were only one application, then
why not just write directly to KMS? There's little call for a window
system in that case.

> The holy grail is as Richard Hughes describes, late binding color
> transforms. In effect every pixel that will go to a display is going
> to be transformed. Every button, every bit of white text, for every
> application. There is no such thing as opt in color management, the
> dumbest program in the world will have its pixels intercepted and
> transformed to make sure it does not really produce 255,255,255
> (deviceRGB) white on the user display.

I agree that there's 'no such thing as an opt in', and equally that
there's no such thing as an opt out. Something is always going to do
something to your content, and if it's not aware of what it's doing,
that something is going to be destructive. For that reason, I'm deeply
skeptical that the option is routing around the core infrastructure.

As arguments to support his solution, Graeme presents a number of
cases such as complete perfect colour accuracy whilst dragging
surfaces between multiple displays, and others which are deeply
understandable coming from X11. The two systems are so vastly
different in their rendering and display pipelines that, whilst the
problems he raises are valid and worth solving, I think he is missing
an endless long tail of problems with his decreed solution caused by
the difference in processing pipelines.

Put briefly, I don't believe it's possible to design a system which
makes these guarantees, without the compositor being intimately aware
of the detail.

This doesn't mean that every input pixel must be sRGB and the
compositor / GPU / display hardware must transform every pixel, but
that the compositor needs to be, at a minimum, aware. Again, I think
everyone agrees that the perfect case for deeply colour-aware
applications, is that they present content in such a way that, in the
ideal steady state, it can be presented directly to the display with a
NULL transform.

> The consequences for a single dumb program, for even 2 seconds,
> showing up on screen with 255,255,255 white on an uncalibrated display
> is the user's white point adaptation is clobbered for at least 10
> minutes, possibly 30 or more minutes. And it doesn't just affect the
> other things they're viewing on the display, it will impact their
> ability to reliably evaluate printed materials in the same
> environment.
>
> So the traditional way of making absolutely certain no program can
> hose the workflow is this crude lever in the video card. If you can
> come up with an equivalently sure fire reliable s that doesn't demand
> that the user draw up a list of "don't ever run these programs" while
> doing color critical work, then great. Otherwise, there's going to
> need to be a way to access the crude calibration lever in the video
> card. Even though crude, this use case is exactly what it's designed
> for.

It isn't a panacea though. It is one way to attack things, but if your
foundational principle is that the display hardware LUT/CTM never be
out of sync with content presented to the display, then my view is
that the best way to solve this is by having the LUT/CTM be driven by
the thing which controls pr

Re: [RFC wayland-protocols] Color management protocol

[Chris Murphy]

On Tue, Dec 20, 2016 at 11:33 AM, Daniel Stone  wrote:
> Hi Chris,
>
> On 20 December 2016 at 18:11, Chris Murphy  wrote:
>> On Tue, Dec 20, 2016 at 10:02 AM, Daniel Stone  wrote:
>>> On 17 December 2016 at 10:16, Graeme Gill  wrote:
 As I've explained a few times, and extension is needed to provide
 the Output region information for each surface, as well as each
 outputs color profile, as well as be able to set each Outputs
 per channel VideoLUT tables for calibration.
>>>
>>> That's one way of looking at it, yes. But no, the exact thing you're
>>> describing will never occur for any reason. If you'd like to take a
>>> step back and explain your reasoning, as well as the alternate
>>> solutions you've discarded, then that's fine, but otherwise, with a
>>> firm and resolute 'no, never' to this point, we're at a dead end.
>>
>> We can't have multiple white points on the display at the same time;
>> it causes incomplete user adaptation and breaks color matching
>> everywhere in the workflow. The traditional way to make sure there is
>> only one white point for all programs is manipulating the video card
>> LUTs. It's probably not the only way to do it. But if it's definitely
>> not possible (for reasons I'm not really following) for a privileged
>> display calibration program to inject LUT data, and restore it at boot
>> up time as well as wake from sleep, then another way to make certain
>> there's normalized color rendering on the display is necessary.
>
> Right: 'ensure whitepoint consistency' is an entirely worthwhile goal,
> and I think everyone agrees on the point. 'Give clients absolute
> control over display hardware LUT + CTM' is one way of achieving that
> goal, but not a first-order goal in itself.
>
> The reason applications can't drive the LUT is because, as you say,
> there's not always just one. If there were only one application, then
> why not just write directly to KMS? There's little call for a window
> system in that case.

At least on Windows and macOS there is a significant dependence on
"the honor system" that applications don't go messing around with
video card LUTs unless they happen to be specifically a display
calibration program. It's not in the interest of these applications to
change the video card LUT. The way it works on macOS and Windows, only
a display calibration program will do this: measures the display with
a linear video card LUT, computes a correction curve to apply to the
LUT, then measures the display again with the LUT in place, creates an
ICC profile from that 2nd set of measurements, and registers the ICC
profile with the OS so programs can be made aware of it.

If a program were to change the LUT, the display profile becomes
invalid. So it's not in the interest of any program that doesn't
calibrate displays to modify video card LUTs. OK so maybe that means
such a program is either a display calibrator, or it's malicious. I
haven't heard of such a malicious program, but that's also like blind
faith in aviation's "big sky theory". But totally proscribing programs
that depend on changing video card LUTs just to avoid the next to
impossible malware vector seems a bit heavy weight, in particular
given that an alternative (full display compensation) doesn't yet
exist.



>
>> The holy grail is as Richard Hughes describes, late binding color
>> transforms. In effect every pixel that will go to a display is going
>> to be transformed. Every button, every bit of white text, for every
>> application. There is no such thing as opt in color management, the
>> dumbest program in the world will have its pixels intercepted and
>> transformed to make sure it does not really produce 255,255,255
>> (deviceRGB) white on the user display.
>
> I agree that there's 'no such thing as an opt in', and equally that
> there's no such thing as an opt out. Something is always going to do
> something to your content, and if it's not aware of what it's doing,
> that something is going to be destructive. For that reason, I'm deeply
> skeptical that the option is routing around the core infrastructure.

There's ample evidence if it's easy to opt out, developers will do so.
It needs to be easier for them to just get it for free or nearly so,
with a layered approach where they get more functionality by doing
more work in their program, or using libraries that help them do that
work for them.

For example a still very common form of partial data loss is the dumb
program that can open a JPEG but ignore EXIF color space metadata and
an embedded ICC profile. What'd be nice is if the application doesn't
have to know how to handle this: reading that data, and then tagging
the image object with that color space metadata. Instead the
application should use some API that already knows how to read files,
knows what a JPEG is, knows all about the various metadata types and
their ordering rules, and that library is what does the display
request and knows it needs to attach the color space meta

Re: [RFC wayland-protocols] Color management protocol

[Graeme Gill]

Pekka Paalanen wrote:
> On Tue, 20 Dec 2016 15:17:31 +1100
> Graeme Gill  wrote:

> When I was talking about configuration, your reply talks about content
> delivery. We are continuously talking past each other. I talk about one
> thing, you deliberately interpret me talking about the other thing, so
> that you can make me look silly. I'm tired of correcting that in every
> turn.

You weren't talking about configuration, you were talking
about control. They are not the same thing. An application determines
(i.e. is in control of) the content it wants presented to the user.
That is its role. If it isn't in control of that, it can't do the job
the user expects of it.

[ And yes, I too am finding it rather tiring to be explaining
  color management fundamentals over and over again. ]

> Clients control what they send to the compositor: that is content
> delivery.

Exactly. Part of that content is color. To control that particular content,
the color values depend on the display they are being presented
on, i.e. which Output. So at some level the application needs to
know what outputs it's content will be delivered to, in order
to provide the correct content.

> Configuration controls compositor's global settings, like CRTC CLUT
> values.

Yes. But certain aspects of a display are both operational
elements _and_ configuration.

To a color calibration application, the VideoLUT is an operational
display element, just like the pixels values are to other
kinds of graphical applications. It's not configuration. Once
it's done, it becomes configuration for other applications
using the display.

So I'll agree that you can classify such an aspect as either
content (in the sense that it is a graphic output element
an application needs to manipulate to function), or configuration.
I'm sure you will say this is more configuration that content - fine.

But from the the calibration application writers point of view,
to write such an application it's very highly desirable
(i.e. may make the difference between such an application
existing or not) that there be a standard API to operate this
graphics system element, that is common and supported by the
graphics display system that it is intended to "configure".
What's the path for that, if it's not a Wayland protocol extension.
Is there a standard Wayland configuration protocol that can be extended ?

(And no, color calibration and profiling is not a "do it at the
 factory and pre-install it" type of thing. It's something
 some users want to do regularly.)

> Why would you not let compositors use the CMS libraries people have
> developed?

Nothing stopping them inventing their own color calibration and
profiling system. But can they afford the development effort ?
(My own color software has been developed over about 20 years).
There may be source code available to them under licensing
conditions that allow them to include it in the compositor,
but do they want to maintain such a port, and is
it really a good idea to want to include a full blown
application of considerable size and complexity, within a
compositor ? (All that color measurement instrument support!)
Do users want to be locked into a single
choice of such a built in application ?
Is it really expected that the compositor has to
be updated every time there is a bug or new feature in
the color management code ?
Maybe they can include a very stripped down
version of color management applications
(as Richard has done in Gnome), but that isn't
going to satisfy color critical users, and
seems rather contrary to open source philosophy to
deny users any way of using something else instead.

Answer - this seems rather unlikely to be a viable path. It's
not reasonable - color management applications need
to be independent applications to be practical, and the
alternative is fairly simply by comparison :-
provide the API's needed as standard.

> This is where we disagree, and that prevents us from making any
> progress.

It's up to you. I've laid out some sketches based on
existing working systems of how color management could
be supported in Wayland, but there are lots of variations
of how to do it, as long as they acknowledge the
logical realities of how color management works, and the
practical realities of how the associated applications work.
Suggest some approaches that take it forward.

Graeme Gill.

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland-protocols] Color management protocol

[Graeme Gill]

Kai-Uwe wrote:

> Maybe the device link is kind of a extension for later implementation.

I'm not enthused by that - I'd rather have it there right from the
start if no other practical means of an application doing the
color conversion itself. To do otherwise means that it will never be
uniformly supported, and relegates Wayland to being second class for
color critical applications.

In terms of the compositor support needed, I don't see it as adding
any significant extra complexity - the processing needed is simpler
in many ways to the device profile case - no linking is needed.
There is just a little extra book keeping in storing one
device link per Output, and using it in preference to the
device profile if it is present.

One of my concerns about this approach is whether it limits the
precision of the conversion in ways that do not apply if
the application is able to do the conversion. HDR is arriving,
so this could be important if it turns out that current
ICC V2 and V4 is insufficient in some way. ICC Max is
too immature at the moment to write into a spec., although
it is moving along. (The presentations at ICC DevCon in
San Diego were interesting from that point of view.)

Graeme Gill.

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland-protocols] Color management protocol

[Graeme Gill]

Richard Hughes wrote:
> On 20 December 2016 at 07:22, Graeme Gill  wrote:
>> Or be prepared to re-visit Wayland's fundamental design decisions
>> if they turn out to be based on a false premise.
> 
> I don't think that's fair. I think Wayland is the opportunity to upset
> the status quo with color management and do correctly what what never
> possible with X11.

I think it is fair - a lot of push back is along the lines of
"that's impossible - Wayland doesn't work that way", which
if taken to a logical conclusion, (maybe) implies that Wayland is
incapable of sporting color management.

Assumption: "Applications are oblivious to the output their
pixels are rendered to"

Reality: An application needs to know the output it's pixels
land on if it is to present them in the correct output specific
colorspace.

Assumption: "The compositor is able to do all the transformations
necessary to render applications pixels to the output device"

Reality: It may not be practical for a compositor to have the
color conversion machinery capable of doing the transformations
in the manner and to the precision that an application requires.

Assumption: "Graphical system API's can be divided into
application operational API's, and Management API's.
Wayland need only cover the former".

Reality: Some graphical functions are both operational
for one type of application, and management for other types
of applications.

Assumption: "All management functions can be incorporated in
the compositor"

Reality: Some management functions require full blown applications,
and can't practically be incorporated in each compositor,
nor tailored to each compositor.

So if the realities challenge the assumptions, then
either clever means need to be invented to get things
to work within the assumptions, or the assumptions need
to be softened. Saying "it's impossible" doesn't progress
things, nor help bring Wayland up to having the capabilities
of other existing systems.

[ The above of course is, as best I grasp it from preceding
  conversations. ]

> Lets be honest for a moment. How many applications support color
> management on the Linux desktop? We're asking application authors to
> understand things like blending spaces, source and destination
> profiles, vcgt, overlapping windows on different crtc's and horrible
> concepts like that.

Agreed. Easier to access, and default color management framework
is desirable (and for that reason was included in my sketch). But
this shouldn't be at the expense of applications that need more
than that, nor at the expense of color management applications
needed to set things up so that all this can work in the first place.

> As a framework guy, _and_ an app developer I just want to tag one
> surface with a colorspace and then let the compositor figure out all
> the grotty details.

And you should be able to. But what about applications that need
far more than that ? (Ordinary CMM's of the type that are likely
to be practical in a compositor, lack a lot of capabilities
that some applications will need).

> Anything more and the application author will just
> decide it's not worth the bother. To calibrate we just ask for a
> surface that's not going to be tampered with, but we don't want to
> optimize for this super-uncommon case.

I disagree - leave it to be an afterthought, and it will be
done badly or left out completely, crippling the practicality
of color management for the system.

Graeme Gill.



___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland-protocols] Color management protocol

[Chris Murphy]

On Tue, Dec 20, 2016 at 3:54 PM, Graeme Gill  wrote:

> But from the the calibration application writers point of view,
> to write such an application it's very highly desirable
> (i.e. may make the difference between such an application
> existing or not) that there be a standard API to operate this
> graphics system element, that is common and supported by the
> graphics display system that it is intended to "configure".
> What's the path for that, if it's not a Wayland protocol extension.
> Is there a standard Wayland configuration protocol that can be extended ?


Doesn't colord already push vcgt tag contents to the video card?  On
macOS, this is done through the display manager, no program directly
modifies the video card LUT. I'm pretty sure it's the same on Windows
in the modern era - it used to be every display calibration program
came with a helper program that would launch at startup time and apply
the calibration curve to the video card LUT.


-- 
Chris Murphy
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland-protocols] Color management protocol

[Graeme Gill]

Pekka Paalanen wrote:

> When one integrates a CMS in a compositor, you no longer need to
> expose configuration (hardware configuration, like CLUT programming)
> via any protocol. The compositor talks directly with the CMS and if the
> compositor can set e.g. CLUTs, CMS can tell it what to set.

"cLUTS" are things in the ICC profile (Color, or multi-dimensional lookup 
tables.)
and are typically used (as part of a conversion) to represent a device response
or an overal color transformation.

VideoLUTs are in the graphics hardware (CRTC), and involve the setup
("calibration") of the display. ICC profile handle some aspects
of the display badly - namely white point setting, which has
been (deliberately) crippled in the ICC format, so setting the hardware
per channel Lookup tables is the way to work around that,
as well as having the benefits of ensuring that even non-color
aware applications all have a consistent white point and visual
transfer curve.
Without this, mixed visual white adaptation will destroy the usefulness
of the display.

An additional subtlety is that in typical hardware, the VideoLUT entry
depth is greater than the frame buffer depth, so setting the overall
visual transfer curve and neutral axis matching using
the VideoLUT has the advantage of extra precision (typically 2 or
more extra bits, quite noticeable on 8 BPP frame buffers). Because
the VideoLUTs are global to each display, all the applications get
the benefit of this, and it makes the profile more accurate by making
the display better behaved

There is a de facto standard in ICC profiles that display
profiles may include a tag that stores the display expected
VideoLUT values ('vcgt' tag), and since the contents of
the display profile are built on the assumption of that
set of calibration curves, systems typically install
that vcgt tag contents in the VideoLUTs when a profile
is set to be the one for that display.

But, to actually create the calibration curves, a color
calibration and profiling application needs to be able
to set the VideoLUT contents to specific values. Other
useful functions are to be able to read the VideoLUT
values, to be able to verify that the calibration is as
intended.

(A little more information is here:
 )

> I am assuming that the compositor can interface with a CMS by calling
> into a library offered by the CMS. If that interfacing was previously
> done over X11, then you have to write that library. It will be more
> efficient too, since you don't have to serialize and deserialize, and
> asynchronicity (problems) appear only when you want to.

In X11 the VideoLUT setting/reading is done via XF86VidModeQueryExtension (old)
or XRandR (current). Typically the system color management support
will track the currently installed display profile, and set the
VideoLUT hardware (Gnome colord), or users will invoke
an equivalent utility at system startup (dispwin, xcalib etc.).
Such utilities also typically set an X11 atom or Output property
so that applications can obtain the display profile.

Note also that there are more things that an application
may want out of the current display profile than simply
the ability to transform into that space - they may
want to determine the color gamut, they may wish
to tag a window capture with the colorspace it is in, etc.

> I'm slowly starting to suspect that CMS designers need a slight paradigm
> shift: the compositor is meant to integrate with the CMS, instead of
> the CMS given low-level access to the hardware bypassing the window
> manager. CMS is no longer something that can be bolted on externally,
> like it is in X11. Embrace the idea of integration, and I belive and
> hope that it will pay off as a much more reliable architecture and
> polished user interfaces. Some of what used to go over X11 would
> probably be much better as a library ABI, but in X11 times it was not
> possible because X11 implied separate processes.

There is scope for moving in that direction, but care needs
to be taken not to reduce functionality as a consequence.

The chicken and egg problem remains - how do color management
applications exercise the hardware to create calibration curves,
as well as help manage the display color configuration by
installing profiles, etc. ?
Without the ability to create the calibration and profile,
you don't have a color managed system.

Graeme Gill.

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland-protocols] Color management protocol

[Niels Ole Salscheider]

On Tuesday, 20 December 2016, 13:38:55 CET, Graeme Gill wrote:
> Niels Ole Salscheider wrote:
> > Yes, exactly. But these are things that do not use the "normal" wayland
> > protocols but are initiated by the compositor.
> 
> I'm not sure what you mean by that. Why should the compositor launch
> applications ? The user should launch applications they want to
> use in the normal fashion they launch applications!
> 
> > In practice this will mean that a compositor will use LCMS / ArgyllCMS /
> > ... and the corresponding tools to accomplish these goals. The compositor
> > might use them as libraries, or maybe have a private D-Bus interface for
> > them. But it will be the compositor that initiates any action.
> 
> Not going to happen. They are not libraries, they are full blown,
> complex applications. And they can't use D-Bus, because Wayland
> doesn't use D-Bus. Think of (a future) remote Wayland as a test case.
> How does a the remote user calibrate, profile and install the
> a profile at a remote display they are sitting at ?
> To work anywhere a Wayland application works, they
> need to be Wayland applications, using the Wayland protocol.
> (And the user will rightfully want to be able to choose
>  which color management tools they use, not be locked into
>  whatever the compositor provides - if it provides anything
>  at all that is, something I rather doubt.)
> 
> > Developers of compositors and CMS can (and probably should) standardize
> > such an interface
> 
> And that is exactly what I want to happen.
> 
> >  (for example a library API or a D-Bus interface).
> 
> Using different mechanisms for communication raises
> a host of issues about support and coordination of
> Wayland and color management actions.
> 
> > But this is out of scope for the wayland protocol.
> 
> Why is that so, given that compositor at the end of the Wayland
> protocol has the job of managing graphics hardware ?

Because wayland does not have protocols for configuration as others have 
pointed out. There isn't even a protocol to change the screen resolution.
You can try to discuss this fundamental design decision but I do not expect it 
to change.

> >>> - You DO NOT know which parts of a surface are shown on which screen.
> >> 
> >> So that needs to be fixed for color aware applications to be able to
> >> provide display colorspace values.
> > 
> > That will be rather difficult in general.
> 
> I simply don't understand why. Wayland already has some of that
> information available, in a less precise way :- it has
> enter and leave events when a surface starts overlapping
> or ceases to overlap a scanout region of an output.
> All that is needed is the region information to
> go along with those events.
> 
> > I understand that you cannot satisfy all requirements by having ONLY a
> > simple color conversion to output color space in the compositor.
> > 
> > But are there transformations from input to output color space that cannot
> > be expressed as a (complex) transformation from input to intermediate
> > space (by the application) and then another transformation from
> > intermediate to output color space? At least as long as the intermediate
> > color space does not clip any color values.
> > I really do not know the answer to that and I will trust you on this.
> 
> Yes. The ICC PCS mix-and-match model has some notable limitations -
> in fact it verges on conceptually broken, because it's not possible
> to do real gamut mapping because the source gamut is divorced from
> the destination gamut when the transformations are created.
> The PRMG approach is sort of a fudgy workaround, but can't solve
> the problem. See
>  for a discussion
> that touches on this.
> 
> So if an application is content to use pre-computed ICC A2B and B2A
> transforms, and put up with the limitations of mix-and-match
> intent selection and operation (perhaps it is satisfied by
> colorimetric with profile default clipping, or generalized
> gamut compression), then this is perfectly fine, and covers
> a lot of ground. But I don't think a color management
> solution should prevent an application doing better than
> this if it wishes to go to the trouble, nor do I think
> that Wayland should have limitations that preceding systems
> don't have. Doing better than this means constructing overall
> device to device transforms (source space to display space) where it
> can use real gamut mappings, and can compute
> higher precision transforms by inverting the A2B table
> of the output profile rather than using the lower precision
> pre-computed B2A table, etc.

Ok, I understand the problem: For high quality perceptual gamut mapping you 
need to know the input and the output gamut and the precomputed tables might 
assume a wrong corresponding profile.

I can only see three solutions to that problem:
1) The compositor does all gamut mapping with a high quality.
2) The application does all the gamut mapping an

Re: [RFC wayland-protocols] Color management protocol

[Graeme Gill]

Daniel Stone wrote:

Hi Daniel,

> That's one way of looking at it, yes. But no, the exact thing you're
> describing will never occur for any reason. If you'd like to take a
> step back and explain your reasoning, as well as the alternate
> solutions you've discarded, then that's fine, but otherwise, with a
> firm and resolute 'no, never' to this point, we're at a dead end.

I've gone through the technical reasons behind this quite a few
times so far in this discussion. I know color is a bit
esoteric to most people, and it's easy to not appreciate
some of the subtleties that none the less have an impact
in the real world. I'm really not sure how I can expand
on this much more, but I'm willing to continue trying
for a while, so can you point to where you want me
to start ?

Cheers,

Graeme Gill.

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland-protocols] Color management protocol

[Graeme Gill]

Hi Chris,
> So the traditional way of making absolutely certain no program can
> hose the workflow is this crude lever in the video card. If you can
> come up with an equivalently sure fire reliable s that doesn't demand
> that the user draw up a list of "don't ever run these programs" while
> doing color critical work, then great. Otherwise, there's going to
> need to be a way to access the crude calibration lever in the video
> card. Even though crude, this use case is exactly what it's designed
> for.

I really wouldn't call it just a "crude lever", given the other
benefits, such as it being a higher resolution way to ensure
"nice" display characteristics. Other possible mechanisms
further up the rendering pipeline are not in as good
a place for this in some ways, and it has zero performance
impact. Tools, standards and workflows are already geared to this
mechanism.

Cheers,
Graeme Gill.



___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland-protocols] Color management protocol

[Graeme Gill]

Daniel Stone wrote:

Hi,

> I'm going to be very blunt here, because the attitude, arrogance, lack
> of respect and civility, and general unwillingness to see a point
> demonstrated by multiple people in this thread is perhaps the worst
> I've ever seen on this list.

I'll agree with that. It's certainly disconcerting to
have serious subjects that are the result of a lot of experience
and thought rejected out of hand without much apparent effort
to understand what's behind them.

> I recommend you re-read Pekka's emails a couple of times until they
> sink in. It is clear that you are extremely experienced in colour
> management;

I think that applies in the other direction as well.

> more so than most in this discussion. It is equally clear
> that you do not understand Wayland as a system, its fundamental design
> principles, nor the things modern desktops do to invalidate pretty
> much every single assumption that your arguments are resting on.

That's almost certainly true, in spite of any effort that I've
made to get up to speed on the subject.

> If you reduce Wayland's capabilities to that of X11, then some of
> your suggestions may be less wildly unsuitable, but on the other hand,
> we might as well be using X11 if that were the case.

It's not my intent to do so, but to contrast the gap in
capabilities that currently exists, and would like
to see filled in a workman like manner.

> Let's say that the target here is a user for whom absolute colour
> correctness is so critical, that they have deeply specialised
> applications and hardware, monitors most people have never heard of,
> secondary measurement and calibration hardware, and have sunk a great
> deal of time into specifically configuring this.
> For such a user to pick a compositor which was actively bad at colour
> management would be rank stupidity.
> 
> If you don't trust the compositor you're using to do the thing which
> is above all else most important to you, maybe pick something else?

If there is no capability or standardization in this area for Wayland based
systems, I don't see how such a user has any other choice than to pick a
"compositor" called Microsoft Windows or Apple OS X. That would be a shame.

> I appreciate parts of this thread have been frustrating, but the fact
> you're participating in these discussions whilst slating Wayland as
> poorly-designed crap that will never take off,

At no stage have I said anything of the kind!

Computer graphics has been of core interest the whole
of my professional life, and believe me, I have an
appreciation of what's involved in creating a system
like Wayland.

But I'd like to see it step up a notch and be a color management
aware/capable system, so that it is a complete foundation for
the future.

> suggests that a) you
> don't actually understand it (objectively true, by this thread), or b)
> deliberately saying these kinds of things to get a rise out of people.

No, I'm trying to get them to see the bigger picture, and
get them thinking about approaches to solving the problems presented,
rather than focusing narrowly on Wayland.

>> So the future is pretty clear - if Wayland doesn't accommodate
>> color management, then no applications or users of color
>> applications are ever going to use Wayland. No
>> Scribus, Krita, GIMP, Inkscape or Darktable for Wayland.
>> No Photographers, Videographers or Desktop publishers using
>> Wayland.
> 
> This is risible hyperbole, and total rubbish.

I am trying to get some minds focused - yes.
(And maybe I'm failing badly in that effort,
 and letting my frustration show too much.)

But I am totally serious. If Wayland's color management
ends up technically second rate, then there is ample
reason to recommend that people working in areas
that benefit from good color management steer clear
of it. That's not a pleasing prospect when it might
be avoided.

> You're painting a false dichotomy where either people use external
> tools to allow colour-critical users to compensate for the damage
> their known-bad compositors do, or there is no chance of ever having
> colour management ever. If only there was a third option.

I'm not sure what you mean by a "known-bad compositors",
nor do I really understand how this paints a false dichotomy.

The external tools are a means of creating the data to
allow for managing and compensating for their particular displays.
A competent application to create this data is non-trivial.
If a graphical systems makes implementation of such software
difficult or awkward or laborious, then such software
may be slow to be developed for such systems. Without
these tools then either color management can't exist
on those systems, or it is compromised (i.e. using EDID
derived profiles, or stock profiles), or awkward workarounds
are needed (switch to an X11 server, boot Windows etc.)

> This thread perhaps demonstrates why many projects which would
> otherwise care about colour management have such difficulty supporting
> colour m

Re: [RFC wayland-protocols] Color management protocol

[Graeme Gill]

Niels Ole Salscheider wrote:

Hi,

>> Why is that so, given that compositor at the end of the Wayland
>> protocol has the job of managing graphics hardware ?
> 
> Because wayland does not have protocols for configuration as others have 
> pointed out. There isn't even a protocol to change the screen resolution.
> You can try to discuss this fundamental design decision but I do not expect 
> it 
> to change.

I understand, but I then wonder where Wayland and it's
associated systems sit. Is this an architectural problem,
or is it that the required surrounding eco-systems
are too immature or non-standard ?

> Ok, I understand the problem: For high quality perceptual gamut mapping you 
> need to know the input and the output gamut and the precomputed tables might 
> assume a wrong corresponding profile.

Right. Having that capability somewhere, guarantees that there are
no artificial limits on algorithm or precision, and future proofing it.

> I can only see three solutions to that problem:
> 1) The compositor does all gamut mapping with a high quality.
> 2) The application does all the gamut mapping and provides a surface for each 
> output.
> 3) Device link profiles.

> I think 1 would fit into the wayland design and would have the additional 
> benefit that all applications (not only professional ones) benefit from it.
> The disadvantage would be that it adds complexity to the compositor and the 
> latter is responsible for good results: If a compositor has a bad CMM there 
> is 
> not much the application can do about.

Implementing a standard ICC based CMM is pretty easy if you use lcms as
a base, and what it does is well understood and predictable.
Implementing something more than that is an open ended problem,
and I don't think any attempt should be made to codify it into a
standard system.

> Solution 2 comes with an overhead and brings some problems when there is no 
> surface for a specific output (e. g. because it was just plugged in).
> I'm not sure how easy it would be to make this work. Maybe someone else can 
> comment on this?

The reaction seems negative. I suspect it can be achieved, but
there seems little prospect of such support being accepted
at the moment.

> Maybe allowing the application to choose between 1 and 3 would be a good 
> idea...

Here's where my current thinking is in terms 3):

  * Allow each surface to have a (source) colorspace ICC profile
set for it. This invokes standard CMM link to create a transform.

  * Allow each surface to have one device link ICC profile for each
output set for it. This would be used in preference to the source
device profile if it is set.

  * An application could create and set a device link when
it notices a surface overlaps an output via the existing
event. The compositor would re-render a surface if
the applicable profile changes or is set.

Problems with this:

 *  Applications that wish to dictate the source to display
conversion have to work harder in creating the device links,
something they don't have to do on other systems.

  * It may not be reasonable to ask Wayland and the compositor
to handle arbitrary number of color channel rasters and
transforms. If not, then the application has to work pretty
hard - pick an intermediate RGB colorspace to
render the incoming images to, then create a profiles/device
link from that working space to the output space.

  * How future proof are ICC device links as a means of
conveying the desired transform ? What about HDR etc.
as a test case ?

This doesn't address any of the problems of supporting
calibration, profiling or color setup, nor how display
profiles are installed or read by applications.

Cheers,

Graeme Gill.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland-protocols] Color management protocol

[Pekka Paalanen]

On Wed, 21 Dec 2016 09:54:07 +1100
Graeme Gill  wrote:

> Pekka Paalanen wrote:
> 
> > Why would you not let compositors use the CMS libraries people have
> > developed?  
> 
> Nothing stopping them inventing their own color calibration and
> profiling system. But can they afford the development effort ?
> (My own color software has been developed over about 20 years).

I suggest that compositors use the CMS you have spent so much time and
effort perfecting, and you start with the assumption that they will not
or cannot do so. Why?

> There may be source code available to them under licensing
> conditions that allow them to include it in the compositor,
> but do they want to maintain such a port, and is
> it really a good idea to want to include a full blown
> application of considerable size and complexity, within a
> compositor ? (All that color measurement instrument support!)
> Do users want to be locked into a single
> choice of such a built in application ?
> Is it really expected that the compositor has to
> be updated every time there is a bug or new feature in
> the color management code ?
> Maybe they can include a very stripped down
> version of color management applications
> (as Richard has done in Gnome), but that isn't
> going to satisfy color critical users, and
> seems rather contrary to open source philosophy to
> deny users any way of using something else instead.

Are you implying that the CMS you worked on so hard is impossible to use
from a compositor?

No, I do not mean forking the CMS and shoving the code into a compositor
project.

I mean libraries, services, daemons... does your CMS really not have
any such interfaces?

Now that I think of the history, that's likely true due to X11 and
having a single display server implementation ever that even declined to
integrate with CMS.

> Answer - this seems rather unlikely to be a viable path. It's
> not reasonable - color management applications need
> to be independent applications to be practical, and the
> alternative is fairly simply by comparison :-
> provide the API's needed as standard.

Yes! The CMS needs to provide the API that all compositors could use.

Even in the X11 case, simply shoving something into the CLUT directly
did not work. You can have multiple apps messing with the CLUT (e.g.
redshift, right?) without knowing about each other, leaving the user
clueless of the state of the display. I believe modern display hardware
start with a CLUT-matrix-CLUT pipeline and continuously invents more
ways, so "just set the CLUT" is already an outdated approach, not to
mention that each hardware plane might have its own pipeline setup
(Wayland compositors will use hardware planes at opportunity at their
own discretion, and completely transparently to any clients). The CMS
could control the X11 compositor or window manager only if that
compositor or WM actually listened, which requires explicit support
coded in it.

The situation on Wayland not that different. You still need the
{ display server, window manager, compositor } process to work *with*
CMS to produce best results, and it even offers significant benefits
like choosing a more appropriate blending space or automatic and
GPU-accelerated color mapping, plus preventing fighting over control.
You don't have X11 for communicating between the compositor and CMS,
now you need a library interface. It's not something one wants Wayland
for, because Wayland is IPC, implying the two parts are in separate
processes.

If you design the compositor-facing interface as a library ABI in your
CMS, then you have the power to design it right and tell compositor
developers how to do the right thing by using it.

Here, now, you have the opportunity to design how to integrate CMS with
Wayland compositors, in a mutually cooperative way between the two
software suites. You could aim for much much higher than just "I need
to control the hardware to begin with".

This, added with the power of adding implementation-specific Wayland
extensions at runtime(*) from within the CMS, should let you implement
much much more than you ever could if you stuck with the X11
architecture "I need to control hardware directly from a CMS tool that
is a Wayland client and the compositor has to stay out of the way".


Thanks,
pq

(*) Doing this requires a library ABI that the compositor will call into.


pgpHGMuIXclIx.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland-protocols] Color management protocol

[Pekka Paalanen]

On Wed, 21 Dec 2016 11:08:06 +1100
Graeme Gill  wrote:

> Richard Hughes wrote:
> > Anything more and the application author will just
> > decide it's not worth the bother. To calibrate we just ask for a
> > surface that's not going to be tampered with, but we don't want to
> > optimize for this super-uncommon case.  
> 
> I disagree - leave it to be an afterthought, and it will be
> done badly or left out completely, crippling the practicality
> of color management for the system.

Designing that is trivial:

GLOBAL cms_calibrator
- request: create_calibration_surface(wl_surface, new cms_calibration_surface)
# Assigns wl_surface role.

INTERFACE cms_calibration_surface
# Surfaces with this role will only be shown on the set output,
# with direct color path bypassing all color-management, and
# and the hardware has been reset to neutral/identity settings.
# (or whatever requirements are appropriate, you can decide
# what to write here)
- request: set_output(wl_output)
# Which output this surface targets. The compositor replies
with a
# configure event.
- event: configure(width, height)
# delivers the width and height the application needs to use


How it operates from a client perspective:

1. create a wl_surface
2. bind to cms_calibrator
3. send create_calibration_surface
4. send set_output
5. wait for configure
6. draw the calibration surface in the correct size
7. use Presentation feedback interface to ensure the calibration
   surface is show with the latest content
8. do what you want to do with the colorimeter
9. go to 6 to update the image if necessary
10. destroy cms_calibration_surface and wl_surface; the display
automatically returns to normal


To be user friendly, one probably wants to add an event in case the
user denies the request to show the calibration window as it will have
temporary global effects.

Whether the global needs to be privileged or not, and how privileges
are implemented are an orthogonal matter.


Thanks,
pq


pgp2lSuoZ7cv1.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland-protocols] Color management protocol

[Richard Hughes]

On 21 December 2016 at 09:14, Pekka Paalanen  wrote:
> I suggest that compositors use the CMS you have spent so much time and
> effort perfecting, and you start with the assumption that they will not
> or cannot do so. Why?

I think lcms2 is fine to use; it's widely used in other projects,
tested, and already optionally used in weston.

> Are you implying that the CMS you worked on so hard is impossible to use
> from a compositor?

I think that's basically correct, argyllcms doesn't have any header
files or shared libraries. When using it to generate color profiles
for things like printers from gnome-color-manager I have to spawn the
binaries themselves (and only in a VT...) and then scrape the output.
https://git.gnome.org/browse/gnome-color-manager/tree/src/gcm-calibrate-argyll.c#n273

> Yes! The CMS needs to provide the API that all compositors could use.

I'm not a great fan of pluggable CMSs, it's a bit like designing a car
that has a requirement that the engine is swappable with another
whilst driving down the motorway. I'm a great fan at pointing people
to http://www.islinuxaboutchoice.com/ when they ask about things like
this.

> so "just set the CLUT" is already an outdated approach

This is another point: We're all talking about the
least-common-denominator approach of setting the RGB 8-bit ramps on
the logic it's the only way to set the white point without the
overhead of a shader lookup. Most modern hardware actually supports
some kind of *matrix* and LUT on the crtc output itself, although
there is no common abstract interface that's provided by libdrm, yet.

Richard.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland-protocols] Color management protocol

[Daniel Stone]

Hey Richard,

On 21 December 2016 at 10:30, Richard Hughes  wrote:
> On 21 December 2016 at 09:14, Pekka Paalanen  wrote:
>> so "just set the CLUT" is already an outdated approach
>
> This is another point: We're all talking about the
> least-common-denominator approach of setting the RGB 8-bit ramps on
> the logic it's the only way to set the white point without the
> overhead of a shader lookup. Most modern hardware actually supports
> some kind of *matrix* and LUT on the crtc output itself, although
> there is no common abstract interface that's provided by libdrm, yet.

Not quite correct; the split-gamma-plus-matrix approach is already
supported by KMS properties. It doesn't quite expose (or at least
enumerate; it might be there if you poke sharply enough) the full
spectrum of complexity that I just outlined in reply to Mattias, but
it'll get there I'm sure ...

Cheers,
Daniel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland-protocols] Color management protocol

[Pekka Paalanen]

On Wed, 21 Dec 2016 10:30:50 +
Richard Hughes  wrote:

> On 21 December 2016 at 09:14, Pekka Paalanen  wrote:
> > I suggest that compositors use the CMS you have spent so much time and
> > effort perfecting, and you start with the assumption that they will not
> > or cannot do so. Why?  
> 
> I think lcms2 is fine to use; it's widely used in other projects,
> tested, and already optionally used in weston.
> 
> > Are you implying that the CMS you worked on so hard is impossible to use
> > from a compositor?  
> 
> I think that's basically correct, argyllcms doesn't have any header
> files or shared libraries. When using it to generate color profiles
> for things like printers from gnome-color-manager I have to spawn the
> binaries themselves (and only in a VT...) and then scrape the output.
> https://git.gnome.org/browse/gnome-color-manager/tree/src/gcm-calibrate-argyll.c#n273

Oh, that's a huge surprise to me, being accustomed to open source.

> > Yes! The CMS needs to provide the API that all compositors could use.  
> 
> I'm not a great fan of pluggable CMSs, it's a bit like designing a car
> that has a requirement that the engine is swappable with another
> whilst driving down the motorway. I'm a great fan at pointing people
> to http://www.islinuxaboutchoice.com/ when they ask about things like
> this.

Sorry about the typo, I meant "an API", not "the API". We're not
Khronos, indeed.

Just like programs can choose their toolkits, compositors should be
able to choose their color management providers for calibration and
color processing. We would still have the public and generic Wayland
extension for providing color-managed content, so it would not affect
normal application compatibility.


Thanks,
pq


pgpheaG31WGYS.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland-protocols] Color management protocol

[Niels Ole Salscheider]

On Wednesday, 21 December 2016, 11:39:50 CET, Graeme Gill wrote:
> Pekka Paalanen wrote:
> > When one integrates a CMS in a compositor, you no longer need to
> > expose configuration (hardware configuration, like CLUT programming)
> > via any protocol. The compositor talks directly with the CMS and if the
> > compositor can set e.g. CLUTs, CMS can tell it what to set.
> 
> "cLUTS" are things in the ICC profile (Color, or multi-dimensional lookup
> tables.) and are typically used (as part of a conversion) to represent a
> device response or an overal color transformation.
> 
> VideoLUTs are in the graphics hardware (CRTC), and involve the setup
> ("calibration") of the display. ICC profile handle some aspects
> of the display badly - namely white point setting, which has
> been (deliberately) crippled in the ICC format, so setting the hardware
> per channel Lookup tables is the way to work around that,
> as well as having the benefits of ensuring that even non-color
> aware applications all have a consistent white point and visual
> transfer curve.
> Without this, mixed visual white adaptation will destroy the usefulness
> of the display.
> 
> An additional subtlety is that in typical hardware, the VideoLUT entry
> depth is greater than the frame buffer depth, so setting the overall
> visual transfer curve and neutral axis matching using
> the VideoLUT has the advantage of extra precision (typically 2 or
> more extra bits, quite noticeable on 8 BPP frame buffers). Because
> the VideoLUTs are global to each display, all the applications get
> the benefit of this, and it makes the profile more accurate by making
> the display better behaved
> 
> There is a de facto standard in ICC profiles that display
> profiles may include a tag that stores the display expected
> VideoLUT values ('vcgt' tag), and since the contents of
> the display profile are built on the assumption of that
> set of calibration curves, systems typically install
> that vcgt tag contents in the VideoLUTs when a profile
> is set to be the one for that display.
> 
> But, to actually create the calibration curves, a color
> calibration and profiling application needs to be able
> to set the VideoLUT contents to specific values. Other
> useful functions are to be able to read the VideoLUT
> values, to be able to verify that the calibration is as
> intended.
> 
> (A little more information is here:
>  )

If the resolution of the frame buffer was high enough we could just apply the 
VideoLUT in software when we also apply the display profile and leave the 
hardware LUT alone. You could then profile the screen by setting the device 
link profile of your surface to the identity mapping without any vcgt tag.

But I agree that we want to program the VideoLUT as long as we use 8 bit 
framebuffers. We normally do not want to allow applications to change the 
VideoLUT since that would have an influence on all applications and a broken 
application might mess with it in some unintended way.

Maybe the solution for profiling would then be to just use KMS for fullscreen 
display and bypass the compositor completely? The profiling application could 
do whatever it wants to the hardware and the compositor would then restore the 
proper state when it is started again...

> > I am assuming that the compositor can interface with a CMS by calling
> > into a library offered by the CMS. If that interfacing was previously
> > done over X11, then you have to write that library. It will be more
> > efficient too, since you don't have to serialize and deserialize, and
> > asynchronicity (problems) appear only when you want to.
> 
> In X11 the VideoLUT setting/reading is done via XF86VidModeQueryExtension
> (old) or XRandR (current). Typically the system color management support
> will track the currently installed display profile, and set the
> VideoLUT hardware (Gnome colord), or users will invoke
> an equivalent utility at system startup (dispwin, xcalib etc.).
> Such utilities also typically set an X11 atom or Output property
> so that applications can obtain the display profile.
> 
> Note also that there are more things that an application
> may want out of the current display profile than simply
> the ability to transform into that space - they may
> want to determine the color gamut, they may wish
> to tag a window capture with the colorspace it is in, etc.
> 
> > I'm slowly starting to suspect that CMS designers need a slight paradigm
> > shift: the compositor is meant to integrate with the CMS, instead of
> > the CMS given low-level access to the hardware bypassing the window
> > manager. CMS is no longer something that can be bolted on externally,
> > like it is in X11. Embrace the idea of integration, and I belive and
> > hope that it will pay off as a much more reliable architecture and
> > polished user interfaces. Some of what used to go over X11 would
> > probably be much better as a library ABI, but in X11 tim

Re: [RFC wayland-protocols] Color management protocol

[Pekka Paalanen]

On Wed, 21 Dec 2016 11:38:41 +0200
Pekka Paalanen  wrote:

> On Wed, 21 Dec 2016 11:08:06 +1100
> Graeme Gill  wrote:
> 
> > Richard Hughes wrote:  
> > > Anything more and the application author will just
> > > decide it's not worth the bother. To calibrate we just ask for a
> > > surface that's not going to be tampered with, but we don't want to
> > > optimize for this super-uncommon case.
> > 
> > I disagree - leave it to be an afterthought, and it will be
> > done badly or left out completely, crippling the practicality
> > of color management for the system.  
> 
> Designing that is trivial:
> 
> GLOBAL cms_calibrator
> - request: create_calibration_surface(wl_surface, new cms_calibration_surface)
>   # Assigns wl_surface role.
> 
> INTERFACE cms_calibration_surface
>   # Surfaces with this role will only be shown on the set output,
>   # with direct color path bypassing all color-management, and
>   # and the hardware has been reset to neutral/identity settings.
>   # (or whatever requirements are appropriate, you can decide
>   # what to write here)
> - request: set_output(wl_output)
>   # Which output this surface targets. The compositor replies
>   with a
>   # configure event.
> - event: configure(width, height)
>   # delivers the width and height the application needs to use
> 
> 
> How it operates from a client perspective:
> 
> 1. create a wl_surface
> 2. bind to cms_calibrator
> 3. send create_calibration_surface
> 4. send set_output
> 5. wait for configure
> 6. draw the calibration surface in the correct size
> 7. use Presentation feedback interface to ensure the calibration
>surface is show with the latest content
> 8. do what you want to do with the colorimeter
> 9. go to 6 to update the image if necessary
> 10. destroy cms_calibration_surface and wl_surface; the display
> automatically returns to normal
> 
> 
> To be user friendly, one probably wants to add an event in case the
> user denies the request to show the calibration window as it will have
> temporary global effects.
> 
> Whether the global needs to be privileged or not, and how privileges
> are implemented are an orthogonal matter.

Hi Niels,

I really should have CC'd you on this one.

I also forgot to mention that surfaces with the cms_calibration_surface
role, when actually presented, would also guarantee that nothing else
will be shown on that specific output, screen saving will not activate,
etc. anything that might hamper calibration will not happen.

You'd also want an event telling that the user has interrupted the
showing of the calibration window, so that the calibration app cannot
hog the output indefinitely even if it freezes. That might be the same
event telling the user denied it in the first place.

This is something you cannot achieve with just a pass-through color
profile.


Thanks,
pq


pgpG5LeJ_tt4L.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland-protocols] Color management protocol

[Daniel Stone]

Hi Chris,

On 20 December 2016 at 20:49, Chris Murphy  wrote:
> On Tue, Dec 20, 2016 at 11:33 AM, Daniel Stone  wrote:
>> On 20 December 2016 at 18:11, Chris Murphy  wrote:
>>> We can't have multiple white points on the display at the same time;
>>> it causes incomplete user adaptation and breaks color matching
>>> everywhere in the workflow. The traditional way to make sure there is
>>> only one white point for all programs is manipulating the video card
>>> LUTs. It's probably not the only way to do it. But if it's definitely
>>> not possible (for reasons I'm not really following) for a privileged
>>> display calibration program to inject LUT data, and restore it at boot
>>> up time as well as wake from sleep, then another way to make certain
>>> there's normalized color rendering on the display is necessary.
>>
>> Right: 'ensure whitepoint consistency' is an entirely worthwhile goal,
>> and I think everyone agrees on the point. 'Give clients absolute
>> control over display hardware LUT + CTM' is one way of achieving that
>> goal, but not a first-order goal in itself.
>>
>> The reason applications can't drive the LUT is because, as you say,
>> there's not always just one. If there were only one application, then
>> why not just write directly to KMS? There's little call for a window
>> system in that case.
>
> At least on Windows and macOS there is a significant dependence on
> "the honor system" that applications don't go messing around with
> video card LUTs unless they happen to be specifically a display
> calibration program. It's not in the interest of these applications to
> change the video card LUT. The way it works on macOS and Windows, only
> a display calibration program will do this: measures the display with
> a linear video card LUT, computes a correction curve to apply to the
> LUT, then measures the display again with the LUT in place, creates an
> ICC profile from that 2nd set of measurements, and registers the ICC
> profile with the OS so programs can be made aware of it.
>
> If a program were to change the LUT, the display profile becomes
> invalid. So it's not in the interest of any program that doesn't
> calibrate displays to modify video card LUTs. OK so maybe that means
> such a program is either a display calibrator, or it's malicious. I
> haven't heard of such a malicious program, but that's also like blind
> faith in aviation's "big sky theory". But totally proscribing programs
> that depend on changing video card LUTs just to avoid the next to
> impossible malware vector seems a bit heavy weight, in particular
> given that an alternative (full display compensation) doesn't yet
> exist.

Understood. I'd perhaps misread some earlier discussions in the
megathread (which I don't really wish to revisit) then; apologies.

For the purposes of this discussion, I'd like to park the topic of
calibration for now. It goes without saying that providing facilities
for non-calibration clients is useless without calibration existing,
but the two are surprisingly different from a window-system-mechanism
point of view; different enough that my current thinking tends towards
a total compositor bypass for calibration, and just having it drive
DRM/KMS directly. I'd like to attack and bottom out the
non-calibration usecase without muddying those waters, though ...

>>> The holy grail is as Richard Hughes describes, late binding color
>>> transforms. In effect every pixel that will go to a display is going
>>> to be transformed. Every button, every bit of white text, for every
>>> application. There is no such thing as opt in color management, the
>>> dumbest program in the world will have its pixels intercepted and
>>> transformed to make sure it does not really produce 255,255,255
>>> (deviceRGB) white on the user display.
>>
>> I agree that there's 'no such thing as an opt in', and equally that
>> there's no such thing as an opt out. Something is always going to do
>> something to your content, and if it's not aware of what it's doing,
>> that something is going to be destructive. For that reason, I'm deeply
>> skeptical that the option is routing around the core infrastructure.
>
> There's ample evidence if it's easy to opt out, developers will do so.
> It needs to be easier for them to just get it for free or nearly so,
> with a layered approach where they get more functionality by doing
> more work in their program, or using libraries that help them do that
> work for them.

I completely agree with you! Not only on the 'opt in' point quoted
just here, but on this. When I said 'opt out' in my reply, I was
talking about several proposals in the discussion that applications be
able to 'opt out of colour management' because they already had the
perfect pipeline created. That 'opt out' is not a thing that exists,
because if the system is designed such that the compositor can only
guess or infer colour properties, then it will get it wrong, and it
will be destructive. That's not a system I'm interes

Re: [RFC wayland-protocols] Color management protocol

[Daniel Stone]

Hi Niels,

On 21 December 2016 at 11:21, Niels Ole Salscheider
 wrote:
> Maybe the solution for profiling would then be to just use KMS for fullscreen
> display and bypass the compositor completely? The profiling application could
> do whatever it wants to the hardware and the compositor would then restore the
> proper state when it is started again...

My working view at the moment is that whatever is doing calibration
should be directly in charge of the full insane complexity of the
display hardware, and that even enumerating this, let alone offering
control over it, is not tractable. Which leaves us with two options:
the compositor runs calibration, or external calibration apps do not
run under a Wayland session and just drive DRM/KMS directly.

This didn't make any sense when all display drivers were Xorg
components, but hey, we do have a universal API in DRM/KMS that you
can write applications directly towards, so I don't see why we should
bend over backwards making these compromises for special-purpose
clients which by definition do not interoperate with a regular desktop
environment.

Cheers,
Daniel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland-protocols] Color management protocol

[Niels Ole Salscheider]

On Wednesday, 21 December 2016, 12:05:12 CET, Daniel Stone wrote:
> Hi Chris,
> 
> On 20 December 2016 at 20:49, Chris Murphy  wrote:
> > On Tue, Dec 20, 2016 at 11:33 AM, Daniel Stone  
wrote:
> >> On 20 December 2016 at 18:11, Chris Murphy  
wrote:
> >>> We can't have multiple white points on the display at the same time;
> >>> it causes incomplete user adaptation and breaks color matching
> >>> everywhere in the workflow. The traditional way to make sure there is
> >>> only one white point for all programs is manipulating the video card
> >>> LUTs. It's probably not the only way to do it. But if it's definitely
> >>> not possible (for reasons I'm not really following) for a privileged
> >>> display calibration program to inject LUT data, and restore it at boot
> >>> up time as well as wake from sleep, then another way to make certain
> >>> there's normalized color rendering on the display is necessary.
> >> 
> >> Right: 'ensure whitepoint consistency' is an entirely worthwhile goal,
> >> and I think everyone agrees on the point. 'Give clients absolute
> >> control over display hardware LUT + CTM' is one way of achieving that
> >> goal, but not a first-order goal in itself.
> >> 
> >> The reason applications can't drive the LUT is because, as you say,
> >> there's not always just one. If there were only one application, then
> >> why not just write directly to KMS? There's little call for a window
> >> system in that case.
> > 
> > At least on Windows and macOS there is a significant dependence on
> > "the honor system" that applications don't go messing around with
> > video card LUTs unless they happen to be specifically a display
> > calibration program. It's not in the interest of these applications to
> > change the video card LUT. The way it works on macOS and Windows, only
> > a display calibration program will do this: measures the display with
> > a linear video card LUT, computes a correction curve to apply to the
> > LUT, then measures the display again with the LUT in place, creates an
> > ICC profile from that 2nd set of measurements, and registers the ICC
> > profile with the OS so programs can be made aware of it.
> > 
> > If a program were to change the LUT, the display profile becomes
> > invalid. So it's not in the interest of any program that doesn't
> > calibrate displays to modify video card LUTs. OK so maybe that means
> > such a program is either a display calibrator, or it's malicious. I
> > haven't heard of such a malicious program, but that's also like blind
> > faith in aviation's "big sky theory". But totally proscribing programs
> > that depend on changing video card LUTs just to avoid the next to
> > impossible malware vector seems a bit heavy weight, in particular
> > given that an alternative (full display compensation) doesn't yet
> > exist.
> 
> Understood. I'd perhaps misread some earlier discussions in the
> megathread (which I don't really wish to revisit) then; apologies.
> 
> For the purposes of this discussion, I'd like to park the topic of
> calibration for now. It goes without saying that providing facilities
> for non-calibration clients is useless without calibration existing,
> but the two are surprisingly different from a window-system-mechanism
> point of view; different enough that my current thinking tends towards
> a total compositor bypass for calibration, and just having it drive
> DRM/KMS directly. I'd like to attack and bottom out the
> non-calibration usecase without muddying those waters, though ...
> 
> >>> The holy grail is as Richard Hughes describes, late binding color
> >>> transforms. In effect every pixel that will go to a display is going
> >>> to be transformed. Every button, every bit of white text, for every
> >>> application. There is no such thing as opt in color management, the
> >>> dumbest program in the world will have its pixels intercepted and
> >>> transformed to make sure it does not really produce 255,255,255
> >>> (deviceRGB) white on the user display.
> >> 
> >> I agree that there's 'no such thing as an opt in', and equally that
> >> there's no such thing as an opt out. Something is always going to do
> >> something to your content, and if it's not aware of what it's doing,
> >> that something is going to be destructive. For that reason, I'm deeply
> >> skeptical that the option is routing around the core infrastructure.
> > 
> > There's ample evidence if it's easy to opt out, developers will do so.
> > It needs to be easier for them to just get it for free or nearly so,
> > with a layered approach where they get more functionality by doing
> > more work in their program, or using libraries that help them do that
> > work for them.
> 
> I completely agree with you! Not only on the 'opt in' point quoted
> just here, but on this. When I said 'opt out' in my reply, I was
> talking about several proposals in the discussion that applications be
> able to 'opt out of colour management' because they already had the
> perfect pipelin

Re: [RFC wayland-protocols] Color management protocol

[Daniel Stone]

Hi Graeme,

On 21 December 2016 at 02:57, Graeme Gill  wrote:
> Daniel Stone wrote:
>> I recommend you re-read Pekka's emails a couple of times until they
>> sink in. It is clear that you are extremely experienced in colour
>> management;
>
> I think that applies in the other direction as well.

I would definitely benefit from seeing an expansion of some of the
terminology that is thrown around which can be subtly misleading. But
yes, as said, I've got some Christmas reading to do.

>> If you reduce Wayland's capabilities to that of X11, then some of
>> your suggestions may be less wildly unsuitable, but on the other hand,
>> we might as well be using X11 if that were the case.
>
> It's not my intent to do so, but to contrast the gap in
> capabilities that currently exists, and would like
> to see filled in a workman like manner.

Per my reply to Chris, some of those gaps can be filled in ways which
are not obvious when coming from other environments. Trying to solve
them in the exact same way would be bashing a square peg into a round
hole, so it can be useful to step back and have a think about
first-order requirements, rather than just jumping directly to deeply
specific solutions.

>> Let's say that the target here is a user for whom absolute colour
>> correctness is so critical, that they have deeply specialised
>> applications and hardware, monitors most people have never heard of,
>> secondary measurement and calibration hardware, and have sunk a great
>> deal of time into specifically configuring this.
>> For such a user to pick a compositor which was actively bad at colour
>> management would be rank stupidity.
>>
>> If you don't trust the compositor you're using to do the thing which
>> is above all else most important to you, maybe pick something else?
>
> If there is no capability or standardization in this area for Wayland based
> systems, I don't see how such a user has any other choice than to pick a
> "compositor" called Microsoft Windows or Apple OS X. That would be a shame.

Yes. No-one in this thread wants to see a solution which precludes
fully correct and accurate colour management.

>> You're painting a false dichotomy where either people use external
>> tools to allow colour-critical users to compensate for the damage
>> their known-bad compositors do, or there is no chance of ever having
>> colour management ever. If only there was a third option.
>
> I'm not sure what you mean by a "known-bad compositors",
> nor do I really understand how this paints a false dichotomy.

By 'known-bad compositor', I speak of a compositor which, when
processing information from clients, does so destructively. Such that
the final output from the compositor (to any connected display, or
screenshot/screencast, be it via means of direct scanout from a plane,
or intermediate GPU rendering, or an intermediate hardware composition
through a dedicated block, or software composition, or, or), produces
incorrect results.

A lot of the discussion on this thread seems aimed at ensuring
compositors are not involved in colour management and colour-critical
applications are forced to use external systems to route around them
in order to achieve the desired colour result. This is a
self-fulfilling prophecy.

> The external tools are a means of creating the data to
> allow for managing and compensating for their particular displays.
> A competent application to create this data is non-trivial.
> If a graphical systems makes implementation of such software
> difficult or awkward or laborious, then such software
> may be slow to be developed for such systems. Without
> these tools then either color management can't exist
> on those systems, or it is compromised (i.e. using EDID
> derived profiles, or stock profiles), or awkward workarounds
> are needed (switch to an X11 server, boot Windows etc.)

Completely understandable. Again though, I think it's important to
separate the discussion of how to create a calibrator, from how to
create a colour-aware application that can achieve its desired colour
results. The two may, at a very low level, share similar requirements
(along with that of managing the data and applying it to outputs etc),
but I expect them to look very different from a protocol point of
view. Some of it may, as said earlier, not involve Wayland at all.

>> This thread perhaps demonstrates why many projects which would
>> otherwise care about colour management have such difficulty supporting
>> colour management correctly.
>
> It's a difficult subject to get a grasp on at times. Many programmers
> get to the stage of knowing what RGB is, and thinking there is not
> much more.

Yes, but it's also how you work with people. Security had the same
issue for the longest time, where there were application/system
people, and then there were security people, and the only time they
met was to tell each other that they didn't live in the real world. I
desperately want to avoid colour management remaining a ghetto whe

Re: [RFC wayland-protocols] Color management protocol

[Daniel Stone]

Hi Niels,

On 21 December 2016 at 13:24, Niels Ole Salscheider
 wrote:
> On Wednesday, 21 December 2016, 12:05:12 CET, Daniel Stone wrote:
>> On 20 December 2016 at 20:49, Chris Murphy  wrote:
>> > For example a still very common form of partial data loss is the dumb
>> > program that can open a JPEG but ignore EXIF color space metadata and
>> > an embedded ICC profile. What'd be nice is if the application doesn't
>> > have to know how to handle this: reading that data, and then tagging
>> > the image object with that color space metadata. Instead the
>> > application should use some API that already knows how to read files,
>> > knows what a JPEG is, knows all about the various metadata types and
>> > their ordering rules, and that library is what does the display
>> > request and knows it needs to attach the color space metadata. It's
>> > really the application that needs routing around.
>>
>> I agree (the specific JPEG case is something that's been bugging me
>> for some time), and it's something I want to build in to make it as
>> easy as possible for people to gradually build their clients to get
>> this right.
>
> This is really something that should be done by the toolkits (Qt, GTK, ...).
> I really hope that they start to read the profile from EXIF when opening an
> image. They can then either attach it to the subsurface that is used to
> display the image, or convert it to their blending space (which could match
> the blending space of the compositor) if blending is performed.

Sure. Complicated of course by things like embedded web views, but ...

>> Similarly, I'd like to park the discussion about surfaces split across
>> multiple displays; it's a red herring. Again, in X11, your pixel
>> content exists in one single flat buffer which is shared between
>> displays. This is not a restriction we have in Wayland, and a lot of
>> the discussion here has rat-holed on the specifics of how to achieve
>> this based on assumptions from X11. It's entirely possible that the
>> best solution to this (a problem shared with heterogeneous-DPI
>> systems) is to provide multiple buffers. Or maybe, as you suggest
>> below, normalised to an intermediate colour system of perhaps wider
>> gamut. Either way, there's a lot of ways to attack it, but how we
>> solve that is almost incidental to core colour-management design.
>
> Has there been any discussion about using a buffer per output to solve the
> heterogeneous-DPI problem? If we end up doing that we might as well use it for
> color correction. But otherwise I would prefer the device link profile
> solution.

No, it's something I've just thrown out here because I thought this
thread was too relentlessly productive and on-topic. It's _a_ possible
solution which doesn't seem immediately useless though, so that's
something. I was mostly using it though, to illustrate that there may
be better long-term solutions than are immediately obvious.

>> > So then I wonder where the real performance penalty is these days?
>> > Video card LUT is a simplistic 2D transform. Maybe the "thing" that
>> > ultimately pushes pixels to each display, can push those pixels
>> > through a software 2D LUT instead of the hardware one, and do it on 10
>> > bits per channel rather than on full bit data.
>>
>> Some of the LUTs/matrices in display controllers (see a partial
>> enumeration in reply to Mattias) can already handle wide-gamut colour,
>> with caveats. Sometimes they will be perfectly appropriate to use, and
>> sometimes the lack of granularity will destroy much of their value. If
>> the compositor is using the GPU for composition, then doing colour
>> transformations is extremely cheap, because we're rarely bound on the
>> GPU's ALU capacity.
>
> Yes, but as Graeme has pointed out doing it in a shader means lower precision
> when using a 8 bit framebuffer. How feasible is it to use a higher resolution
> framebuffer and how big would the performance impact be?

Well yeah, if you're using an 8-bit framebuffer then that caps your
effective precision. But even ignoring the fact that intermediate
calculations within shaders happen at vastly higher precision (often
32bpc) than either your source or destination buffer, I don't know of
hardware which supports 10bpc sampler targets but not render targets.
Meaning that sudden demotion to 8bpc precision doesn't just happen;
you either succeed or fail in the first.

(By way of example, Mesa does not usefully expose 10bpc formats for
non-Intel drivers right now; the hardware and underlying drivers do;
it's just a small bit of missing glue code. On the other hand, there
is no silent jump between precision; it just wouldn't work.)

Cheers,
Daniel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland-protocols] Color management protocol

[Chris Murphy]

On Wed, Dec 21, 2016 at 5:05 AM, Daniel Stone  wrote:

>I'd like to attack and bottom out the
> non-calibration usecase without muddying those waters, though ...

What about games? I'm not aware of any color managed games. As far as
I know they all assume deviceRGB and are content with the user getting
something rather obviously less chromatic with less dynamic range on a
laptop, and rather more if they have a 4K TV, or a wide gamut display.
Do games typically draw through X or do they use DRM/KMS?

Video. This is such a rat hole of a mess right now. There are
different codecs with different color spaces, and some of the wrappers
imply different color handling on top of this, and then the user
agents all end up interpreting this mess differently so the same video
content can appear differently depending on user agent, and then
depending on platform. It's so bad. In ancient times Apple had
quicktime video pumped through ColorSync with very good performance.
I'm going to guess this involved simple matrix + TRC defined source
and destination color spaces for the transform. I know that Adobe
Flash, about 3-4 years ago, started to do on-the-fly display
compensation if the metadata in the source file enabled it. (I don't
remember if the tag says "I'm sRGB" and therefore Flash color managed
it, or if the tag says "color management me" and Flash assumes it's
sRGB and therefore color manages it.) And all of this would work in a
web browser's cut out area.

Web browsers. Right now all the web browsers are doing their own color
management, haphazardly. e.g. only images with embedded profiles are
color managed. Untagged images, html and css are deviceRGB, there is
no transformation, and thus no display compensation most of the time.
Browser developers have complained color managing every element in a
web page slows down rendering by a ton. Maybe they're doing it wrong.
:-D Also, browser plugins do their own thing, even if the browser has
full color management enabled, this doesn't affect plug-in content. I
don't know if there's any difference between NPAAPI vs PPAPI plug-ins
in this regard.

GIMP, Scribus, Krita, Digicam, Darktable - are all color managing
their content in advance (early binding) and supply device RGB, having
used the current display profile as the destination in a transform. So
they already do display compensation and don't need it to happen
again. So either they've got a bunch of work to do to rip that out if
Wayland is going to do it for them, or they need a passthrough. Web
browsers are a good example of programs that should probably rip out
what they have and have something else completely color manage all of
their content regardless of whether it's native elements or plug-in,
but I digress.

There has been a need for an explicit pass through to avoid any (or
additional) color management, and there are presently programs that
continue to expect that there will be.

On macOS this is achieved by tagging the content with the current
display profile, since source equals destination, the CMM sees this
and does a null transform, it's a noop. But there's no actual,
literal, off switch. If the content is not explicitly tagged, it's
assumed to be sRGB and hence color managed. So it's both opt in (if
you want something other than sRGB) and opt out (you want a pass
through).

On iOS there are no transforms, there is no need for display
compensation because all displays are either sRGB or (recently)
DCI-P3, and apparently they have the quality control to ensure this
level of consistency at a hardware level. Ironically, they've reverted
to closed loop hardware based calibration. Don't underestimate the
power of consistency and ancient ideas!

On Windows, ICC based color management is opt in, there is an API. If
a transform is not requested, it doesn't happen.

On Android, it's the same as Windows except no API, and display gamut,
dynamic range and tone response are all over the map. (And yet the
world isn't ending, even though if you view the same image on 10
Android phones or tablets you will have 10 different experiences).

I don't assume that on Linux any of these must be mimicked. But there
are distinct advantages with mimicking: we'll have a good idea where
the bodies are buried, rather than having something completely
different from any other platform.

-- 
Chris Murphy
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland-protocols] Color management protocol

[Kai-Uwe]

Hello Richard,

Am 21.12.2016 um 11:30 schrieb Richard Hughes:
> On 21 December 2016 at 09:14, Pekka Paalanen  wrote:
>> I suggest that compositors use the CMS you have spent so much time and
>> effort perfecting, and you start with the assumption that they will not
>> or cannot do so. Why?
> 
> I think lcms2 is fine to use; it's widely used in other projects,
> tested, and already optionally used in weston.

For the simple shoot and forget interface for client color space
tagging, which Niels is thankfully working on, a CMS like littleCMS
might be well established, maintained, reviewed, audited and supported.

However as it is used in Weston, it has clipping and other not so good
side effects, but it is certainly valuable on its own for base color
correction. A different CMS can go beyond that and add more color
management features to the benefit of the while desktop not only some
esoteric clients, which support device links or other more powerful
expressions from their own GUIs.

Kai-Uwe
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland-protocols] Color management protocol

[Kai-Uwe]

Hello Pekka,

Am 21.12.2016 um 11:59 schrieb Pekka Paalanen:
> On Wed, 21 Dec 2016 10:30:50 +
> Richard Hughes  wrote:
> 
>> On 21 December 2016 at 09:14, Pekka Paalanen  wrote:
>> I think that's basically correct, argyllcms doesn't have any header
>> files or shared libraries. When using it to generate color profiles
>> for things like printers from gnome-color-manager I have to spawn the
>> binaries themselves (and only in a VT...) and then scrape the output.
>> https://git.gnome.org/browse/gnome-color-manager/tree/src/gcm-calibrate-argyll.c#n273
> 
> Oh, that's a huge surprise to me, being accustomed to open source.

At least the Oyranos CMS API is certainly able to integrate ArgyllCMS as
a CMM, despite Argyll providing only CLI interfaces. Oyranos CMS
provides libraries, tools. And GUIs and (X11) compositors use those
Oyranos libs.

>>> Yes! The CMS needs to provide the API that all compositors could use.  

> Sorry about the typo, I meant "an API", not "the API". We're not
> Khronos, indeed.
> 
> Just like programs can choose their toolkits, compositors should be
> able to choose their color management providers for calibration and
> color processing. We would still have the public and generic Wayland
> extension for providing color-managed content, so it would not affect
> normal application compatibility.

As a CMS author, who is much involved with the KDE community and working
as well for other DEs, I appreciate this openness. I wish to integrate
Oyranos CMS with Wayland/Weston.

colord is considerd very Gnome centric.

Kai-Uwe
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland-protocols] Color management protocol

[Graeme Gill]

Pekka Paalanen wrote:
> On Wed, 21 Dec 2016 10:30:50 +
> Richard Hughes  wrote:

>> I think that's basically correct, argyllcms doesn't have any header
>> files or shared libraries. When using it to generate color profiles
>> for things like printers from gnome-color-manager I have to spawn the
>> binaries themselves (and only in a VT...) and then scrape the output.
>> https://git.gnome.org/browse/gnome-color-manager/tree/src/gcm-calibrate-argyll.c#n273
> 
> Oh, that's a huge surprise to me, being accustomed to open source.

What connection do you expect between open source and a set of
applications somehow _having_ to be structured as a library ??

(Yes, of course my Open Source ArgyllCMS Color Management toolset
 has a multitude of headers and libraries that it uses to implement
 its functionality. But being a set of applications, it isn't necessarily
 intended that other applications link to all that.)

> Just like programs can choose their toolkits, compositors should be
> able to choose their color management providers for calibration and
> color processing.

You missed profiling. CMM yes, but calibration and profiling and complex
linking, etc. etc. - no - they are user applications. Users
want to be able to pick and choose between such applications, not
be locked into a single implementation. This fosters
competition and innovation, just like any other application
area.

Graeme Gill.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland-protocols] Color management protocol

[Graeme Gill]

Pekka Paalanen wrote:

> Designing that is trivial:

I'm not so sure.

> GLOBAL cms_calibrator
> - request: create_calibration_surface(wl_surface, new cms_calibration_surface)
>   # Assigns wl_surface role.
> 
> INTERFACE cms_calibration_surface
>   # Surfaces with this role will only be shown on the set output,
>   # with direct color path bypassing all color-management, and
>   # and the hardware has been reset to neutral/identity settings.
>   # (or whatever requirements are appropriate, you can decide
>   # what to write here)

Why this has to be made a special case? The normal
machinery used to manage color is capable of
configuring things to be in a proper state for calibration
and profiling (if this was not the case, then it is not
truly able to do the color management!)

Due to the different bit depth of the VideoLUT entries and the
frame buffer, it is expected that it is possible to set
the VideoLUT value for the entry that corresponds
with the values set in the frame buffer (i.e. classically
10 bit VideoLUT entry depth in 8 bit frame buffer),
so that the test patch values can be of the same precision
as the resulting VideoLUT entries that get created from them.

> - request: set_output(wl_output)
>   # Which output this surface targets. The compositor replies
>   with a
>   # configure event.
> - event: configure(width, height)
>   # delivers the width and height the application needs to use

Right, but none of this addresses the main point of calibration -
to create a set of 1D LUTs to load into the hardware. How
is the hardware configured ?

> Whether the global needs to be privileged or not, and how privileges
> are implemented are an orthogonal matter.

It may be orthogonal, but still needs a concrete solution
to be implementable.

And let me raise a fundamental point about profiling here
(not to be confused with calibration). Profiling the display will not
work if the color values of the pixels to the display is different during
profiling, to what it is for normal application display.

Regards,
Graeme Gill.


___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland-protocols] Color management protocol

[Graeme Gill]

Pekka Paalanen wrote:

Hi,

> I suggest that compositors use the CMS you have spent so much time and
> effort perfecting, and you start with the assumption that they will not
> or cannot do so. Why?

We need to be clear on terminology here - "CMS" can have a few
meanings, depending on the intent of the user.

CMS in the sense of the tools I've written is a suite
of applications. Unless my understanding of what
a compositor is, is very wide of the mark, I really
don't think you want to incorporate something like
a quarter of a million lines of extra source code that
is organized into a flexible suite of inter-operating
tools that work together, into a compositor.

(CMS can also loosely refer to things like a CMM
 (Color Management Module). A CMM  typically has much better defined
 functionality and smaller scope, and can certainly be incorporated in a
 compositor - i.e. lcms).

As an application writer, I don't think incorporation
into a compositor is a reasonable proposition either - the very
purpose of an operating system is to be a good
environment to support applications, so to propose
re-implementing the applications within some sort
of quasi-non-standard operating environment
such as a compositor, has nothing attractive about it.
(Take that to the power N if there are N different compositors.)

To have the compositor call out to the tools rather
than incorporate them is perfectly possible
(Richard does some of this in colord I think), but doesn't
solve the problem of how the tools can do their job
if the graphics sub-system (i.e OS) doesn't support the facilities
they need to access the graphics hardware.

> Are you implying that the CMS you worked on so hard is impossible to use
> from a compositor?

As incorporated code - yes - I don't think it is practical.

> No, I do not mean forking the CMS and shoving the code into a compositor
> project.

> I mean libraries, services, daemons... does your CMS really not have
> any such interfaces?

No - it's an application, so it's organization is private - it doesn't
aim to provide services to anything except its own components. But even
if it was so organized, how does this solve the problem of those services
not being able to access the hardware ?
Why would the compositor or desktop environment want to re-implement
the applications UI's ?

>> Answer - this seems rather unlikely to be a viable path. It's
>> not reasonable - color management applications need
>> to be independent applications to be practical, and the
>> alternative is fairly simply by comparison :-
>> provide the API's needed as standard.
> 
> Yes! The CMS needs to provide the API that all compositors could use.

That's back to front. The CMS needs the API's that the Compositor provides,
since the Compositor is the operating system element that
is providing a standard and coherent API for applications
to access the display hardware.

> Even in the X11 case, simply shoving something into the CLUT directly
> did not work.

Terminology confusion - in ICC speak, cLUT is a multi-dimensional Color lookup
table (aka "3DLUT" in the 3D case, aka "mLUT"). The terms
I'm familiar with for the single dimensional lookup tables
in the (used to be) Video D/A are either "RAMDAC" (From the Brooktree HW) or
"VideoLUT", the latter I thought being the generally adopted term.

> You can have multiple apps messing with the CLUT (e.g.
> redshift, right?) without knowing about each other, leaving the user
> clueless of the state of the display.

There's a big difference between "did not work" and "could be
improved". In practice it all works well enough, because few applications
mess with the VideoLUTs, and the user can fix it if there is
a problem, by not installing or enabling applications that clash.
This is little different than the user dealing with other
clashes, such as which application is currently talking
to a serial port, which application is currently full screen, etc.

And "can be made to work" is infinitely better than
"impossible, because the application environment doesn't give access".

Could it be improved to better manage or resolve such clashes - yes!

But for a user who wants color management, there is no clash - they
don't run things like "redshift" or applications that alter the brightness
of the display, because that will mess up their display profile
and hence color accuracy.

> I believe modern display hardware
> start with a CLUT-matrix-CLUT pipeline and continuously invents more
> ways, so "just set the CLUT" is already an outdated approach, not to
> mention that each hardware plane might have its own pipeline setup

This is a complete distraction.

1) Saying "there's more complicated stuff that could be standardized
   in the future, so lets not implement things that people currently
   depend on now" is not serving the users at all, and could go on
   indefinitely.

2) CLUT-matrix-CLUT has no application to display calibration. It
   has possible uses I'm sure, for instance you could use

Re: [RFC wayland-protocols] Color management protocol

[Graeme Gill]

Pekka Paalanen wrote:

> I also forgot to mention that surfaces with the cms_calibration_surface
> role, when actually presented, would also guarantee that nothing else
> will be shown on that specific output, screen saving will not activate,
> etc. anything that might hamper calibration will not happen.

That's all good - but aren't these the sorts of controls
that other applications need too ?
Slide show or Video player apps need to prevent screensaving,
modal dialogs need to be able to pop to the top of
the window stack etc.

Graeme Gill.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland-protocols] Color management protocol

[Graeme Gill]

Niels Ole Salscheider wrote:

> If the resolution of the frame buffer was high enough we could just apply the 
> VideoLUT in software when we also apply the display profile and leave the 
> hardware LUT alone.

Yes, but that's not typically how the HW is arranged. Even
10 bit frame buffer configurations may possibly be followed
by 12 bit output entry 1D LUTS, specifically so that
lineariation curves can be applied at a high enough
resolution so as to be able to configure the 10 bit steps
to a satisfactory accuracy.

> You could then profile the screen by setting the device 
> link profile of your surface to the identity mapping without any vcgt tag.

That doesn't solve the problem for systems that do not have high resolution
frame buffers though. Such systems take a step back when running
Wayland if there is no means to create a set of higher resolution
calibration curves.

Summary - the 1D LUT HW is almost universally supported in
video cards, often offers higher resolution in the
non-linearized display space, comes for free in
terms of performance, ensures better behavior of
the display for all applications, color managed or not, and as
a color management processing step, is very widely supported by
color management systems and tools.

> But I agree that we want to program the VideoLUT as long as we use 8 bit 
> framebuffers. We normally do not want to allow applications to change the 
> VideoLUT since that would have an influence on all applications and a broken 
> application might mess with it in some unintended way.

Theoretically, but not practically. All current systems are open
to this "flaw", yet people do useful work on them without
being subject to such problems. It's like saying that
theoretically an application could send loud, annoying
sounds to the audio output. Yes they can, but users don't
put up with that kind of thing, so such applications get
un-installed pretty fast.

> Maybe the solution for profiling would then be to just use KMS for fullscreen 
> display and bypass the compositor completely? The profiling application could 
> do whatever it wants to the hardware and the compositor would then restore 
> the 
> proper state when it is started again...

Maybe - but this seems rather hacky, and I'm not clear
if things like (say) Qt will continue to provide the UI
if the application plays with DRM/KMS (aren't you implicitly
shutting down Wayland for that output ? - I'm not clear on the details).

Doesn't this also imply that the calibration and profiling
applications then have to do a lot of fairly low level
configuration to set the display in the same state
that Wayland is configured to have it in ?
(i.e. how much does DRM operate in parallel
to Wayland ? Can I get/set CRTC VideoLUTs via DRM while
Wayland is running on an output ?)

Is it certain that every Wayland supporting system has DRM/KMS available ?

Having created an application calibration curve, how does
the application install it for loading into the correct CRTC when
Wayland is running ? (Packing it in some ICC profile may solve
normal usage situations, if there is a profile, but cuts off
other current uses such as checking that the VideoLUT
is set as expected, capturing it during profiling, etc.)

Cheers,
Graeme Gill.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland-protocols] Color management protocol

[Graeme Gill]

Daniel Stone wrote:

Hi Daniel,

> For the purposes of this discussion, I'd like to park the topic of
> calibration for now. It goes without saying that providing facilities
> for non-calibration clients is useless without calibration existing,

I'm puzzled by what you mean by "non-calibration clients" ?

- taken literally that translates to applications that don't
  perform calibration, which is almost all of them, which I guess
  is not what you mean.

> but the two are surprisingly different from a window-system-mechanism
> point of view; different enough that my current thinking tends towards
> a total compositor bypass for calibration, and just having it drive
> DRM/KMS directly. I'd like to attack and bottom out the
> non-calibration usecase without muddying those waters, though ...

There are dangers in bypasses that go outside the normal
rendering pipeline - if not very carefully understood, they
can lead to the situation where the test values are not
being processed in the same way that normal rendering is
processed, leading to invalid test patch results.

And in any case, this approach always strikes me as really hacky -
if there is a well thought out color management pipeline, then
the same mechanisms used to configure the steps in the pipeline
are the very ones that should work to configure it into a state suitable
for measurement. This is natural and elegant, and  much safer.

("Safer" in color management terms typically translates to
 "less likely to lead to difficult to diagnose failures to
  get the expected color, due to processing steps that are
  modifying color in hard to scrutinize ways".)

Chris Murphy wrote:
 The holy grail is as Richard Hughes describes, late binding color
 transforms. In effect every pixel that will go to a display is going
 to be transformed. Every button, every bit of white text, for every
 application. There is no such thing as opt in color management, the
 dumbest program in the world will have its pixels intercepted and
 transformed to make sure it does not really produce 255,255,255
 (deviceRGB) white on the user display.

I wouldn't call this a "holy grail", nor am I sure this really
falls into what is normally regarded as a "late binding" color
workflow.

In color workflows, "late binding" typically refers to delaying
the rendering of original (assumed photographic) source material
into an intermediate device dependent colorspace until it actually
gets to the point where this is necessary (i.e. printing
or display). But this is not automatically better or easier,
it actually comes down to where the rendering intent information
(creative judgment) resides, as well as where the gamut definitions reside.
[At this point I'll omit a whole discussion about the nuances and pro's
 and con's of early & late binding.]

What Chris is talking about above, is simply providing a mechanism
in a display server to by-default manage non-color managed "RGB"
output from applications. That's very desirable in a world
full of non-color aware applications (including most desktop
software itself) and native wide gamut displays.

> I completely agree with you! Not only on the 'opt in' point quoted
> just here, but on this. When I said 'opt out' in my reply, I was
> talking about several proposals in the discussion that applications be
> able to 'opt out of colour management' because they already had the
> perfect pipeline created.

Right. A completely different case to dealing with
non-color aware/managed applications.

Daniel Stone wrote:
>>> As arguments to support his solution, Graeme presents a number of
>>> cases such as complete perfect colour accuracy whilst dragging
>>> surfaces between multiple displays, and others which are deeply
>>> understandable coming from X11. The two systems are so vastly
>>> different in their rendering and display pipelines that, whilst the
>>> problems he raises are valid and worth solving, I think he is missing
>>> an endless long tail of problems with his decreed solution caused by
>>> the difference in processing pipelines.

Sorry, I'm not at all as convinced that I don't understand
many of the differences between X11 and Wayland.

>>> Put briefly, I don't believe it's possible to design a system which
>>> makes these guarantees, without the compositor being intimately aware
>>> of the detail.

Using device links is a direction to make this possible I think,
since this allows decoupling the setting up of the color transform,
from when (and who) executes the corresponding pixel transformation.
So the application can then (if it chooses to manage its own color)
setup the color transformations for each output, while the compositor
can execute the pixel transformation on whichever of the surface
pixels it chooses to whichever of the outputs it needs to render to.
Note the implications about what range of source colorspace widths
the compositor then needs to handle though!

Chris Murphy wrote:
>> I'm not fussy about th

Re: [RFC wayland-protocols] Color management protocol

[Graeme Gill]

Daniel Stone wrote:

Hi Daniel,

Niels Ole Salscheider wrote:
> My working view at the moment is that whatever is doing calibration
> should be directly in charge of the full insane complexity of the
> display hardware, and that even enumerating this, let alone offering
> control over it, is not tractable. Which leaves us with two options:
> the compositor runs calibration, or external calibration apps do not
> run under a Wayland session and just drive DRM/KMS directly.

Really unattractive (i.e. a big obstacle) from a color management
calibration/profiling application writers point of view.

I certainly don't want to have to figure out any insane complexity
of display hardware - that's not my applications job - I just want the
access to the abstracted common color pipeline functionality that has always
been available in every desktop operating system, so that these
applications, and all the color sensitive applications can work.

> This didn't make any sense when all display drivers were Xorg
> components, but hey, we do have a universal API in DRM/KMS that you
> can write applications directly towards, so I don't see why we should
> bend over backwards making these compromises for special-purpose
> clients which by definition do not interoperate with a regular desktop
> environment.

Sorry, but from my perspective this is completely insane.

I think that adding a couple of well understood API's doesn't
compare to modifying a desktop application to have to, on the fly
switch from a normal application context into configuring
and then driving a (basically) raw frame buffer, convey all
it's user interface to the frame buffer to run test patches,
and then switch back again. And I don't know what you mean by
"do not interoperate with a regular desktop environment". These
are perfectly regular desktop applications that happen to have
a special purpose. Casting them adrift from the normal desktop
environment raises their difficulty into the "requires heroic effort"
territory, due to huge breakage of cross platform application
compatibility alone, and is directly contrary to the very
idea of what a display server and the overlaying application UI
toolkits are meant to provide!

I'm also thinking it would really help a lot if you and
others contributing to this thread were able
to procure something like a X-Rite i1 display Pro,
run up the manufacturer provided software on
MSWindows or OS X to get a feel for what it does,
then fire up DisplayCAL+ArgyllCMS on Linux/X11
and take it for a spin.
(Another path would be to obtain one of Richard's
 ColorHug's, but I think seeing how the commercial
 software operates as well, would add a broader perspective.)

I can keep writing a lot of words, but they don't seem to
be conveying much meaning without some common context.

Cheers,

Graeme Gill.


___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland-protocols] Color management protocol

[Graeme Gill]

Daniel Stone wrote:

Hi Daniel,

> I would definitely benefit from seeing an expansion of some of the
> terminology that is thrown around which can be subtly misleading. But
> yes, as said, I've got some Christmas reading to do.

If anybody would like some concise explanations for color management
terms and concepts, I'm willing to so explain, as well as
provide references for more expansion or detail.
Being lucid enough to succeed in conveying comprehension
is another thing of course.

> Per my reply to Chris, some of those gaps can be filled in ways which
> are not obvious when coming from other environments. Trying to solve
> them in the exact same way would be bashing a square peg into a round
> hole, so it can be useful to step back and have a think about
> first-order requirements, rather than just jumping directly to deeply
> specific solutions.

Agreed - and this is something I'm trying to do as well, to outline
the big picture as the background that leads to specific suggestions.

>> I'm not sure what you mean by a "known-bad compositors",
>> nor do I really understand how this paints a false dichotomy.
> 
> By 'known-bad compositor', I speak of a compositor which, when
> processing information from clients, does so destructively. Such that
> the final output from the compositor (to any connected display, or
> screenshot/screencast, be it via means of direct scanout from a plane,
> or intermediate GPU rendering, or an intermediate hardware composition
> through a dedicated block, or software composition, or, or), produces
> incorrect results.

Incorrect in the sense of spatial rendering, or color values/fidelity or both ?

> A lot of the discussion on this thread seems aimed at ensuring
> compositors are not involved in colour management and colour-critical
> applications are forced to use external systems to route around them
> in order to achieve the desired colour result. This is a
> self-fulfilling prophecy.

That's not what I'm suggesting. Compositors have a vital
role in allowing different applications to share a desktop,
as well as help applications and toolkits compose and
operate a GUI. But that is all about buffer management,
spatial rendering and coordination of updates. Transparency
and color encoding formats starts to dip into some color
related aspects, but only in a simple way that isn't related
to the colorimetry. A color managed workflow is about how
color is best preserved between different device dependent
color spaces, and in the context of a display system driven
by applications, this is primarily about the color spaces the
application takes in, or defines its own colors in, and the
display colorspace. (And lets be clear, when I say "colorspace"
here I'm speaking of the colorimetry, tonal response and color
mixing characteristics represented by the (often) RGB values,
although applications in general will deal with many other
types of input colorspaces such as CMYK, device independent
colorspaces, multi-channel spaces, etc. etc.)

> Yes, but it's also how you work with people. Security had the same
> issue for the longest time, where there were application/system
> people, and then there were security people, and the only time they
> met was to tell each other that they didn't live in the real world. I
> desperately want to avoid colour management remaining a ghetto where
> the only way to get correct results is via complex external systems
> which attempt to route around the underlying display pipeline. I want
> it to be a first-class part of our system. But this thread is not a
> good start.

Agreed it's not a good start, and I guess the gulf in
understanding is far wider than I have imagined from my
normal technical interactions with people.

> Simply providing video LUT data and nothing else is not a complete
> solution, because it means GPU-based composition pipelines (they do
> exist for non-alpha-blended cases too) are unaware of colourspace, and
> are thus liable to be destructive to the end result, especially if
> they attempt to do things such as taking clients with no explicit
> source information to be in sRGB colourspace.

I'm not sure what you are alluding to. A compositor pipeline
that alters color values in arbitrary ways will of course
make a color managed workflow difficult to impossible,
but what sort of compositor processing do you anticipate will
do this kind of thing ?

> That you keep saying 'program the video LUT' makes me think you
> perhaps do not realise the full complexity of colour management in
> modern display hardware (again, see other thread). This includes that
> LUTs can sometimes be applied on a per-plane basis as well as
> per-output.

Right - so this is perhaps something that might be made more
flexible. Currently it's kind of random whether things like video
overlay planes get VideoLUT curves applied to them or not, depending
on the hardware capability and/or diligence or understanding of the
driver writers.

> The last part is important,