Re: Wayland color management protocol proposal
(taking Richard out of CC as he replied on list) Am 19.06.2013 04:52, schrieb John Kåre Alsaker: Here is my current color management protocol for Wayland clients. The basic idea is that the compositor sends two color spaces to the clients. A compositing color space which the compositor prefers since it would require no conversions. A full-screen color space which the compositor can be able to scan out from. The full-screen color space is intended to used by games which are able to do color conversions as part of their post-processing. It's also possible it could be used by video players. Just rewording to get all in sync about the terms. The compositor colour space appears like a kind of document colour space, which the desktop/display is in. In the existing colour managed compositors that defaults to sRGB, but can of course be a different space like you suggest here. The full-screen color space reads like the main outputs device space. Is that notation correct? For various clients it would be essential to see each outputs native space as well. Multi monitor aware colour correction in some essential for artists applications as well as analysing software come to mind. Different rendering intents and more advanced color spaces have not explicitly been considered here, but I hope the use of ICC profiles will cover these. From a architecture point of view, that is not so easy. There are few CMS'es around to modify the rendering bits in a ICC profile. Secondly as the profiles are passed by file name, that would require copying before giving to Wayland, which sounds unfortunate and might cause confusion later on. Calibration tools will require explicit privileges in order to do their job. Using the full-screen color space won't be enough since video card gamma correction can apply to it. I also wonder if we can just remove the VCGT tag from the ICC profiles to indicate that the client doesn't have to correct for that, but I'm not sure that anyone would use the tag anyway. Sending a faked no VCGT profile is slightly indirect, but might work out. That needs to be documented very well. A calibration/profiling program needs then to set the VCGT-less profile to the output in question and then displays its measurement patches on a surface without colour conversion. To deprecate the VCGT tag is not so easy, as we have lots of legacy profiles around from windows / osx software and directly from vendors. Ignoring the VCGT tag is no option, modifying the profile by baking the VCGT tag into the ICC standard colorimetric descriptions might be a workaround inside a CMS. kind regards Kai-Uwe ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Wayland color management protocol proposal
On 19 June 2013 03:52, John Kåre Alsaker john.kare.alsa...@gmail.com wrote: Here is my current color management protocol for Wayland clients. The basic idea is that the compositor sends two color spaces to the clients. If we back up a little first, what's the problem we're trying to solve? * We already have the ICC profile filename from the CMS plugin for the output that sets the calibration sate * We want to convert the pixels on a surface from assumed-sRGB to the chosen display profile * We want there to be no conversion if the display profile is not set or if the display profile is set to sRGB * We want to be able to poke out regions of a surface for specific users, e.g. if a video player or image editor is already doing CM itself, or if a calibration tool is running that needs to output colors unmolested * We perhaps want to mark out regions of a surface that have a predictable or well known color space, to offload conversion from my Nikon D60 camera profile to the output space on the GPU, rather than the CPU. * Ideally we want to composite the surfaces together using linear light where possible I think addressing these in small chunks will let us define the protocol to be as simple as possible. I'm also keen on keeping the workflow ICC-only, trying to do anything else will lead to madness. Also, as a small point, we can't just ignore the VCGT tag as it forms part of the calibration state, and the characterisation is only valid for that state. I agree it makes sense to produce profiles without a VCGT when we have full screen color correction on most hardware, but until then we have to honor them. I think what it makes most sense for Raphael to start on is to take the ICC profile filename as specified in the CMS plugin, and do the assumed-sRGB - output transform in a GPU shader. That's quite a task in itself, and trying to think about everything all at once and talking protocol changes is bewildering for my little head, let alone someone new to the project :) Richard ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Wayland color management protocol proposal
Here is my current color management protocol for Wayland clients. The basic idea is that the compositor sends two color spaces to the clients. A compositing color space which the compositor prefers since it would require no conversions. A full-screen color space which the compositor can be able to scan out from. The full-screen color space is intended to used by games which are able to do color conversions as part of their post-processing. It's also possible it could be used by video players. Different rendering intents and more advanced color spaces have not explicitly been considered here, but I hope the use of ICC profiles will cover these. Calibration tools will require explicit privileges in order to do their job. Using the full-screen color space won't be enough since video card gamma correction can apply to it. I also wonder if we can just remove the VCGT tag from the ICC profiles to indicate that the client doesn't have to correct for that, but I'm not sure that anyone would use the tag anyway. protocol name=cms interface name=wl_cms_factory version=1 request name=destroy type=destructor/ enum name=error entry name=bad_surface value=0 summary=the given wl_surface is invalid/ entry name=bad_output value=1 summary=the given wl_output is invalid/ /enum request name=get_cms_surface arg name=id type=new_id interface=wl_cms_surface summary=the new cms-surface object id/ arg name=surface type=object interface=wl_surface summary=the surface to be turned into a cms-surface/ /request request name=get_cms_output arg name=id type=new_id interface=wl_cms_output summary=the new cms-output object id/ arg name=surface type=object interface=wl_output summary=the output to be turned into a cms-output/ /request request name=create_rgb_color_space description summary=create a RGB color space Creates a new color space from a RGB model. If the compositor is unable to use the RGB model, an undefined color space will be created instead. /description arg name=id type=new_id interface=wl_color_space summary=the new color space object id/ arg name=gamma type=int/ arg name=gamut type=int/ arg name=parameters type=array/ /request request name=create_profile_color_space description summary=create color space from profile Creates a new color space from a profile. If the compositor is unable to use the profile, an undefined color space will be created instead. /description arg name=id type=new_id interface=wl_color_space summary=the new color space object id/ arg name=mime_type type=string/ arg name=fd type=fd/ /request /interface interface name=wl_cms_output version=1 request name=destroy type=destructor/ event name=compositing_color_space description summary=update the output's compositing color space This event is send when wl_cms_output is created and when the compositor's compositing color space for the output changes. This is the color space the compositor uses internally when compositing surfaces on this output. Clients should try to render content in this space as it's the most efficient when surfaces are not fullscreen and compositing is required. However surfaces using this color space may not be able to be scanned out. If the client doesn't intend to use the passed color space, it must destroy it when receiving this event. /description arg name=color_space type=new_id interface=wl_color_space/ /event event name=fullscreen_color_space description summary=update the output's fullscreen color space This event is send when wl_cms_output is created and when the compositor's fullscreen color space for the output changes. This is the native color space of the output where the compositor don't have to use any conversions to display it. The compositor may not be able to do compositing in this color space without expensive conversions. If the client doesn't intend to use the passed color space, it must destroy it when receiving this event. /description arg name=color_space type=new_id interface=wl_color_space/ /event /interface interface name=wl_cms_surface version=1 request name=destroy type=destructor/ request name=set_color_space description summary=set the color space of a surface This request sets the color space of a wl_surface. If color_space is NULL or undefined, the default color space will be used instead. It's state is buffered so triggering wl_surface.commit is required for it to take effect. /description arg name=color_space type=object interface=wl_color_space allow-null=true/ /request /interface interface
