[Openicc] Color Management for compositor mutter
hughsient at gmail.com
Thu May 5 07:43:27 PDT 2011
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:
-- I'm hopeful that I also will get invited to the OpenICC round table
discussion this year.
>> 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
> Most colours are shades and blended and not solid on modern desktops.
Sure, agreed. But unless you're using a monitor profile that does
something crazy like swap the blue and red channels the blending is
going to work just as the designer hoped it would.
>> ...But in this specific case, some of the output pipelines are
>> using GL already (e.g. gstreamer) and so adding an extra texture
>> transform into the pipeline really isn't hard at all. The only hard
> Sounds useful to me.
Yup, I was meant to talk to the GStreamer guys about it last year, but
I ran out of time. It's on my list of things to do when I'm at GUADEC
> 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
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.
> 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
> 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
level code to "enable" color correction or to "disable" color
correction then we've, again, failed as architecture designers.
I really think this kind of stuff needs to be in the framework code,
well below the application layer.
More information about the openicc