[Development] Color Management support in Qt 5?

[Olivier Goffart]

On Sunday 10 November 2013 11:05:06 John Layt wrote:
> 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 :-)

There is really two uses case: 
 1) Enabling API so QImage can be used as a container for programs that do 
proffesional image processing
 2) Correctness of the Qt painting system. (Regarding drawing images from the 
internet, antialiasing, and blending)

Enabling a QImage::colorProfile(),  having public API for color conversion, or 
having QImage with more than 32bit per pixel would fit the use case #1
The question we need to ask ourself is if we want to provide such advanced API 
for image manipulation.  Or should the image manipulation software make use of 
specialized third party libraries or implement it themself.


Then we have the IMHO more important thing which is correctness of Qt itself.  
How can Qt be suitable for an image manipulation program if it does not even 
draw properly?

If you don't know what I mean, here are the problem with the current 
implementation of the raster paint engine: The raster paint engine assume a 
linear color space.    (I don't what the scene graph does). 
It assume that the intensity of a pixel is proportional to its value. In other 
words, it assumes that a pixel (128,128,128)  will have half of the intensity 
of (255,255,255).
But because the human eyes is more sensible to low intensity it is common to 
have a non linear intensity. (This is called gamma) And color profiles usually 
have different gamma.  And every screen have a different gamma too.

For example, when drawing a black line with antialiasing enabled, Qt will try 
to compute what is the portion of a pixel which contains, and if half of the 
pixel is covered by the line, then the pixel will have 0.5 of the value. But 
that's only valid in a linar space.  Same when blending one image on another 
one: Qt will do     alpha * pixel1  + (1-alpha) * pixel2.    Again, one would 
need to account for the gamma while blending, but Qt Does not. Also the 
computation used when drawing an image with smooth scale would need to use 
gamma correction.

The difference is not that big but is clearly visible to the trained eyes.  
Samuel once showed me a demo he made that was showing the difference on a few 
examples.


So this is why I am saying that QImage should only be in the linear color 
space.  It should be up to the image loader to convert to  linear space and  
the backing store should do the conversion to the screen color space.

Then Qt would behave correctly and we can start talking about exposing API to 
do color conversion.


-- 
Olivier

Woboq - Qt services and support - http://woboq.com - http://code.woboq.org