darktable employs a fully color managed workflow:
Input color specifications are taken from embedded or user supplied ICC profiles or – in the case of raw files – from a library of camera specific color matrices.
darktable automatically reads the display profile of your monitor (if properly configured) for an accurate color rendition on screen. Multi-screen setups are fully supported as long as a system service like colord is in place and properly set up to inform darktable about the correct monitor profile.
In order for darktable to accurately render colors on screen it needs to find the correct display profile of your monitor. In general this requires your monitor to be properly calibrated and profiled, and it needs the profile to be correctly installed on your system. darktable querys your X display server's xatom as well as the system service colord (if available) for the right profile. If needed you can enforce a specific method in the GUI preferences dialog (see Section 8.1, “GUI options”).
To investigate your display profile configuration you can call the
darktable-cmstest binary which prints out useful information like
profile name per monitor and tells you if the system is correctly configured (see
Section 1.1.6, “
In rare cases you may need to manually select the display profile. This is possible from the softproof and gamut check option dialogs in the darkroom view (see Section 184.108.40.206, “Soft proof” and Section 220.127.116.11, “Gamut check”), and the display profile dialog in the lighttable view (see Section 2.1, “Overview”).
A configuration parameter “always use LittleCMS 2 to apply output color profile” in darktable's core options (see Section 8.2, “Core options”) defines how colors are rendered.
darktable can render colors either with its internal algorithms or by using the external library LittleCMS2. darktable's internal method is by an order of magnitude faster than the external one. The external option gives you a choice of the rendering intent and might offer a slightly higher accuracy in some cases.
Note that if the given ICC is LUT-based or contains both, a LUT and a matrix, darktable will use LittleCMS 2 to render the colors regardless of that configuration parameter's value.
If rendering with LittleCMS2 is activated (see Section 18.104.22.168, “Rendering method”) you can define how out-of-gamut colors are handled when converting between color spaces. A selection box in the export panel (see Section 2.3.12, “Export selected”), the output color profile module (see Section 22.214.171.124, “Output color profile”), and the soft proof option (see Section 126.96.36.199, “Soft proof”) gives you a choice of the following rendering intents:
|perceptual||Suited to pictures as it maintains the relative position of colors. This is usually the best choice.|
|relative colorimetric||Out-of-gamut colors are converted to colors having the same lightness, but different saturation. Other colors remain unmodified.|
|saturation||Saturation is kept but lightness is slightly changed.|
|absolute colorimetric||Keep the white point.|
darktable's input images are either RGB files (like JPEGs or TIFFs) or camera raws – both represent colors by a combination of red, green and blue. Most part of our modules act in the CIELAB color space (often just called “Lab”) which describes color as a combination of lightness data (L) and a point in the a-b color plane. The final output of the image processing pipeline is once again in RGB, either shaped for the monitor display or the output file.
This process implies that the pixelpipe has two color conversion steps: input color profile and output color profile. In addition there is the demosaic step for raw images, where the colors of each pixel are reconstructed by interpolation.
Each module has a fixed position in the pixelpipe which tells you which color space the module lives in:
|up to demosaic||Image is in raw data format with only latent colors. Each pixel carries lightness and color information for only one base color. Please mind that some of the modules in this part can also act on non-raw input images in RGB format with full information on all three color channels.|
|between demosaic and input color profile||Image is in RGB format within the color space of the specific camera or input file.|
|between input color profile and output color profile||Image is in Lab format. This is a very huge universal color space which covers all colors visible to the human eye (and even more). As darktable processes images in 4x32-bit floating point buffers, we can handle the Lab color space without risking banding or tonal breaks.|
|after output color profile||Image is in RGB format as defined by the selected display or output ICC profile.|
Theoretically the individual components of color data are confined to certain minimum and maximum levels. As an example the intensity of an individual red, green or blue color channel in RGB can be anything in the range between 0% and 100% (or between 0.0 and 1.0). Likewise the L channel in Lab can be anything between 0 (pure black) and 100 (pure white).
In practice sometimes the image processing steps in darktable's modules can lead to values which lie outside of these confined ranges. In fact even the well established color matrices, which convert from camera RGB to Lab, may sometimes produce pixels with negative L values.
Pixels with these kind of values are said to have “unbounded colors”. One could clamp (i.e. confine) those values to the allowed range at every processing step. However, it has been found that it is much preferred and less prone to artifacts to not clamp in-between unbounded colors, but treat them just like any other color data.
In darktable there is no technical requirement for clamping; due to the fact that we are using floating point arithmetics for all processing steps, unbounded values can be passed along like any other value until the final color conversion module makes sure that they are transferred into the most reasonable color within the selected output color space. Therefore darktable avoids clamping as far as the underlying algorithms allow.
That said there are some infrequent situations which still can lead to problematic results unless the user takes some action. Some modules in Lab color space, like levels and monochrome, need to rely on the fact that the L channels carries all lightness information and the a and b channels purely represent chroma and hue. Unbounded colors with negative L values are especially problematic to these modules and can lead to black pixel artifacts.
It has been found that highly saturated blue light sources in the image frame are hot candidates for pixels with negative L values. If you are engaged in stage photography you should pay close attention to image areas like that.
In order to mitigate that issue the input color profile module (see Section 188.8.131.52, “Input color profile”) has a gamut clipping option. It is off by default but can be activated in case you observe artifacts. Depending on the settings, colors get confined to one of the offered RGB gamuts. In effect black pixel artifacts are prevented at the costs of losing some color dynamics. See Section 184.108.40.206, “Input color profile” for an example.