[Openicc] Color Management for compositor mutter

[Kai-Uwe Behrmann]

Am 05.05.11, 15:43 +0100 schrieb Richard Hughes:
> On 5 May 2011 15:17, Kai-Uwe Behrmann <ku.b at gmx.de> wrote:
>> You want a clutter specific spec for your personal largest convenience.
>> Sorry that is not going to work.
>
> That's really not what I said.
>
>> OpenICC round table in Brussels. Next one will be likely in Montreal in some
>> few days.
>
> I'm presenting this:
> http://create.freedesktop.org/wiki/Making_color_management_%22just_work%22_using_colord
> -- I'm hopeful that I also will get invited to the OpenICC round table
> discussion this year.

OpenICC is open to anyone interessted in ICC colour management toppic.

>>> And pretty much *all* the software the studios use.
>>
>> Strong claims and none if any substantiation. That reads like bad marketing.
>
> The company I work for, Red Hat, has contracts with at least two of
> the big studios. I'm sure you can understand I can't tell you who they
> are, and I certainly can't tell you what software they run. But I'm
> pretty sure anyone who's been to the cinema in the last year or so
> knows both studios very well.
>
> I about 2 months I'm hopefully going to both studios in person to talk
> to the developers there about GNOME3. That's as much as I'm willing to
> substantiate.

The big studios I know have quite the potential to find or implement a 
small work around if they really need native colours with existing closed 
source software especially on Linux with its great flexibility. As well
typical studio software runs on dedicated work places full screen. 
Colour grading is often enough done in special rooms. The selection 
of a window manager is not at all an issue in this context.

>> As I am writing this email I sit in front of a wide gamut and a average
>> monitor. As well all laptops with attached monitor should look comparable
>> IMO.
>
> Sure, I'm on a huge gamut HP DreamColor screen, and also a pretty
> crappy T510 display. I never watch films spanning both screens, nor
> work with windows straddling them as there's a ~50cm gap from glass
> edge to glass edge.

If you have no problem with one monitor showing previews and the other 
final graphics and GUI elements in a uncorrected manner I have. Maybe
you have switched the wide gamut to emulate a sRGB display. That would be 
natural without a working colour server.

>> In other words, it makes no sense to adhere in the print pipeline to a
>> opt-out model, while we agree to opt-in for displaying.
>
> Well, that's not quite what I said. I think it makes a lot of sense
> for some things like background wallpaper and window controls to be
> early-color-bound. But some things, like video, to be late color
> bound. But late color bound doesn't automatically mean using the
> window manager.

Well. Some clearification. Applications and toolkits can do late and 
early colour binding as much as they like.

For systems exists a more narrow definition of opt-in and opt-out. Let 
us not confuse that with late and early colour binding in applications.
If a system enforces every content to be colour managed regardless of 
being tagged with a ICC profile or not and has some very specific means 
for pass through of colours it is opt-out. If it does not care about 
untagged content it is opt-in and applications must actively order any 
colour trasnformation. Both schemes can supply the underpinnings for early 
and late colour binding.

>> It makes sense to use the same basic principle throughout all device classes
>> for easier understanding af all involved parties.
>
> I don't think anyone but a handful of people should understand all
> this. If an application developer has to add a single line of low

Understanding colour management should be easy to everyone interessted if 
well architectured and including becoming useable and teachable.

> level code to "enable" color correction or to "disable" color
> correction then we've, again, failed as architecture designers.

Wrong. On osX each programmer must specify the colour space to each 
graphics object.

> I really think this kind of stuff needs to be in the framework code,
> well below the application layer.

Agreed. CompICC and Ghostscript are system layer. And that should work 
with all toolkits in the same way.


kind regards
Kai-Uwe Behrmann
-- 
developing for colour management 
www.behrmann.name + www.oyranos.org