[Openicc] ICC Profiles in X Specification 0.4

[Richard Hughes]

On 25 March 2010 08:48, Kai-Uwe Behrmann <ku.b at gmx.de> wrote:
> I use Xinerama APIs on a daily basis. They work relyable. The indexing of
> ICC_PROFILE(_xxx) must follow the Xinerama API. It should be explicitely
> described in the next spec version. Thats all.

I don't use Xinerama, as it's deprecated. Please read
http://en.wikipedia.org/wiki/Xinerama -- it's insane to base a new
spec on an obsolete technology.

> The original _ICC_PROFILE spec misses several use cases. We should correct
> that.

Has anybody actually written down those use cases?

> This implies to me to deprecate _ICC_PROFILE and move device informations
> into _ICC_DEVICE_PROFILE. Thus apps can be explicite together with the
> net-color spec.
> The _ICC_PROFILE is then there for backward compatibility only and free to
> be altered by the colour server.

If _ICC_DEVICE_PROFILE was moved to a XRandR property, that would make
sense. It's already way too difficult for applications to know "what's
the output ICC profile for this window". I'm currently providing a
simple DBus server to get this kind of information easily if an
application wants to do early color binding. In that way, applications
get a filename from a simple window XID, rather than having to work
out what Xinerama output they are on (or mostly on) and then to get a
property from the root window.

> The net-color spec itself is pretty indifferent. What we need to discuss
> here is how to integrate with the ICC in X spec.

Well, if an application is using net-color then presumably this
interacts with other part of the specification. net-color seems to be
telling the composting manager of the source profile, and then
offloading the processing to the compiz frontend, where I assume sRGB
is used for the non-tagged regions. Whilst it's a cool trick, I'm not
sure how well viewing something like a PDF would work, with multiple
ICC profiles for each image, and the application has to tag each
sub-region of the file (which changes as the user scrolls, etc),
rather than windows. I'm sure for applications like that it would be
more useful to do early color binding (using lcms for instance) and
then tag a window region as "don't color convert me to monitor profile
twice".

In this way it would be a bit like a firewall, where you only 'punch'
out regions of the desktop which are already color managed. All we
need to do is ask applications which respect _ICC_PROFILE to tag the
window with an X property (_ALREADY_COLOR_CORRECTED?), and then leave
it up to compiz to color correct the rest of the screen, masking out
the tagged areas. This seems a much easier thing to ask application
authors to do, and we can even provide hooks in the toolkit (e.g. for
an auto color corrected GtkImage) to make things even easier.

This seems a lot easier that trying to upload profiles to the server
and referencing them by uuids, trying to keep the two synchronized,
and then trying to convert from all the different source profiles to
destination profiles in one place. In my opinion, of course.

Richard.