[RFC PATCH 1/6] Add colorcorrection protocol

[Kai-Uwe Behrmann]

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:
>>> how much data can an ICC profile be?
>> Printer profiles can be several megabytes in size, but display
>> profiles (what will be seen here) are usually in the 20-30kb size
>> range.
> I do wonder if we will have a problem with the maximum message
> size in Wayland. I'm not sure how the maximum is determined, and since
> profiles could in theory be very big, I'd propose using an out-of-band
> method for transferring that data.
>
>>> Also, what if a client has several surfaces all with the same ICC
>>> profile, would it not be useful to have some notion of re-using an
>>> already sent and parsed color profile? Otherwise I would imagine lots
>>> of overhead if every surface has a private copy of the profile
>>> sent over the wire, parsed, and stored in the compositor's renderer.
>> I don't think typically they'll be many different profiles in use, on
>> a typical system most things will just be (assumed) sRGB to 'n'
>> display profiles, where n is the number of outputs.
> I take that as "yes, explicit re-use would be very useful" to avoid
> parsing, comparing and coalescing at every turn.
>
>>> 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.

> I would also like to have room for compositors that blend in a
> non-ideal color space. Having a separate blending color space is
> essentially an additional copy, AFAIU, which is a pretty high cost for
> something, whose result any single client cannot assume at all, anyway.
> I still think that if a client needs the result of blending non-opaque
> pixels to be guaranteed, it should do it itself and not rely on the
> server.
>
>> Overall, I'm very happy to see someone pick up this work. Thanks.
> Indeed.

kind regards
Kai-Uwe