[Development] Color Management support in Qt 5?

Kai-Uwe Behrmann ku.b at gmx.de
Wed Nov 13 15:58:26 CET 2013


Am 10.11.2013 11:05, schrieb John Layt:
> On 9 November 2013 12:50, Olivier Goffart <olivier at woboq.com> wrote:
>> On Saturday 09 November 2013 03:02:18 Alessandro Portale wrote:
>>> I like the idea of re-starting small, and quite a bit of what was done
>>> in Nokia times can certainly be re-used.
>>> What if Qt started by simply *enabling* color management. I.e. giving
>>> access to the information that an application needs to perform color
>>> management tasks itself. In a much later iteration Qt could perhaps
>>> perform color management operations. Qt should IMHO avoid automatic
>>> color management under the hood, especially without providing API to
>>> control it.
>>>
>>> Milestones could be:
>>> 1) QImage[Reader] gives access to image color profile. Either whole
>>> profile or just an identifier in case of standard spaces such as sRgb.
>>> 2) QScreen gives access to the current display color profile for that
>>> specific screen.
>>> 3) There are notifications (signals?) when the a window changes to
>>> another screen, or when a screen profile is changed in the system.
>>> 4) Same as "2" but for installed Printers on the system.
>>> ...
>>> 99) QColorEngine can do color conversions using an input profile, a
>>> source Image an output profile plus different parameters.
>>>
>>> Ideas? Kai-Uwe, what color management feature (or enabler) are you
>>> missing most in Qt?
>> Allow me to disagree :-)
>> How usefull are 1-4 without 99?  What exactly can you do with that
>> information.
> Well, I'm no expert at the graphics side of things, but I think before
> you can start applying a color profile you need to know what color
> profile to apply :-)  If we at least expose that config for apps to
> use then they only need to apply the transforms themselves, rather
> than also having to abstract the system config.  Then afterwards we
> can start using the config ourselves in our own code.  OTOH we don't
> want to ship api that we may have to change later when we start using
> it ourselves in anger.
>
> I think step 1 is very definitely a cross-platform api to access the
> host system config and profiles, regardless of whether we make it
> public or not.  That's easy enough for Windows and Mac where each has
> a single color management framework built-in, but on Linux we still
> have two competing systems (perhaps Kai-Uwe can update us on that
> situation, is there a single combined config yet?).

Most applications use for Xorg the ICC Profile in X spec [1]. The spec 
is served by Oyranos CMS as well as the colord CMS and others.

> Now, to really expose my lack of knowledge, AFAIK Mac especially and
> Windows graphics contexts can apply the required transforms themselves
> internally, so wherever we use the native context it's surely just a
> case of configuring them to do the work for us?  It's really only on
> Linux or XP that we would have to have code for doing the transforms
> ourselves using LCMS?  But like I said, I know nothing of our graphics
> internals :-)

Lcms is for realtime conversions too slow. OpenGL provides in some 
profiles a 3D texture lookup on the GPU, which is fast.

kind regards
Kai-Uwe Behrmann

[1] 
http://www.openicc.info/index.php?title=ICC_Profiles_in_X_Specification_0.4



More information about the Development mailing list