[Development] Color Management support in Qt 5?

John Layt jlayt at kde.org
Sun Nov 10 11:05:06 CET 2013


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?).

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 :-)

Cheers!

John.



More information about the Development mailing list