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.

Input Color Profile (colorin)

• Problem:

  1. does internal RGB -> Lab conversion
  2. virtually always followed by a module taking RGB input
  3. so the pipeline converts from Lab back to RGB

• Solution:

  1. have colorin only do RGB(camera) -> RGB(pipe) conversion
  2. need to update iop data version to add a flag whether output should be Lab or RGB (for compatibility with existing edits)

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.

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.