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
