Calligra/Libs/Pigment/Color Conversion System

From KDE Community Wiki
< Calligra‎ | Libs‎ | Pigment
Revision as of 17:59, 6 December 2010 by Cyrille (talk | contribs) (Created page with 'This page describes the Color Conversion System (CCS) of pigment. = The problems = One of the goal of pigment is to offer the most accurate conversion between two color spaces a...')
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

This page describes the Color Conversion System (CCS) of pigment.

The problems

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 [1]) but it's not implemented yet in LCMS, but other color management library like WCS ([2]) 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.

How it is done in other libraries

LCMS

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

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.

Color Conversion System

A solution to that problem is to adopt a more flexible Color Conversion System as described in this document.

Requirements

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.

Graph

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.

criterion

  • color correctness
  • bit depth
  • dynamic range (it's mostly wether there is a float to integer transformation)
  • length of the path

Dynamic range criterion is inhibited if either the source color space or the destination color space isn't an HDR color space.

Implementation detail

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:

  • a direct path between the color spaces is available, it is assumed to be the best answer to the problem
  • once a solution has been found that maximize the criterions, the search is stop and that path is used for color conversion
  • all the path have been explored, then the less worse (the best solution doesn't exist) solution is selected

Tests

This section describes how the CCS can be tested, and used to study the behavior of color conversion in pigment.

  • output the graph of color conversion link using graphviz, output for each colorspace the best linked selected to convert to any color space
  • compute all the link that maximize the criterions (removing length of the path) and check that they gives the same results
  • compute all the link and see how link that don't maximize the criterions affects the result
  • test that all color pace can be converted to any other color space with a maximal link