This section tries to explain some of the basic concepts on how darktable develops images in the darkroom.
The basic element of an image operation in darktable is called a module. darktable comes with a rich set of over 60 modules for all kind of image manipulations. In Section 3.4, “Modules” you will find a description for each of the available modules.
darktable processes images – from input to output – in a so called “pixelpipe”. Within the pixelpipe image processing consists of consecutive operations which are implemented as “modules”.
Modules are applied in a fixed order. This differentiates darktable, as a non-destructive image editor, from classical image manipulation programs like GIMP. As module order is fixed, you are free to activate, deactivate or change the parameters of a module at arbitrary points in time; the order of activation in your workflow does not have any impact on the outcome.
Users frequently ask why the module order is fixed and if there are plans to change that restriction. There are several reasons why darktable works in the way described:
The sequence of modules has been selected with great care in order go give highest output quality. Changes to the sequence would generally worsen the result rather than improving it.
Certain image processing steps just don't make sense if they are shifted in the pixelpipe. To mention just a few: highlight reconstruction needs to be done on raw data before demosaicing and the demosaic step needs to be performed before any input color profile can be applied.
Most of darktable's modules are designed to work within a specific color model (see Section 3.2.10, “Color management” for more details). Full flexibility would require modules to support different parallel algorithms depending on the color space they are working in – this would drastically increase complexity.
That said, the fixed sequence of modules is not likely to change in the near future.
Whenever you activate or deactivate a module or go back to a module and change the parameters, this adds an item on top of the “history stack”.
For example, when working on a raw file, the history stack on the left panel might say that you first enabled bilateral filtering, then disabled base curve, then adjusted white balance. But at any time, the processing took the raw image, adjusted white balance on it, then demosaic, then base curve (if enabled), then bilateral filtering (if enabled), as shown bottom to top on the right panel.
The history stack records your workflow in the order in which you made changes to the pipeline. It allows you to go back to an earlier stage of development if needed. The history stack represents your personal workflow and is not to be confused with the sequence in which modules are applied in the pixelpipe (see above). For more details on the history stack see Section 3.3.3, “History stack”.