[Development] Color Profile support on Qt

[Alessandro Portale]

On Mon, Jul 16, 2012 at 7:07 PM, Olivier Goffart <olivier at woboq.com> wrote:
> All QPainter operations (at least in the raster engine) assume a linear color
> space. That means that the color conversion need to hapen last, right before
> being shown to the screen. After all kind of blending operations or anything
> done with QPainter.  (That means it could even been done in the platform
> plugin)

Good point. That way may automagically solve the issue with which
screen (output-) profile to use when painting on a "screen". However,
color transformations are not cheap and may slow down painting. I
already see all kinds of caching in that area :)

> Color conversion should probably also happen when loading images, to convert
> them to a linear color space.  Right now, Qt do no handle color profiles at
> all, so it interpret png for example as plain linear RGB instead of sRGB.

Would the 'linear' RGB in this case be the screen RGB? RGB without a
profile has little meaning in a color management workflow. Imho,
QImage could continue loading the "raw" rgb-data as-is and
additionally load/hold the profile of the image (or the very common
sRgb tag) in order to use that as input profile at the end when
painting. This would also make sure that there is only one color
transformation in the (load -> display) workflow. Two color
transformations will cause quantisation artifacts, esp. with 8-data.

>> > Just a few questions:
>> > 1) Would Qt use (and ship) a color conversion library, or would the
>> > system library be used where available (e.g. on OSX and Windows)?
>>
>> Regarding native platform support, we should work together with
>> Oyranos developers. While their API is horrible (maybe because it is
>> so non-Qt'ish), they have in-depth knowledge about the theory and the
>> praxis of color management. Maybe with their expertise, we can create
>> a nice API for application developers to interface the platforms.
>
> I'd say Qt should use an external library for that. This problem has already
> been solved, and there is no reason to reinvent the wheel.
> That said, I'm saying that without knowing what are the available libraries.

There are free libraries that do icc profile based color conversions.
Qt could "ship" one of those as 3rd-party code. The functionality that
was missing in any of these libraries -last time I looked-, is a cross
platform API to get the current system profile for a screen. I did not
yet look at Oyranos, though.


My 2 cents. If I may sketch a very dirty, basic API set which could
imho enable different cases for "color savvy" application develpers:

  QImage::QImage(...) // Constructors would load image input profile
or standard profile tag (sRgb/Adobe Rgb).

  QICCProfile QImage::profile(); // Returns the original image input
profile. (Yes, this should be part of QtColorManagement, not QtGui.
This sketch *is* dirty)

  static QICCProfile QtColorManagement::systemProfile(int screenID =
0); // Return the current system profile for a specific screen (TODO:
printer?)

  static QImage QtColorManagement::profileTranformedImage(const QImage
&image, const QICCProfile &outputProfile) // The resulting Image data
is now in the colorspace of a specific screen or printer(cmyk?)

  static QImage QtColorManagement::profileTranformedColor(const QColor
&color, const QICCProfile &inputProfile, const QICCProfile
&outputProfile) // Transforming single colors.

  ... QPainter would remain color profile agnostic, as it is right now.

Such an API would avoid all automatic conversions by default, and
simply provide cross platform helpers for app developers who decide to
consciously do color management.
QtWebkit could of course perform color management as Safari does: "If
a loaded image has a profile/tag" match it to screen.