[RFC wayland-protocols 1/1] unstable: add color management protocol

[Graeme Gill]

Pekka Paalanen wrote:

> Is this sent for all color spaces added by clients as well
> (color_space_from_icc request)? If yes, I think that has potential to
> become denial-of-service attack vector. A malicious client adding a ton
> of color spaces could easily cause all new clients to disconnect when
> the compositor send buffer overflows on creating a zwp_color_manager_v1
> object. It is even more prone because the initial events will carry a
> fd per profile, and the number of fds is much more limited than
> messages.

I don't see a case for (source) color profiles uploaded by
a client being visible to other clients. Other clients
don't know what they represent, so can't really
make use of them. It would be a waste of time to even look
for them.

The idea of making standard profiles available to all clients
is a way of not duplicating well understood spaces. These
are usable by all clients because they have understood identifiers
and definitions, and are not going to change while the client is
using them. (Note however that it is possible for an output
profile to change, so ideally there should be a way of a client
being notified of this, so that they can take appropriate
action if they wish).

> Chris had some good comments on terminology. Is "color space" correct
> here? "Color image encoding"?

I suspect different people may mean different things by these.

By my definitions, a colorspace is something that comes
out of, or goes into a color capture or reproduction device,
or something that can be related to device independent color values.

Encoding on the other hand, is a way of representing those
color values in a digital form. So by my definition that
includes reversible transformations such as YCC like encodings,
different bit depths, float vs. integer and ranges (i.e. video range encoding) etc.

I'm not sure if there is a formal definition that can be pointed to.

> - zero/one or more outputs, can't the same color space apply to
>   multiple outputs? Most likely if the outputs are not actually
>   calibrated but use either the standard sRGB assumption or maybe an
>   ICC profile from then vendor rather than individually measured.

Yes, that's the most likely scenario. But all the profiles
(i.e. output profiles, standard profiles, client uploaded
 profiles) should be able to be referred to by a handle or
 object identifier, and that would be what is used to tag
 the output or surface.

Cheers,
	Graeme Gill.