This page describes the Color Conversion System (CCS) of pigment.
One of the goal of pigment is to offer the most accurate conversion between two color spaces and with a minimum loss of information. For the most common color spaces (Grayscale, RGB, CMYK, LAB and XYZ) this is done using ICC Profile and the lcms library, but only for 8bit and 16bit integer. For floating points, an extension to ICC Profile has been proposed in 2006 ( see ) but it's not implemented yet in LCMS, but other color management library like WCS () and very likely SampleICC, but WCS is only available on Windows, and SampleICC's licence is not compatible with GPL.
In Krita 1.6, color conversion between ICC color spaces is assumed by lcms, and when conversion involves a non ICC color spaces it either fallback to LAB16 integer or worse to RGB8 integer. This introduce a loss of information, especially for HDR images.
LCMS follow the ICC workflow, meaning that all color spaces are attached with a profile that defines transformation to either XYZ or LAB. So unless a shortcuts is possible (like for a change of depth), colors are first convert either to XYZ or LAB, then back to the destination color space. Shortcuts are also available.
BABL is a "dynamic, any to any, pixel format conversion library". It's use by GEGL for color conversion. BABL makes the assumption that all color spaces can can be converted without loss to RGB float 32bits, so all color spaces are expected to at least defines a transformation to and from RGB float 32 bits, plus they can define additional transformations. If no direct transformation is found, going through RGB32Float is considered as the reference transformation, but it's not necessarily the fastest transformation. So all possible pathes are evaluated, each path is then compared to the reference transformation, the fastest one which gives the same results as the reference transformation is then used to convert pixels.
A solution to that problem is to adopt a more flexible Color Conversion System as described in this document.
The two main requirements are:
* respect color correctness * support transformation between HDR colorspace without losing the dynamic range information
The first requirement means to use ICC transformation as much as possible. But, on a side note, both requirements might conflicts at some point. The Dynamic Range transformation receive priority when the transformation is between to float/HDR color spaces, indeed there is no point in keeping the dynamic range information if the final color space doesn't support dynamic range, and if the user want to transform color between two HDR color space, it's very unlikely that he will accept the lost of the dynamic range information.
The best way to represent all the possible color transformation is to use a graph, where the node are color spaces and the vertex are possible direct transformation. Then the creation of a color conversion transformation is research of the best path in the graph.
Dynamic range criterion is inhibited if either the source color space or the destination color space isn't an HDR color space.
When a color space factory is added to the registry, it is also inserted in the graph of color space transformation, in function of advertised features, all ICC color spaces are linked together.
Before a color transformation is created, the CCS determine the path with the lowest cost in the graph. The results of that search is then saved in a cache.
Condition to stop the exploration of the graph:
This section describes how the CCS can be tested, and used to study the behavior of color conversion in pigment.