[Development] Color Profile support on Qt

[Kai-Uwe Behrmann (oy)]

Alessandro Portale <alessandro <at> casaportale.de> writes:

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

Drawing during displaying on the fly is a typical approach. osX does this
implicitly and always accelerated. On Windows conversion will happen on 
the CPU and only after explicitly requested. For Linux it is/will be a mixture.

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

Sounds quite unusual.

> profile has little meaning in a color management workflow. Imho,

agreed!

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

Keeping the ICC profile around is a good entry strategy.

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

agreed, a Qt specific abstraction would be desirable for C++ and QImage.

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

The QICCProfile should at least expose a QByteArray on each platform to obtain 
the raw ICC blob beside the internal description and ICC ID.

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

That API would need a concept of device listings and driver contexts for 
display outputs, scanners, printers and cameras.

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

void QtColorManagement::profileTranformedImage(const QImage &image_in, 
const QICCcontext &conversion, QImage &image_out); // Conversions can 
happen in place

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

For the long plan, I doubt that would be useful. For now it is a big step
forward to store ICC profiles along a QImage as meta data.

Considered can as well a general framework to store IPC, Exif and other
information additional to ICC profile for each loaded image.

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

The Quartz backend for webkit in Safari tags all colours with the according
input colour space as is required by osX API's.

However the current approach in FF is to convert all colours on input, which 
has generally some disadvantages. But that is as well the most simple way to
implement colour correction with a ICC support lacking drawing API.

kind regards
Kai-Uwe
-- 
www.behrmann.name www.oyranos.org