Roadmap

darktable's DNA is anarchy and personal projects. However, given the recent increase in contributions, it might be good to write down the high-level priorities of each contributor to get a general idea of the direction the project is taking and of the future challenges. Any contributor should feel free to add their personal views, goals and projects on this page.

Full RGB scene-linear workflow

The benefits of the scene-linear workflow is to provide consistent blurs, alpha blending (for masks), and intensity-scalable filters that can work for HDR and SDR as well. It is also the starting point for inter-operability with compositing and painting software operating in scene-referred (Blender, Natron, Krita, etc.) and HDR screen support.

Each module can now declare its internal color space (Lab or RGB) and the pixel pipeline has an internal way of converting Lab <-> RGB between modules when needed.

The custom has been taken to rename "xxxx RGB" the modules that work internally in RGB color space. Modules from darktable 2.6 and prior that do the Lab <-> RGB conversion internally should be re-written to use the pipeline-level conversion.

Pipeline

• Problems:
  1. future modules may need to work internally in XYZ color space (and derivated Yxy or Yuv spaces).
• Solutions:
  1. add XYZ as internal color space for modules.

Color balance

• Problems:
  1. uses internal conversion Lab -> RGB -> Lab.
  2. contrast setting affects color saturation (because the standard algo has been chosen for interoperability with ASC-CDL).
  3. saturation algo is not perfectly hue-linear (because the standard algo has been chosen for same reasons).
• Solutions:
  1. use pipeline conversion Lab -> RGB, but it might need a color space different from the pipeline working RGB (like log-encoded ACEScc).
  2. add chroma-preserving contrast modes as alternatives to standard.
  3. add vibrance setting (based on the one developed for the basic module in PR #3599) and chroma setting (based on the filmic v4 color science in PR #4800)
• Improvements:
  1. add fulcrums to slope/offset/power to define the range of application of each settings (see Filmlight software).
  2. do some sort of gamut sanitization after color correction.
• Notes:
  1. discussions with @sobotka and @aurelienpierre need to converge to some rational solution to achieve a sensible color correction in this module.

Tone equalizer

• Problems:
  1. the guided filter does not blur the highlights and the lowlights uniformly, lowlights are blurred much more.
• Solutions:
  1. an exposure-invariant guided filter is being developed by @rawfiner and @aurelienpierre and needs extensive tests.

Channel mixer

• Problems:
  1. mistakes have been founds in the computations, leading to wrong computations (erroneous parentheses)
  2. RGB values are clipped between 0 and 1.
• Solutions:
  1. fix mistakes: PR #5106 by @mtvoid.
  2. rewrite a scene-referred able channelmixer RGB: PR #4940 by @aurelienpierre.

Filmic RGB

• Problems:
  1. OpenCL kernels for the v4 are not provided.
• Solutions:
  1. PR #5762 by @aurelienpierre adds OpenCL support.

Low-pass, High-pass and contrast equalizer

• Problems:
  1. use Lab color space internally, which is not suited with their physically-defined operations.
• Solutions:
  1. convert to linear Yxy space before applying the algorithms. The rest of the algorithms should not be affected since Yxy follows the same logic as Lab for the chroma/luma separation.

Masking & Blending API

• Problems:
  1. blending operations clip RGB values between 0 and 1.
  2. masking operations in Lab/Lch are poorly suited to HDR scenes.
• Solutions:
  1. clip RGB blending operations only for negative values.
  2. use JzAzBz space for chroma/luma/hue masking (to generate the alpha mask) but apply the alpha blending in "linear" RGB whenever possible.
• Notes:
  1. PR #4688 by @hlecleme implements the solutions neatly. Testing and merging this work is high-priority.

Documentation

The documenting work was put on hold, waiting for the PR from @mica that promised to move it from awfull Saxon custom XML format to something more contrib-friendly. That PR never made it to core because of translation issues. Meanwhile, new features were not documented. Documentation is high-priority for darktable 3.4.