[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Re: Re: [GSoC] KWin colour management
From:       Kai-Uwe Behrmann <ku.b () gmx ! de>
Date:       2012-03-22 18:20:11
Message-ID: alpine.LNX.2.00.1203221903470.8311 () siras ! rasena
[Download RAW message or body]


Am 22.03.12, 18:41 +0100 schrieb Thomas Lübking:
> Am 22.03.2012, 08:55 Uhr, schrieb Kai-Uwe Behrmann <ku.b@gmx.de>:
>
>> Lets hypothetical assume some effort is initiated to bring CM to Qt and
>> that happens during Qt 5 life time. The new design says by default all
>> content is considered sRGB, which is by itself reasonable. However
>> existing applications will initially not know about that changed
>> convention.
> Errrmmm... how is that please different from opting out of the compositor?
> Except that latter does not only hit Qt applications but also *every* 
> "legacy" stuff around?

I was tould by the graphics community to keep the X Color Management spec 
backward compatible with the ICC Profile in X spec, so we did. Thus old 
style applications see a sRGB profile through the ICC Profile in X spec, 
and they continue to work by converting to sRGB.

>> The conflict is solveable by making the new drawing API incompatible with
>> the old one, e.g. requiring a colour space argument.
> Or by making user code color correction calls (QApplication::setColorSpec(int 
> spec)?) invalidate/override library settings?

Something like that is technical possible. But let me repeat, you get then 
a mixture of colour managed and non colour managed apps with the same 
toolkit, which is completely non understandable for users.

kind regards
Kai-Uwe Behrmann
-- 
www.oyranos.org

[prev in list] [next in list] [prev in thread] [next in thread]