[Development] QT5 and color management

[Anders Torger]

On 08/29/2016 03:16:16 PM, Morten Sorvig wrote:
> 
> > On 29 Aug 2016, at 10:20, Anders Torger <torger at ludd.ltu.se> wrote:
> > 
> > 
> > Hello,
> > 
> > The color management capabilities of QT for displaying images is
> quite 
> > hard to figure out. I've searched the internet and you get very few
> 
> > hits often pointing to discussions several years old. So I think
> it's 
> > appropriate to start a new thread to get the latest.
> > 
> > I'm new to QT, but I'm not new to color management and ICC 
> profiles.
> 
> > I've worked a bit with GTK and RawTherapee project so I know how
> color 
> > management is handled there in Windows / Linux and OS X.
> > 
> > What you typically do in a cross-platform scenario is that you
> figure 
> > out which ICC profile the display has in a platform-specific way 
> (if
> 
> > you have multi-head you just have to choose one, haven't seen 
> anyone
> 
> > handle a window which is displayed on two screens simultaneously),
> and 
> > then you use LittleCMS or other third-party library to convert your
> 
> > RGB data yourself to an output that matches the display, and then
> you 
> > just put that raw data to the screen using the GUI toolkit. In 
> other
> 
> > words, the GUI toolkit doesn't do any color conversions, but just 
> > delivers the raw pixel values to the display.
> > 
> > This is how you do it in GTK. With GTK there is as far as I know a 
> > problem on Mac OS X, where GTK is not low-level enough; Mac OS X
> APIs 
> > (Quartz?) will do the display conversion always so you can only
> output 
> > sRGB(?). I've not worked too much with OS X so I'm not 100% sure 
> how
> it 
> > works there or if there is a work-around to get larger color space
> than 
> > sRGB. If anyone happens to know that too, I'm all ears.
> 
> We’ve researched a bit into the OS X side of this, see QTBUG-47660.
> Input
> from application developers is very welcome here - I’d like to make
> sure
> what we implement is actually usable in practice.
> 
> If you don’t want to use OpenGL then we’re looking at supporting two
> modes:
> 
> * The application outputs sRGB/linear sRGB to Qt. Qt will configure
> the
>   native view accordingly, color conversion to the display color 
> space
> 
>   is done by the OS.
> 
> * The application gets the ICC profile for the display and outputs
> per-
>   display correct colors to Qt. Qt configures the native view to use
> the 
>   display profile. There is no color space conversion outside
> application code.
> 
> There is currently no API available to support this; the first
> iteration
> would probably be a a mac-spesifc API.
> 
> Recently Apple introduced the "extended linear sRGB” color space
> (with
> support for component values below 0.0 and above 1.0), specifically
> for
> wide-gamut displays. I think we need floating-point support in QImage
> to make use of this format.
> 
> Morten
> 
> 

Thanks. Looking at QTBUG-47660, if I understand it correctly it says 
that since QT 5.5 a QImage will output "native" pixels to the display. 
That is if I send 255,0,0 the display it will show the reddest red 
it can output. If that is correct, it will work for us, as we then can 
do "the usual way", that is find and load the display ICC profile using 
a native method, and use LittleCMS to convert from our internal format 
to the display's color space. That would be great, as it would work the 
same in Linux, Windows and OS X then.

In the longer term I'm sure the typical application developer would 
love the mode when color space is locked to sRGB (or better if you can 
pick among a number of presets) and then QT makes sure proper 
conversion to the display takes place under the surface. That is the 
typical application developer never needs to care about color 
management, "it just works".

However the typical application developer probably doesn't care at all 
if colors vary a bit as few applications require accurate colors.

If color management is required it's a special case, and I think 
application developers can then accept the extra complexity by having 
to use LittleCMS or similar to do the conversion on their own. The most 
important thing is that you actually *can* do it in some way or 
another. As said with GTK it was not possible on OSX due to output 
colorspace being locked to sRGB rather than native display like on the 
other platforms.

When writing cross-platform applications I see an advantage in 
"dumbing down" color management so it becomes equal between Linux/
Windows/OSX. In Linux and Windows we've used to having to do it 
manually in the application as the colors we send to the toolkit will 
be displayed with native display values. OSX has more advanced/
automatic color management, but if QT makes use of that it would mean 
that either it would work differently in Linux/Windows or one would 
have to make QT's color management a lot more advanced on those 
platforms to make it as automatic as on OSX.

The largest drawback with the application-doing-it-on-its-own approach 
is that multi-head configurations can't really be made to work. The 
classic example if you have half of your application window on one 
screen and the other half on another, which have different ICC 
profiles. App-controlled color management usually means that you 
convert for the primary display, and only that. If QT itself would 
handle color management on a lower level I assume multi-head could work 
too. However I find this problem to be a minor one, as when you do work 
with a color managed application, it's about graphics, photos etc, and 
then you generally have one expensive calibrated monitor which is your 
primary display where you place the GUI.

/Anders