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