color management spec

[Lubos Lunak]

On Saturday 31 of May 2008, Kai-Uwe Behrmann wrote:
> Am 30.05.08, 16:47 +0200 schrieb Tomas Carnecky:
> > Lubos Lunak wrote:
> > >  There are technical things I don't like about the proposal, but before
> > > we get to that, I think this mail is seriously lacking in the "Why"
> > > department. For example: Why the compositing manager should do that?
> > > Or: Why do the work of adding it to compositing managers when many
> > > users don't use them for various reasons and then applications
> > > presumably need to handle it themselves anyway?
> >
> > Ideally no support at all from applications should be needed. If you for
> > example set the default profile for untagged windows to sRGB (which is
> > what applications implicitly assume) then you get a color corrected
> > display basically for free. I don't primarily target applications that
> > absolutely need color management (professional graphics applications
> > etc.) because those need to do it internally anyway in most cases. For
> > normal desktop users with old computers who can not afford to use
> > compositing managers color management doesn't make much sense.

 I don't think it's about old computers. For compositing you need decent 
hardware, good support in X and a good driver, and it's a question if anybody 
has all of that these days (I have strong doubts about that). I run a 
compositing manager only because I develop it, otherwise I probably wouldn't. 
I somehow would expect that people who actually care about precise colors 
would generally also care about stability, performance or whatever else it is 
compositing managers today are not that reliable at. So it looks to me like 
with this approach you're aiming for a relatively far future.

> > But new 
> > computers with wide gamut displays etc. will need color management. And
> > you don't want to add color management to every single application, not
> > only because it would be difficult but also because the performance
> > would be worse then if you did the color conversion in a compositing
> > manager. They already use OpenGL and the GPU, so adding a (one line!)
> > fragment shader isn't that big deal.

 It certainly is today. 'They' is two compositing managers in total, as far as 
I'm aware, and AFAIK fragment shaders aren't that common these days either. 
There are XRender-only compositing managers, and there are apparently many 
people using XRender even when they theoretically could use OpenGL. That may 
be a part of your plan, but then again it is limiting the user base or aiming 
for future.

> To add to this, the project of handling colour management inside compiz
> has many sides which are nice to modularise:
> A ) communicate what is required by a application (regions, profiles..),
>     and tell what can be done by the windowmanager?
> B ) convert a ICC profile conversion into a shader description
> C ) wrap most of the above into Oyranos API's and
>     a hopefully small remainder into a compiz plug-in
>
> Ideally applications see nothing about this.

 Why does the original proposal speak about the compositing manager doing it 
on the behalf of applications then?

> And let me ask you, Lubos, why not in compiz? What is difficult with
> it? Or, where else?

  'Why' is a natural question when being told to do something without being 
told why. Or can I count on you or somebody else writting the necessary code 
for me?

-- 
Lubos Lunak
KDE developer
--------------------------------------------------------------
SUSE LINUX, s.r.o.   e-mail: l.lunak at suse.cz , l.lunak at kde.org
Lihovarska 1060/12   tel: +420 284 028 972
190 00 Prague 9      fax: +420 284 028 951
Czech Republic       http://www.suse.cz