[RFC PATCH 1/6] Add colorcorrection protocol

[Pekka Paalanen]

On Mon, 31 Mar 2014 13:13:40 +0200
Kai-Uwe Behrmann <ku.b-list at gmx.de> wrote:

> Am 31.03.2014 11:43, schrieb Pekka Paalanen:
> > On Mon, 31 Mar 2014 09:25:34 +0100
> > Richard Hughes <hughsient at gmail.com> wrote:
> >
> >> On 31 March 2014 08:46, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> >>> Is that a reasonable requirement for all compositors that support
> >>> per-output ICC profiles?
> >> I think it's a very little amount of work, IMO doing it centrally
> >> makes a lot of sense as some bits are tricky to do correctly.
> > "Tricky" should be solve by shared libraries rather than a daemon,
> > IMHO. I'm more concerned about the amount of work the compositor will
> > be doing, not the work for implementing it. I think such color space
> > conversion should be accounted for the client, i.e. done in the client.
> 
> The concerns of KWin's Martin where at time of implementing CM, that
> colour conversions shall be done in one place. Pro inside KWin was
> mentioned to have only few LUTs applied to many textures. In the logical
> opposite, contra client side conversions was the need to compute store
> and cache all LUTs per client, without much sharing among different
> clients running under one compositor.
> 
> Feature wise, the only output aware colour correcting applications I
> know of under Linux are two compositors, with Niels path three, and some
> client side example code in Oyranos. So moving stuff to the clients will
> very likely loose those valuable features like per output correction,
> speedy ICC colour corrected movie displaying, consitency etc.
> 
> > It would be wasteful, if a compositor needs to compute the source
> > conversion every time it just repaints the screen, even if the content
> > for a color-managed surface has not changed. I'm assuming a compositor
> > would be texturing directly out of a client's buffer.
> 
> In many cases a client is not remotely able to compute per output
> regions without much information about scaling, positioning, (warping?)
> etc. In the past very few clients used that informations even if
> available. See my comment above. Client side colour correction (early
> colour binding) was and is a corner case - even sometimes a very
> valuable one. With more features going inside compositors, it becomes
> for clients harder to predict on which output a pixel will appear.
> Practical clients would need to analyse all effects a compositor
> performs on a clients buffer, for that to work correctly.

My starting point for the *protocol* is that one surface can be
correct for only one output at a time, and the compositor is
telling the client which output it is. I think we already have the
main output designation... or do we... at least we already would
need it for clients to properly handle output_scale and
output_transform, so that problem exists already.

That should not preclude the possibility of a compositor doing
proper color mapping from a surface separately to each output, so
that the surface shows correctly on every output instead of just
one at a time.

What I would advocate, if possible, is to keep the option of doing
one output at a time correct colors mapped in the client, and if a
compositor really wants to go all the way, it can do the color
mapping itself per-output. All the compositor needs is to know in
which color space/profile the client produced the pixels, or if it
must be uncorrected (does uncorrected for all outputs make sense?).

So, if a client is concerned about the color correctness, it can do
the mapping itself for one output at a time, and get guaranteed
results (the compositor will not alter the pixel values that get
scanned out on that output).

If a compositor wants to, it can have clients provide all surfaces
in some suitable standard color spaces, and map separately to each
output.

If you think that is too much duplicate work to have "correct
colors" implemented optionally by either compositors or clients,
that is ok.

I guess what I am asking here is, what is a compositor required to
implement, when it exposes some color management interface to
clients, and what guarantees do clients have. To me it would seem
reasonable to allow demanding clients work also on simple
compositors that do not do correct arbitrary color mapping on behalf
of clients; in such cases, the client should somehow know that, and
be allowed to render so that uncorrected (in compositor)
presentation will be correct for one output. Do you think that
would be worth it, or do we just not allow compositors that go only
half way?

By "simple" I could also mean "efficient" or "performant", since I
assume doing all the color mapping at compositing time would be
relatively expensive - especially if it forces the compositor to
ignore an opportunity for direct scanout from client buffer.


Thanks,
pq


PS. please use reply-to-all so we don't lose all the CCs.