[Development] Color Management support in Qt 5?

[Kai-Uwe Behrmann]

Am 09.11.2013 12:50, schrieb Olivier Goffart:
> On Saturday 09 November 2013 03:02:18 Alessandro Portale wrote:
>> Allow me jump into this topic to contribute to its liveliness :)
>>
>> The term "Color Management" has been used in different ways here on
>> the list. Lately, it was about how to blend images in a non-linear
>> color space. That is IMHO perhaps a small and not "that typical" part
>> of what color management means for imaging applications.
>>
>> 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.
>
> All the QPainter API assume linear colorspace (at least in the raster paint
> engine). And that would be difficult to change that and the result would be much
> slower painting.
> What does the scene graph do?
>
> That means that when you blend images or smooth scale, or antialias, Qt assume
> everything is in the linear colorspace.
>
> I think milestones could rather be:
>
> 1) QImage[Reader] converts automatically to linear color space, so that all
> QImage's are in the linear color space
> 2) A conversion to the screen's colorspace is done "at the end" (by the
> platform plugin?  by the compositor?)
> 3) Allow QImage to be in any colorspace and have QImage::colorProfile()
> 4) change QPainter, and graphicssystem to handle different colorspaces.

Alessandros feature list allows for early binding by applications. That 
is essentially what colour managed apps do today. They take input 
colours and convert them to output colours themself. With the mentioned 
APIs inside Qt, they can do that the Qt way without platform specific code.

Oliver,
what you describe is about late colour binding.
A minor annotation to your point 1)
 > QImage[Reader] converts automatically to linear color space, so that 
all QImage's are in the linear color space
Some app authors will dislike to be forced to have uncontrolled colour 
conversions. So I would like to add the feature request for a conversion 
switch off for opaque images. Uncontrolable changes of pixel colours can 
result in e.g. wrong measurements for ICC profile generation.

Otherwise I do not see a contradiction to what Alessandro wrote as his 
feature list is a precondition to do the automatic or late colour 
binding stuff.

kind regards
Kai-Uwe Behrmann