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 

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

[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