Re: [RFC wayland-protocols] Add the color-management protocol
Daniel Stone wrote: Hi, > I mean lowest common denominator _between clients_, whilst still being > tied to the output. So the gamut would ideally be as wide as (the > specific output + highest gamut buffer being painted during this > stage), but in taking multiple clients with potentially disparate > colour source attributes and producing a single flat buffer, you may > need to unpick some properties of the client's colour attributes. My apologies Daniel, I know I'm not following you, but I'll blunder through a reply anyway, in the hope of stumbling on some common ground: I don't think there are any serious issues with rendering for a single output from multiple source colorspaces within an application, since the output has a single gamut that can be known. But given that a surface can span more than one output, there is no single color space that can simultaneously encompass all outputs (disparate) gamuts, and yet clip in an application/user preferred manner. I'm sure that the only way this is doable is for the application to be able to specify in some non-intent-limited way a transformation between each source colorspace and each particular output space. (I say this after many years pondering the ICC's attempt to decouple source and destination gamuts via the PCS (Profile Connection Space), even though this is logically impossible.) > This is quite a big difference from X11, in that there is no longer a > giant single buffer for all displays. One of the benefits of the > aggressive decoupling we've done ... I'm not sure of the relevance. Nothing about application color management cares about those sort of details. The primary task is almost always transforming between two specific device dependent colorspaces. Where the pixels reside or what the buffers are shared with, or how the pixels get spatially transformed is mostly irrelevant. The device colorspaces that the buffers value represent is what's important from a color management perspective. Regards, Graeme Gill. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC wayland-protocols] Add the color-management protocol
On Tuesday, 20 December 2016, 14:25:02 CET, Daniel Stone wrote: > Hi Niels, > Just nitpicking at the protocol side of things a little bit; please > excuse what I'm sure is a horrific abuse of the terminology, contained > in what I'm sure is a series of stupid questions. > > On 19 November 2016 at 16:29, Niels Ole Salscheider > > wrote: > > + > > + > > + This interface allows attaching a color space to a wl_surface. The > > + compositor uses this information to display the colors correctly. > > + For this, the compositor converts any attached surfaces to the > > blending + color space before performing the blending operations. > > After blending, + the output surface is converted to the color space > > of the output device. + This interface also provides requests for > > the sRGB and the blending color + space. It further allows creation > > of a color space from an ICC profile. + The client is informed by an > > event if the color space of one of the + outputs changes. > > + > > + > > + > > + > > +With this request, the color space of a wl_surface can be set. > > +The sRGB colorspace is attached to a surface before > > set_colorspace is +called for the first time. > > + > > + > > + > /> + > > Hm. When does this apply: is it at the next wl_surface::commit, or > immediately? FWIW, the correct answer for this is the former. ;) Yes, the former is right. I will make this more explicit. > Putting explicit language in to this effect would be good; it may also > be nice to have this new_id a separate per-surface object, so the > application can then destroy the object to opt out, e.g. if it starts > embedding content of an unknown colourspace, so the best option is to > have the compositor convert from sRGB. Can you explain what exactly you mean by per-surface objects? Do you suggest to add a wl_surface argument to the zwp_colorspace_v1 object or how would it work? The reason why I did not do this was because I expect that many (sub)surfaces will use the same color profile, e. g. sRGB or the preferred (blending) color space of the compositor. We can avoid the former by defining that no colorspace object implies sRGB. But that does not help for the preferred color space that might be used if the client does simple color conversions on its own. > Another good reason to have a per-surface object is so you have > explicit control: only one per-surface object can be active at any > time, and that surface is free to call set_colorspace as many times as > it wants. Without per-surface objects, you can't enforce the same > 'only one at a time' model. My idea was that set_colorspace can be called as often as the client wants - the new color profile will be used once wl_surface.commit is called and the old profile won't have effect anymore from there on. > > + > > + > > +This request allows to create a zwp_colorspace_v1 object from an > > ICC +profile. The fd argument is the file descriptor to the ICC > > profile (ICC +V2 or V4). > > + > > + > > + > > + > > This should probably take length + offset, and note explicitly whether > it requires NULL termination or not, and how that relates to the size. > Our experience with xkbcommon was that _not_ NULL-terminating was > ideal. I have never seen length and offset arguments in other wayland requests that take an fd (do you have an example?). But I can add it if it is useful. > > + > > + > > +This request returns a zwp_colorspace_1 object for the sRGB color > > +space. The sRGB color space is initially attached to all > > surfaces. > > + > > + > > + > > Why is returning this object useful? The only use I can see is to > return the surface to the 'unset' state, which could possibly be more > cleanly handled by destroying a per-surface object. The description is > also copypasta. Yes, the use case is to reset the color profile to sRGB. If we switch to per- surface objects we can remove this. > > + > > + > > +This request returns a zwp_colorspace_v1 object for the blending > > color +space of the compositor. All surfaces are converted by the > > compositor +to the blending color space before the blending > > operations. Once the +blending is performed, a further color > > conversion to the output color +spaces is carried out by the > > compositor. > > +A client should render in the blending color space returned by > > this +request if it does any color conversion on its own. This > > allows the +compositor to skip the color conversion to the > > blending color space. + > > + > > + > > This might be a stupid question, but is the blending colourspace > constant, or could it feasibly be changed if you had, e.g., outputs > with different characteristics? I understand
Re: [RFC wayland-protocols] Add the color-management protocol
On Wed, 21 Dec 2016 20:44:24 -0700 Chris Murphy said: > On Wed, Dec 21, 2016 at 5:49 PM, Carsten Haitzler > wrote: > > On Wed, 21 Dec 2016 12:24:33 -0700 Chris Murphy > > said: > > > >> So... > >> > >> Do applications (wayland clients) choose what compositor to use? Each > >> application could be using a different compositor? > >> > >> Does it make any sense that there'd be three different classes of > >> compositor: no-color management, assume sRGB color management, and > >> full color management (all objects are explicitly tagged and the > >> compositor is doing display compensation with the help of e.g. lcms)? > >> Or am I missing something about compositors? > > > > your choice of wm or desktop chooses your compositor. choose gnome? it'll be > > mutter. choose enlightenment? it'll be enlightenment. choose kde? it'll be > > kwin etc. etc. etc. > > Aha OK. And how does Weston fit into it? Do any of them directly > leverage Weston or is it just a reference to get Wayland support > included? it's the reference/test compositor. if you want a fully working desktop these days it's gnome's mutter, enlightenment or more recently kde's kwin has been catching up. there is a tiling wm called sway as well. that's the major compositors that are actually meant for "every day" use. weston isn't something i'd say is useful for day to day (not without a lot of extending/work). -- - 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] Add the color-management protocol
On Wed, Dec 21, 2016 at 5:49 PM, Carsten Haitzler wrote: > On Wed, 21 Dec 2016 12:24:33 -0700 Chris Murphy > said: > >> So... >> >> Do applications (wayland clients) choose what compositor to use? Each >> application could be using a different compositor? >> >> Does it make any sense that there'd be three different classes of >> compositor: no-color management, assume sRGB color management, and >> full color management (all objects are explicitly tagged and the >> compositor is doing display compensation with the help of e.g. lcms)? >> Or am I missing something about compositors? > > your choice of wm or desktop chooses your compositor. choose gnome? it'll be > mutter. choose enlightenment? it'll be enlightenment. choose kde? it'll be > kwin > etc. etc. etc. Aha OK. And how does Weston fit into it? Do any of them directly leverage Weston or is it just a reference to get Wayland support included? -- Chris Murphy ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC wayland-protocols] Add the color-management protocol
On Wed, 21 Dec 2016 12:24:33 -0700 Chris Murphy said: > So... > > Do applications (wayland clients) choose what compositor to use? Each > application could be using a different compositor? > > Does it make any sense that there'd be three different classes of > compositor: no-color management, assume sRGB color management, and > full color management (all objects are explicitly tagged and the > compositor is doing display compensation with the help of e.g. lcms)? > Or am I missing something about compositors? your choice of wm or desktop chooses your compositor. choose gnome? it'll be mutter. choose enlightenment? it'll be enlightenment. choose kde? it'll be kwin etc. etc. 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] Add the color-management protocol
So... Do applications (wayland clients) choose what compositor to use? Each application could be using a different compositor? Does it make any sense that there'd be three different classes of compositor: no-color management, assume sRGB color management, and full color management (all objects are explicitly tagged and the compositor is doing display compensation with the help of e.g. lcms)? Or am I missing something about compositors? Chris Murphy ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC wayland-protocols] Add the color-management protocol
On Wed, 21 Dec 2016 09:56:05 + Daniel Stone said:
> Hi,
>
> On 21 December 2016 at 00:36, Carsten Haitzler wrote:
> > On Tue, 20 Dec 2016 16:46:07 + Daniel Stone said:
> >> On 19 December 2016 at 02:08, Carsten Haitzler
> >> wrote:
> >> > so... here is my question - shouldn't the colorspace be tired to a
> >> > buffer? not a surface? yes. i know. the surface "displays" the buffer...
> >> > but the colorspace is intrinsic to the buffer content... right?
> >>
> >> Conceptually, buffer is a good shout, but buffers are hidden from you
> >> in EGL. Given that people will want to do (at least vaguely)
> >> colour-correct GL rendering, that makes surface rather than bufer the
> >> right choice.
> >
> > i actually meant wl_buffer which is really the abstraction on top of these
> > buffers... ?
>
> No, I mean that client rendering looks like this in EGL:
> egl_dpy = eglGetPlatformDisplay(...);
> egl_cfg = eglChooseConfig(egl_dpy, ...);
> egl_surf = eglCreateWindowSurface(egl_dpy, egl_cfg, ...);
> egl_ctx = eglCreateContext(egl_dpy, egl_cfg, ...);
> (bool) eglMakeCurrent(egl_dpy, egl_surf, egl_surf, egl_ctx);
> {
> (void) gl*();
> (bool) eglSwapBuffers();
> }
oh yeah. i was not thinking if client is using egl and eglswapbuffers is hiding
everything. i was thinking clients explicitly sending buffers.
> At no point does an EGL client ever come into contact with the
> wl_buffers produced by EGL. They are utterly opaque, and hidden inside
> the EGL implementation. This means that, in order to get
> colour-correct rendering through EGL, you either have to have it
> attached to the surface (which the client can see and control), or you
> have to grow EGL API for the entire breadth of colour management. This
> is a lot of the reason why we have things like opaque region attached
> to the surface, with the commit latched, rather than buffers.
>
> Cheers,
> Daniel
>
--
- 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] Add the color-management protocol
Hi Graeme, On 21 December 2016 at 01:15, Graeme Gill wrote: > Daniel Stone wrote: >> However, another >> client could then come along and force your client off the plane, such >> that you land in the compositor's GPU pipeline before display: this >> rendering may be done in a 'lowest common denominator' colourspace, >> such that the most optimal / least lossy output from your colour-aware >> client would then _not_ correspond to your display device's native >> characteristics. > > Some details make for possible disadvantages with color > critical applications. Is a "lowest common denominator" space > one with a gamut smaller than any attached display, ensuring > that every color can be displayed without loss, while not > allowing any use of a displays full gamut, or is it > a colorspace that has a larger gamut than any attached > display, meaning that colors will get clipped in > ways the application has no control over, or may > not want ? (i.e. the particular application may > want some other intent such as perceptual or saturation > gamut mapping). I mean lowest common denominator _between clients_, whilst still being tied to the output. So the gamut would ideally be as wide as (the specific output + highest gamut buffer being painted during this stage), but in taking multiple clients with potentially disparate colour source attributes and producing a single flat buffer, you may need to unpick some properties of the client's colour attributes. This is quite a big difference from X11, in that there is no longer a giant single buffer for all displays. One of the benefits of the aggressive decoupling we've done ... Cheers, Daniel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC wayland-protocols] Add the color-management protocol
Hi,
On 21 December 2016 at 00:36, Carsten Haitzler wrote:
> On Tue, 20 Dec 2016 16:46:07 + Daniel Stone said:
>> On 19 December 2016 at 02:08, Carsten Haitzler wrote:
>> > so... here is my question - shouldn't the colorspace be tired to a buffer?
>> > not a surface? yes. i know. the surface "displays" the buffer... but the
>> > colorspace is intrinsic to the buffer content... right?
>>
>> Conceptually, buffer is a good shout, but buffers are hidden from you
>> in EGL. Given that people will want to do (at least vaguely)
>> colour-correct GL rendering, that makes surface rather than bufer the
>> right choice.
>
> i actually meant wl_buffer which is really the abstraction on top of these
> buffers... ?
No, I mean that client rendering looks like this in EGL:
egl_dpy = eglGetPlatformDisplay(...);
egl_cfg = eglChooseConfig(egl_dpy, ...);
egl_surf = eglCreateWindowSurface(egl_dpy, egl_cfg, ...);
egl_ctx = eglCreateContext(egl_dpy, egl_cfg, ...);
(bool) eglMakeCurrent(egl_dpy, egl_surf, egl_surf, egl_ctx);
{
(void) gl*();
(bool) eglSwapBuffers();
}
At no point does an EGL client ever come into contact with the
wl_buffers produced by EGL. They are utterly opaque, and hidden inside
the EGL implementation. This means that, in order to get
colour-correct rendering through EGL, you either have to have it
attached to the surface (which the client can see and control), or you
have to grow EGL API for the entire breadth of colour management. This
is a lot of the reason why we have things like opaque region attached
to the surface, with the commit latched, rather than buffers.
Cheers,
Daniel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC wayland-protocols] Add the color-management protocol
Hi Kai-Uwe, On 20 December 2016 at 19:38, Kai-Uwe wrote: > Am 20.12.2016 um 17:44 schrieb Daniel Stone: >> On 20 December 2016 at 14:46, Kai-Uwe wrote: >>> PDF, SVG2 require handling of different blending color spaces. So the >>> interface appears to be useful. >> >> I'm not quite sure how this response relates to my question, unless >> you are discussing a Weston compositor which targets PDF and/or SVG. > > I am talking about source documents, which might be PDF or SVG. And in > these the blending space can change. So a Wayland client might draw each > PDF/SVG element to a Wayland surface and would come in need to switch > the blending space for rendering the document. Doing it all in Wayland > makes the server much more powerful. > >> In Niels's strawman proposal, there is only _one_ blending colourspace >> for _every_ blending operation performed in the _entire_ compositor. > > Ah ok. So take my comment as the hint for a possible use case for > multiple blending spaces ;-) Yes, if you look at the request as written, it's about _retrieving_ the compositor's single blending space, not setting one. I don't think that's adequate, and as you say, it may be a good solution for clients to provide profiles enabling the compositor to transform for both final display and for blending. >>> My concern is that input == output color space => NULL conversion is >>> flacky. A explicite opt out of color correction would be much appreciated. >> >> What does an explicit opt-out actually mean? Does it mean that the >> compositor assumes sRGB? Linear? That a NULL transform is applied when >> scanning out directly from that surface? When going through a GPU >> composition pipeline, is the inverse transform from the output >> colourspace to blending colourspace, or does 'opt out' mean that >> blending is performed directly in the target colourspace? > > From the main use case of drawing channel values unaltered to the > output, I would say the later. That is as well the current behavior, > without any color correction and changed happening only while blending. > There is no gamma conversion, no color space conversion. The conflict > might be that blending ops work currently best for gamma encoded values > and might be changed to work for linear gamma 1.0 . The transition from > a gamma image to convert to linear gamma for blending should not be > noticeable, perhaps measurable. Further there is the need to copy the > surface for blending to linear gamma. For this case, do not touch the > values, it appears appropriate. But that means that blending (in non-linear space) will look pretty awful. :\ >> I'm also curious as to what you mean by it being flaky. > > Flaky - the client cant not know what happens to its values as > output==output => NULL is a implicit rule. It might be optimised out or > whatever at will of the server and the client is a real looser as it is > only a weak suggestion. A Do Not Touch (or opt out) marker is pretty > clear to everyone and the client can assume to remain in control like > with a contract. It can assume, but it really shouldn't. The client can make its guesses and assumptions about what's going on, but the compositor is free to do much more than what it was under X11, and what it can express to the client. Given the diversity of what compositors do: blending, surface transformation/displacement and cloning across multiple outputs, cloned outputs, screenshots/streaming, etc, this will always be a guess. And this makes me wince every time I see 'opt out'; the intention when writing it is 'the client knows what's going on so can get it right', but I read 'the client doesn't know what the compositor's doing and the compositor doesn't know what the client means, which guarantees that it's going to get it wrong at some point'. I'm still missing some subtlety in your point, but perhaps there's language you could suggest for some part of Niels's strawman spec, which would strengthen these guarantees to a point a client could be assured the right thing was happening. I don't see any future for an 'opt out' flag ever though. Cheers, Daniel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC wayland-protocols] Add the color-management protocol
Daniel Stone wrote: Hi, > If there was a per-output blending colourspace (as well as final > display colourspace), that would make a great deal more sense to me. Agreed. It depends on what is demanded of this blending colorspace - if the demands are not highly critical, then either blending in the native output space (fast and dirty), or blending in a per-channel linear light output space at higher precision (say 16 bit or half) would result in linear light blending without having any impact on color gamut or color precision for each output. Graeme Gill. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC wayland-protocols] Add the color-management protocol
Kai-Uwe wrote: > PDF, SVG2 require handling of different blending color spaces. So the > interface appears to be useful. Yes, but would the compositor really be used to implement this ? My assumption is that blending is a facility to allow the window manager to create various visual effects, such as transparency between different application windows. I also assume that if a window is configured to be partially transparent, then all bets are off as far as color accuracy for that window. Of course it would be nice if color is minimally affected by transparency. > My concern is that input == output color space => NULL conversion is > flacky. A explicite opt out of color correction would be much appreciated. Setting a null (source) colorspace (is presumably) a way to do that, but there is no mechanism for the application to know which display the pixels will end up on, and objections have been raised to providing the application with this information. Graeme Gill. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC wayland-protocols] Add the color-management protocol
Daniel Stone wrote: Hi, > it. Some KMS devices can perform per-plane colour management > (typically a variable-depth degamma LUT, 3x3 CTS matrix and re-gamma > LUT), such that a non-fullscreen client can have correct colour > conversion, independent of any compositor rendering. there's certainly a lot of complexity in full utilizing hardware color transform capabilities. Similar capabilities exist in some higher end displays themselves, although this basically boils down to a mechanism to get the display to emulate a particular colorspace. If the computer system driving the display is smart enough though, such display capabilities can largely be ignored, and the display simply run in a native, widest gamut mode, making that capability available to applications. (Exception - the display per channel LUTs may be higher precision that what is offered by the graphics card VideoLUTs, therefore it is desirable to set calibration in the display. Unfortunately such in display capabilities are largely hidden by proprietary protocols. Typically some means of communicating wit the display via the EDID is needed to support this.) > However, another > client could then come along and force your client off the plane, such > that you land in the compositor's GPU pipeline before display: this > rendering may be done in a 'lowest common denominator' colourspace, > such that the most optimal / least lossy output from your colour-aware > client would then _not_ correspond to your display device's native > characteristics. Some details make for possible disadvantages with color critical applications. Is a "lowest common denominator" space one with a gamut smaller than any attached display, ensuring that every color can be displayed without loss, while not allowing any use of a displays full gamut, or is it a colorspace that has a larger gamut than any attached display, meaning that colors will get clipped in ways the application has no control over, or may not want ? (i.e. the particular application may want some other intent such as perceptual or saturation gamut mapping). Cheers, Graeme Gill. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC wayland-protocols] Add the color-management protocol
On Tue, 20 Dec 2016 16:46:07 + Daniel Stone said: > Hi, > > On 19 December 2016 at 02:08, Carsten Haitzler wrote: > > On Sat, 19 Nov 2016 17:29:20 +0100 Niels Ole Salscheider > > said: > >> + > >> + > >> + This interface represents a color space that can be attached to > >> surfaces. > >> + It is used by the zwp_color_management_v1 interface. > >> + > > > > so... here is my question - shouldn't the colorspace be tired to a buffer? > > not a surface? yes. i know. the surface "displays" the buffer... but the > > colorspace is intrinsic to the buffer content... right? > > Conceptually, buffer is a good shout, but buffers are hidden from you > in EGL. Given that people will want to do (at least vaguely) > colour-correct GL rendering, that makes surface rather than bufer the > right choice. i actually meant wl_buffer which is really the abstraction on top of these buffers... ? -- - 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] Add the color-management protocol
Carsten Haitzler (The Rasterman) wrote: > it's a different mapping of byte1, byte2, byte3 within a pixel to different > r,g > and b points in the visible spectrum. :) It's not though - it's colorimetry, so there is no control over the visible spectrum - the spectral characteristic is determined by the display primary spectral characteristics, and a change in representation/encoding doesn't imply any change in the primaries. Even the RGB's haven't changed, because the relationship between RGB <-> YCbCr is fixed according to a given standard. Graeme Gill. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC wayland-protocols] Add the color-management protocol
Hello Daniel, Am 20.12.2016 um 17:44 schrieb Daniel Stone: > On 20 December 2016 at 14:46, Kai-Uwe wrote: >> Am 20.12.2016 um 15:25 schrieb Daniel Stone: >>> On 19 November 2016 at 16:29, Niels Ole Salscheider + + +This request returns a zwp_colorspace_v1 object for the blending color +space of the compositor. All surfaces are converted by the compositor +to the blending color space before the blending operations. Once the +blending is performed, a further color conversion to the output color +spaces is carried out by the compositor. +A client should render in the blending color space returned by this +request if it does any color conversion on its own. This allows the +compositor to skip the color conversion to the blending color space. + + + >>> >>> This might be a stupid question, but is the blending colourspace >>> constant, or could it feasibly be changed if you had, e.g., outputs >>> with different characteristics? I understand that blending in linear >>> space is a must, but are there other considerations in play which >>> could suggest multiple 'blending spaces' for a single compositor? (I >>> would expect that if the blending space was to be constant across >>> outputs, then it should also be statically derivable by clients, >>> making this event redundant.) >> >> PDF, SVG2 require handling of different blending color spaces. So the >> interface appears to be useful. > > I'm not quite sure how this response relates to my question, unless > you are discussing a Weston compositor which targets PDF and/or SVG. I am talking about source documents, which might be PDF or SVG. And in these the blending space can change. So a Wayland client might draw each PDF/SVG element to a Wayland surface and would come in need to switch the blending space for rendering the document. Doing it all in Wayland makes the server much more powerful. > In Niels's strawman proposal, there is only _one_ blending colourspace > for _every_ blending operation performed in the _entire_ compositor. Ah ok. So take my comment as the hint for a possible use case for multiple blending spaces ;-) + + +This request returns a zwp_colorspace_v1 object for the requested +output. A client can use this when it does not want its surfaces to be +color-corrected. In this case it can attach the color space of its main +output to its surfaces. + + + + >>> >>> If a client doesn't want its surfaces to be colour-corrected ... won't >>> the compositor still convert into blending space and back (not >>> necessarily a lossless operation), if blending is required? >> >> Likely. >> >> My concern is that input == output color space => NULL conversion is >> flacky. A explicite opt out of color correction would be much appreciated. > > What does an explicit opt-out actually mean? Does it mean that the > compositor assumes sRGB? Linear? That a NULL transform is applied when > scanning out directly from that surface? When going through a GPU > composition pipeline, is the inverse transform from the output > colourspace to blending colourspace, or does 'opt out' mean that > blending is performed directly in the target colourspace? From the main use case of drawing channel values unaltered to the output, I would say the later. That is as well the current behavior, without any color correction and changed happening only while blending. There is no gamma conversion, no color space conversion. The conflict might be that blending ops work currently best for gamma encoded values and might be changed to work for linear gamma 1.0 . The transition from a gamma image to convert to linear gamma for blending should not be noticeable, perhaps measurable. Further there is the need to copy the surface for blending to linear gamma. For this case, do not touch the values, it appears appropriate. > I'm also curious as to what you mean by it being flaky. Flaky - the client cant not know what happens to its values as output==output => NULL is a implicit rule. It might be optimised out or whatever at will of the server and the client is a real looser as it is only a weak suggestion. A Do Not Touch (or opt out) marker is pretty clear to everyone and the client can assume to remain in control like with a contract. Kai-Uwe ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC wayland-protocols] Add the color-management protocol
Hi, On 19 December 2016 at 02:08, Carsten Haitzler wrote: > On Sat, 19 Nov 2016 17:29:20 +0100 Niels Ole Salscheider > said: >> + >> + >> + This interface represents a color space that can be attached to >> surfaces. >> + It is used by the zwp_color_management_v1 interface. >> + > > so... here is my question - shouldn't the colorspace be tired to a buffer? not > a surface? yes. i know. the surface "displays" the buffer... but the > colorspace > is intrinsic to the buffer content... right? Conceptually, buffer is a good shout, but buffers are hidden from you in EGL. Given that people will want to do (at least vaguely) colour-correct GL rendering, that makes surface rather than bufer the right choice. Cheers, Daniel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC wayland-protocols] Add the color-management protocol
Hi Kai-Uwe, On 20 December 2016 at 14:46, Kai-Uwe wrote: > Am 20.12.2016 um 15:25 schrieb Daniel Stone: >> On 19 November 2016 at 16:29, Niels Ole Salscheider >>> + >>> + >>> +This request returns a zwp_colorspace_v1 object for the blending >>> color >>> +space of the compositor. All surfaces are converted by the >>> compositor >>> +to the blending color space before the blending operations. Once >>> the >>> +blending is performed, a further color conversion to the output >>> color >>> +spaces is carried out by the compositor. >>> +A client should render in the blending color space returned by this >>> +request if it does any color conversion on its own. This allows the >>> +compositor to skip the color conversion to the blending color >>> space. >>> + >>> + >>> + >> >> This might be a stupid question, but is the blending colourspace >> constant, or could it feasibly be changed if you had, e.g., outputs >> with different characteristics? I understand that blending in linear >> space is a must, but are there other considerations in play which >> could suggest multiple 'blending spaces' for a single compositor? (I >> would expect that if the blending space was to be constant across >> outputs, then it should also be statically derivable by clients, >> making this event redundant.) > > PDF, SVG2 require handling of different blending color spaces. So the > interface appears to be useful. I'm not quite sure how this response relates to my question, unless you are discussing a Weston compositor which targets PDF and/or SVG. In Niels's strawman proposal, there is only _one_ blending colourspace for _every_ blending operation performed in the _entire_ compositor. This means that the blending colourspace must be independent of the output devices; in this case, it is relatively easy to replace this with a single fixed colourspace. If there was a per-output blending colourspace (as well as final display colourspace), that would make a great deal more sense to me. >>> + >>> + >>> +This request returns a zwp_colorspace_v1 object for the requested >>> +output. A client can use this when it does not want its surfaces >>> to be >>> +color-corrected. In this case it can attach the color space of its >>> main >>> +output to its surfaces. >>> + >>> + >>> + >>> + >> >> If a client doesn't want its surfaces to be colour-corrected ... won't >> the compositor still convert into blending space and back (not >> necessarily a lossless operation), if blending is required? > > Likely. > > My concern is that input == output color space => NULL conversion is > flacky. A explicite opt out of color correction would be much appreciated. What does an explicit opt-out actually mean? Does it mean that the compositor assumes sRGB? Linear? That a NULL transform is applied when scanning out directly from that surface? When going through a GPU composition pipeline, is the inverse transform from the output colourspace to blending colourspace, or does 'opt out' mean that blending is performed directly in the target colourspace? I'm also curious as to what you mean by it being flaky. Cheers, Daniel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC wayland-protocols] Add the color-management protocol
Am 20.12.2016 um 15:25 schrieb Daniel Stone: > On 19 November 2016 at 16:29, Niels Ole Salscheider > wrote: >> + >> + >> +This request allows to create a zwp_colorspace_v1 object from an ICC >> +profile. The fd argument is the file descriptor to the ICC profile >> (ICC >> +V2 or V4). >> + >> + >> + >> + > > This should probably take length + offset, and note explicitly whether > it requires NULL termination or not, and how that relates to the size. > Our experience with xkbcommon was that _not_ NULL-terminating was > ideal. Color spaces are binaries. So NULL-termination might not apply? >> + >> + >> +This request returns a zwp_colorspace_v1 object for the blending >> color >> +space of the compositor. All surfaces are converted by the >> compositor >> +to the blending color space before the blending operations. Once the >> +blending is performed, a further color conversion to the output >> color >> +spaces is carried out by the compositor. >> +A client should render in the blending color space returned by this >> +request if it does any color conversion on its own. This allows the >> +compositor to skip the color conversion to the blending color space. >> + >> + >> + > > This might be a stupid question, but is the blending colourspace > constant, or could it feasibly be changed if you had, e.g., outputs > with different characteristics? I understand that blending in linear > space is a must, but are there other considerations in play which > could suggest multiple 'blending spaces' for a single compositor? (I > would expect that if the blending space was to be constant across > outputs, then it should also be statically derivable by clients, > making this event redundant.) PDF, SVG2 require handling of different blending color spaces. So the interface appears to be useful. >> + >> + >> +This request returns a zwp_colorspace_v1 object for the requested >> +output. A client can use this when it does not want its surfaces to >> be >> +color-corrected. In this case it can attach the color space of its >> main >> +output to its surfaces. >> + >> + >> + >> + > > If a client doesn't want its surfaces to be colour-corrected ... won't > the compositor still convert into blending space and back (not > necessarily a lossless operation), if blending is required? Likely. My concern is that input == output color space => NULL conversion is flacky. A explicite opt out of color correction would be much appreciated. Kai-Uwe ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC wayland-protocols] Add the color-management protocol
Hi, On 20 December 2016 at 14:25, Daniel Stone wrote: > Hm. When does this apply: is it at the next wl_surface::commit, or > immediately? FWIW, the correct answer for this is the former. ;) > Putting explicit language in to this effect would be good; it may also > be nice to have this new_id a separate per-surface object, so the > application can then destroy the object to opt out, e.g. if it starts > embedding content of an unknown colourspace, so the best option is to > have the compositor convert from sRGB. > > Another good reason to have a per-surface object is so you have > explicit control: only one per-surface object can be active at any > time, and that surface is free to call set_colorspace as many times as > it wants. Without per-surface objects, you can't enforce the same > 'only one at a time' model. A thought which just coalesced in my mind as I was making coffee, is that this would also allow the compositor to suggest the best colourspace for the surface's content to be rendered in. Though the output device's characteristics are (semi-)constant, the rendering pipeline is not. For instance, if you're switching between blending and not, but even things like content from other clients can affect it. Some KMS devices can perform per-plane colour management (typically a variable-depth degamma LUT, 3x3 CTS matrix and re-gamma LUT), such that a non-fullscreen client can have correct colour conversion, independent of any compositor rendering. However, another client could then come along and force your client off the plane, such that you land in the compositor's GPU pipeline before display: this rendering may be done in a 'lowest common denominator' colourspace, such that the most optimal / least lossy output from your colour-aware client would then _not_ correspond to your display device's native characteristics. Cheers, Daniel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC wayland-protocols] Add the color-management protocol
Hi Niels, Just nitpicking at the protocol side of things a little bit; please excuse what I'm sure is a horrific abuse of the terminology, contained in what I'm sure is a series of stupid questions. On 19 November 2016 at 16:29, Niels Ole Salscheider wrote: > + > + > + This interface allows attaching a color space to a wl_surface. The > + compositor uses this information to display the colors correctly. > + For this, the compositor converts any attached surfaces to the blending > + color space before performing the blending operations. After blending, > + the output surface is converted to the color space of the output > device. > + This interface also provides requests for the sRGB and the blending > color > + space. It further allows creation of a color space from an ICC profile. > + The client is informed by an event if the color space of one of the > + outputs changes. > + > + > + > + > +With this request, the color space of a wl_surface can be set. > +The sRGB colorspace is attached to a surface before set_colorspace is > +called for the first time. > + > + > + > + Hm. When does this apply: is it at the next wl_surface::commit, or immediately? FWIW, the correct answer for this is the former. ;) Putting explicit language in to this effect would be good; it may also be nice to have this new_id a separate per-surface object, so the application can then destroy the object to opt out, e.g. if it starts embedding content of an unknown colourspace, so the best option is to have the compositor convert from sRGB. Another good reason to have a per-surface object is so you have explicit control: only one per-surface object can be active at any time, and that surface is free to call set_colorspace as many times as it wants. Without per-surface objects, you can't enforce the same 'only one at a time' model. > + > + > +This request allows to create a zwp_colorspace_v1 object from an ICC > +profile. The fd argument is the file descriptor to the ICC profile > (ICC > +V2 or V4). > + > + > + > + This should probably take length + offset, and note explicitly whether it requires NULL termination or not, and how that relates to the size. Our experience with xkbcommon was that _not_ NULL-terminating was ideal. > + > + > +This request returns a zwp_colorspace_1 object for the sRGB color > +space. The sRGB color space is initially attached to all surfaces. > + > + > + Why is returning this object useful? The only use I can see is to return the surface to the 'unset' state, which could possibly be more cleanly handled by destroying a per-surface object. The description is also copypasta. > + > + > +This request returns a zwp_colorspace_v1 object for the blending > color > +space of the compositor. All surfaces are converted by the compositor > +to the blending color space before the blending operations. Once the > +blending is performed, a further color conversion to the output color > +spaces is carried out by the compositor. > +A client should render in the blending color space returned by this > +request if it does any color conversion on its own. This allows the > +compositor to skip the color conversion to the blending color space. > + > + > + This might be a stupid question, but is the blending colourspace constant, or could it feasibly be changed if you had, e.g., outputs with different characteristics? I understand that blending in linear space is a must, but are there other considerations in play which could suggest multiple 'blending spaces' for a single compositor? (I would expect that if the blending space was to be constant across outputs, then it should also be statically derivable by clients, making this event redundant.) > + > + > +This request returns a zwp_colorspace_v1 object for the requested > +output. A client can use this when it does not want its surfaces to > be > +color-corrected. In this case it can attach the color space of its > main > +output to its surfaces. > + > + > + > + If a client doesn't want its surfaces to be colour-corrected ... won't the compositor still convert into blending space and back (not necessarily a lossless operation), if blending is required? > + > + > +This event will be sent when the color space of an output is changed. > + > + > + These three, linked together, are somewhat awkward, but then again, so are server-created objects. > + > + > + This interface represents a color space that can be attached to > surfaces. > + It is used by the zwp_color_management_v1 interface. > + > + > + > + > +Informs the server that the client
Re: [RFC wayland-protocols] Add the color-management protocol
On Tue, 20 Dec 2016 18:25:40 +1100 Graeme Gill said: > Carsten Haitzler (The Rasterman) wrote: > > > what if the display can do different color profiles for different regions? > > my example is yuv colorspace. 601 vs 709 etc. actually can be assigned per > > hw plane... they are different colorspaces ... :) > > It isn't a different color space though, just a different color encoding, > since the primaries haven't changed. > > Analogous examples: XYZ and Yxy space. XYZ and L*a*b* space. RGB and LCH. it's a different mapping of byte1, byte2, byte3 within a pixel to different r,g and b points in the visible spectrum. :) -- - 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] Add the color-management protocol
Carsten Haitzler (The Rasterman) wrote: > what if the display can do different color profiles for different regions? my > example is yuv colorspace. 601 vs 709 etc. actually can be assigned per hw > plane... they are different colorspaces ... :) It isn't a different color space though, just a different color encoding, since the primaries haven't changed. Analogous examples: XYZ and Yxy space. XYZ and L*a*b* space. RGB and LCH. Graeme Gill. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC wayland-protocols] Add the color-management protocol
On Mon, 19 Dec 2016 10:07:31 +0100 Niels Ole Salscheider said: > On Monday, 19 December 2016, 11:08:31 CET, Carsten Haitzler wrote: > > On Sat, 19 Nov 2016 17:29:20 +0100 Niels Ole Salscheider > > > > said: > > > Signed-off-by: Niels Ole Salscheider > > > --- > > > > > > 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> > > > diff --git a/Makefile.am b/Makefile.am > > > index e693afa..ff435d5 100644 > > > --- a/Makefile.am > > > +++ b/Makefile.am > > > @@ -12,6 +12,7 @@ unstable_protocols > > > = \ > > > unstable/tablet/tablet-unstable-v2.xml > > > \ unstable/xdg-foreign/xdg-foreign-unstable-v1.xml > > > \ > > > unstable/idle-inhibit/idle-inhibit-unstable-v1.xml > > > \ + > > > unstable/color-management/color-management-unstable-v1.xml > > > \ $(NULL) > > > > > > stable_protocols > > > > > > = \ diff > > > --git a/unstable/color-management/README > > > b/unstable/color-management/README new file mode 100644 index > > > 000..3bd3e6c > > > --- /dev/null > > > +++ b/unstable/color-management/README > > > @@ -0,0 +1,4 @@ > > > +Color management protocol > > > + > > > +Maintainers: > > > +Niels Ole Salscheider > > > diff --git a/unstable/color-management/color-management-unstable-v1.xml > > > b/unstable/color-management/color-management-unstable-v1.xml new file mode > > > 100644 index 000..f2bb3f6 > > > --- /dev/null > > > +++ b/unstable/color-management/color-management-unstable-v1.xml > > > @@ -0,0 +1,136 @@ > > > + > > > + > > > + > > > + > > > +Copyright © 2014-2016 Niels Ole Salscheider > > > + > > > +Permission to use, copy, modify, distribute, and sell this > > > +software and its documentation for any purpose is hereby granted > > > +without fee, provided that the above copyright notice appear in > > > +all copies and that both that copyright notice and this permission > > > +notice appear in supporting documentation, and that the name of > > > +the copyright holders not be used in advertising or publicity > > > +pertaining to distribution of the software without specific, > > > +written prior permission. The copyright holders make no > > > +representations about the suitability of this software for any > > > +purpose. It is provided "as is" without express or implied > > > +warranty. > > > + > > > +THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS > > > +SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND > > > +FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY > > > +SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES > > > +WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN > > > +AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, > > > +ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF > > > +THIS SOFTWARE. > > > + > > > + > > > + > > > + > > > + This interface allows attaching a color space to a wl_surface. The > > > + compositor uses this information to display the colors correctly. > > > + For this, the compositor converts any attached surfaces to the > > > blending + color space before performing the blending operations. > > > After blending, + the output surface is converted to the color space > > > of the output device. > > > + This interface also provides requests for the sRGB and the blending > > > color > > > + space. It further allows creation of a color space from an ICC > > > profile. + The client is informed by an event if the color space of > > > one of the + outputs changes. > > > + > > > + > > > + > > > + > > > +With this request, the color space of a wl_surface can be set. > > > +The sRGB colorspace is attached to a surface before > > > set_colorspace is +called for the first time. > > > + > > > + > > > + > > /> + > > > + > > > + > > > + > > > +This request allows to create a zwp_colorspace_v1 object from an > > > ICC +profile. The fd argument is the file descriptor to the ICC > > > profile (ICC > > > +V2 or V4). > > > + > > > + > > > + > > > + > > > + > > > + > > > + > > > +This request returns a zwp_colorspace_v1 object for the requested > > > +output. A client can use this when it does not want its surfaces > > > to be > > > +color-corrected. In this case it can attach the color space of > > > its > > > main > > > +
Re: [RFC wayland-protocols] Add the color-management protocol
On Monday, 19 December 2016, 11:08:31 CET, Carsten Haitzler wrote: > On Sat, 19 Nov 2016 17:29:20 +0100 Niels Ole Salscheider > > said: > > Signed-off-by: Niels Ole Salscheider > > --- > > > > 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> > > diff --git a/Makefile.am b/Makefile.am > > index e693afa..ff435d5 100644 > > --- a/Makefile.am > > +++ b/Makefile.am > > @@ -12,6 +12,7 @@ unstable_protocols > > = \ > > unstable/tablet/tablet-unstable-v2.xml > > \ unstable/xdg-foreign/xdg-foreign-unstable-v1.xml \ > > unstable/idle-inhibit/idle-inhibit-unstable-v1.xml \ > > + > > unstable/color-management/color-management-unstable-v1.xml \ > > $(NULL) > > > > stable_protocols > > > > = \ diff --git > > a/unstable/color-management/README b/unstable/color-management/README new > > file mode 100644 index 000..3bd3e6c > > --- /dev/null > > +++ b/unstable/color-management/README > > @@ -0,0 +1,4 @@ > > +Color management protocol > > + > > +Maintainers: > > +Niels Ole Salscheider > > diff --git a/unstable/color-management/color-management-unstable-v1.xml > > b/unstable/color-management/color-management-unstable-v1.xml new file mode > > 100644 index 000..f2bb3f6 > > --- /dev/null > > +++ b/unstable/color-management/color-management-unstable-v1.xml > > @@ -0,0 +1,136 @@ > > + > > + > > + > > + > > +Copyright © 2014-2016 Niels Ole Salscheider > > + > > +Permission to use, copy, modify, distribute, and sell this > > +software and its documentation for any purpose is hereby granted > > +without fee, provided that the above copyright notice appear in > > +all copies and that both that copyright notice and this permission > > +notice appear in supporting documentation, and that the name of > > +the copyright holders not be used in advertising or publicity > > +pertaining to distribution of the software without specific, > > +written prior permission. The copyright holders make no > > +representations about the suitability of this software for any > > +purpose. It is provided "as is" without express or implied > > +warranty. > > + > > +THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS > > +SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND > > +FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY > > +SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES > > +WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN > > +AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, > > +ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF > > +THIS SOFTWARE. > > + > > + > > + > > + > > + This interface allows attaching a color space to a wl_surface. The > > + compositor uses this information to display the colors correctly. > > + For this, the compositor converts any attached surfaces to the > > blending + color space before performing the blending operations. > > After blending, + the output surface is converted to the color space > > of the output device. > > + This interface also provides requests for the sRGB and the blending > > color > > + space. It further allows creation of a color space from an ICC > > profile. + The client is informed by an event if the color space of > > one of the + outputs changes. > > + > > + > > + > > + > > +With this request, the color space of a wl_surface can be set. > > +The sRGB colorspace is attached to a surface before > > set_colorspace is +called for the first time. > > + > > + > > + > /> + > > + > > + > > + > > +This request allows to create a zwp_colorspace_v1 object from an > > ICC +profile. The fd argument is the file descriptor to the ICC > > profile (ICC > > +V2 or V4). > > + > > + > > + > > + > > + > > + > > + > > +This request returns a zwp_colorspace_v1 object for the requested > > +output. A client can use this when it does not want its surfaces > > to be > > +color-corrected. In this case it can attach the color space of > > its > > main > > +output to its surfaces. > > + > > + > > + > > + > > this above i wonder if this shoiuld be done this way. does it not expose too > much about an output? what happens when the output changes its colorspace? > imagine it has software control
Re: [RFC wayland-protocols] Add the color-management protocol
On Sat, 19 Nov 2016 17:29:20 +0100 Niels Ole Salscheider said: > Signed-off-by: Niels Ole Salscheider > --- > 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 > > diff --git a/Makefile.am b/Makefile.am > index e693afa..ff435d5 100644 > --- a/Makefile.am > +++ b/Makefile.am > @@ -12,6 +12,7 @@ unstable_protocols > = \ > unstable/tablet/tablet-unstable-v2.xml > \ unstable/xdg-foreign/xdg-foreign-unstable-v1.xml\ > unstable/idle-inhibit/idle-inhibit-unstable-v1.xml\ > + > unstable/color-management/color-management-unstable-v1.xml\ > $(NULL) > stable_protocols > = \ diff --git > a/unstable/color-management/README b/unstable/color-management/README new > file mode 100644 index 000..3bd3e6c > --- /dev/null > +++ b/unstable/color-management/README > @@ -0,0 +1,4 @@ > +Color management protocol > + > +Maintainers: > +Niels Ole Salscheider > diff --git a/unstable/color-management/color-management-unstable-v1.xml > b/unstable/color-management/color-management-unstable-v1.xml new file mode > 100644 index 000..f2bb3f6 > --- /dev/null > +++ b/unstable/color-management/color-management-unstable-v1.xml > @@ -0,0 +1,136 @@ > + > + > + > + > +Copyright © 2014-2016 Niels Ole Salscheider > + > +Permission to use, copy, modify, distribute, and sell this > +software and its documentation for any purpose is hereby granted > +without fee, provided that the above copyright notice appear in > +all copies and that both that copyright notice and this permission > +notice appear in supporting documentation, and that the name of > +the copyright holders not be used in advertising or publicity > +pertaining to distribution of the software without specific, > +written prior permission. The copyright holders make no > +representations about the suitability of this software for any > +purpose. It is provided "as is" without express or implied > +warranty. > + > +THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS > +SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND > +FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY > +SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES > +WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN > +AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, > +ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF > +THIS SOFTWARE. > + > + > + > + > + This interface allows attaching a color space to a wl_surface. The > + compositor uses this information to display the colors correctly. > + For this, the compositor converts any attached surfaces to the blending > + color space before performing the blending operations. After blending, > + the output surface is converted to the color space of the output > device. > + This interface also provides requests for the sRGB and the blending > color > + space. It further allows creation of a color space from an ICC profile. > + The client is informed by an event if the color space of one of the > + outputs changes. > + > + > + > + > +With this request, the color space of a wl_surface can be set. > +The sRGB colorspace is attached to a surface before set_colorspace is > +called for the first time. > + > + > + > + > + > + > + > +This request allows to create a zwp_colorspace_v1 object from an ICC > +profile. The fd argument is the file descriptor to the ICC profile > (ICC > +V2 or V4). > + > + > + > + > + > + > + > +This request returns a zwp_colorspace_v1 object for the requested > +output. A client can use this when it does not want its surfaces to > be > +color-corrected. In this case it can attach the color space of its > main > +output to its surfaces. > + > + > + > + this above i wonder if this shoiuld be done this way. does it not expose too much about an output? what happens when the output changes its colorspace? imagine it has software controls where it can chnage its mapping or hardware buttons etc.? shouldnt we just have a list of colorspaces available (that may change at any time so some kind of event indicating a change would be needed)? > + > + > +This request returns a zwp_colorspace_1 object for the sRGB color > +space. The sRGB color
Re: [RFC wayland-protocols] Add the color-management protocol
Niels Ole Salscheider wrote: Hi, > The ICC profiles to which the zwp_colorspace objects point can be compared > easily: Each ICC profile contains an unique 128 bit fingerprint in the header > so > that only this fingerprint has to be compared. actually, this isn't true. The MD5 fingerprint value was only introduced in ICC V4, and so is not present in ICC V2 profiles. Even in V4 profiles, it is recommended rather than mandatory, so can't be relied upon. Graeme Gill. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC wayland-protocols] Add the color-management protocol
On Wednesday, 23 November 2016, 12:20:42 CET, Bill Spitzak wrote: > Is there a way to determine if two zwp_colorspace objects are actually the > same? The ICC profiles to which the zwp_colorspace objects point can be compared easily: Each ICC profile contains an unique 128 bit fingerprint in the header so that only this fingerprint has to be compared. Do you think that this is enough or do you want this information to be duplicated in the zwp_colorspace object? > I can imagine clients being interested in whether or not the output > colorspace is sRGB, and whether or not the blending color space is > sRGB or the output space. > > > On Sat, Nov 19, 2016 at 8:29 AM, Niels Ole Salscheider > > wrote: > > Signed-off-by: Niels Ole Salscheider > > --- > > > > 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> > > diff --git a/Makefile.am b/Makefile.am > > index e693afa..ff435d5 100644 > > --- a/Makefile.am > > +++ b/Makefile.am > > @@ -12,6 +12,7 @@ unstable_protocols = > > \> > > unstable/tablet/tablet-unstable-v2.xml > > \ > > unstable/xdg-foreign/xdg-foreign-unstable-v1.xml > > \ > > unstable/idle-inhibit/idle-inhibit-unstable-v1.xml > > \ > > > > + unstable/color-management/color-management-unstable-v1.xml > > \> > > $(NULL) > > > > stable_protocols = > > \> > > diff --git a/unstable/color-management/README > > b/unstable/color-management/README new file mode 100644 > > index 000..3bd3e6c > > --- /dev/null > > +++ b/unstable/color-management/README > > @@ -0,0 +1,4 @@ > > +Color management protocol > > + > > +Maintainers: > > +Niels Ole Salscheider > > diff --git a/unstable/color-management/color-management-unstable-v1.xml > > b/unstable/color-management/color-management-unstable-v1.xml new file > > mode 100644 > > index 000..f2bb3f6 > > --- /dev/null > > +++ b/unstable/color-management/color-management-unstable-v1.xml > > @@ -0,0 +1,136 @@ > > + > > + > > + > > + > > +Copyright © 2014-2016 Niels Ole Salscheider > > + > > +Permission to use, copy, modify, distribute, and sell this > > +software and its documentation for any purpose is hereby granted > > +without fee, provided that the above copyright notice appear in > > +all copies and that both that copyright notice and this permission > > +notice appear in supporting documentation, and that the name of > > +the copyright holders not be used in advertising or publicity > > +pertaining to distribution of the software without specific, > > +written prior permission. The copyright holders make no > > +representations about the suitability of this software for any > > +purpose. It is provided "as is" without express or implied > > +warranty. > > + > > +THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS > > +SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND > > +FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY > > +SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES > > +WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN > > +AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, > > +ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF > > +THIS SOFTWARE. > > + > > + > > + > > + > > + This interface allows attaching a color space to a wl_surface. The > > + compositor uses this information to display the colors correctly. > > + For this, the compositor converts any attached surfaces to the > > blending + color space before performing the blending operations. > > After blending, + the output surface is converted to the color space > > of the output device. + This interface also provides requests for > > the sRGB and the blending color + space. It further allows creation > > of a color space from an ICC profile. + The client is informed by an > > event if the color space of one of the + outputs changes. > > + > > + > > + > > + > > +With this request, the color space of a wl_surface can be set. > > +The sRGB colorspace is attached to a surface before > > set_colorspace is +called for the first time. > > + > > + > > + > /> + > > + > > + > > + > > +This request allows to create a zwp_colorspace_v1 object from an > > ICC +profile. The f
