Darktable 3.4 module order does not match that of pixelpipe

Question

Darktable 3.4 manual states here:

Note: The order in which processing modules are executed exactly matches the order in which the modules appear in darktable’s user interface.

I deleted the ~/.config/darktable folder, restarted darktable, clicked "3.0" in "Module order", and the order of the modules in the pixelpipe (history stack) and the UI are completely different, no mater which workflow is used. Clicking in the 'i' icon for resetting parameters made no difference.

Check here:

Am I doing something wrong, or this is a bug?

Answer 1

The order the modules appear in the history stack depends on the editing steps you make in the UI. The history is a versioning of your edits, a simple revision system. This cannot be compared and isn't equal to the pixelpipe order. It serves a completely different use. The history stack can be compared to the Document history of GIMP, or Ctrl+Z/Y for undo/redo.

You are already quoting the documentation correctly, there is just a minor misinterpretation: "order in which the modules appear in darktable’s user interface" refers to the modules in the right-hand panel, not the history stack in the left-hand panel.

In the section on the history stack there is this explanatory paragraph:

Note: The history stack is not a representation of the order in which the modules are executed but the order in which they were amended. The execution order is represented by the order of the modules in the right-hand panel.

The pixelpipe is a term which is used for the order in which the modules are processed internally for rendering the image. This is different from the edit history to avoid unintentional information loss, such as dynamic range, unnecessary (re-)conversions between color spaces etc. More information can be found in the linked darktable docs in the pixelpipe and module order section.

Addressing to your comment, darktable applies some basic modules to all images at the beginning, like demosaic, base curve, color profiles, orientation etc. Otherwise you'd start with the really raw image and that looks really ugly and is not a good start. Some steps like demosaic are even necessary to display the image at all. So, darktable is not prejudiced, it is just transparent to the user.

Compressing the history stack is only possible because the order of the editing steps in the history stack is not relevant, only the internal order is. Information on this can be found on the (other) section in the docs on the history stack

Answer 2

The pixel pipeline is the order in which Darktable applies transforms to the data when **rendering.**The order matters because some transforms operate exclusively on a single pixel based exclusively on the current value of that pixel and other transforms change a pixel’s value based upon the values of other pixels and these changes may involve multiple iterations in a single operation.

While by default Darktable applies transforms in a particular order when rendering, recent versions allow users to instruct Darktable to apply transforms in a different order (this is generally discouraged because results tend to be less predictable).

As other answers point out, the history stack reflects the order by which the user chose transforms to apply. It is similar to an undo history (but not the same because it contains less detail about the sequence of settings adjustments).

Some modules may be applied automatically by Darktable. The user can control this behavior and disable modules Darktable applies by default. Automatically applied modules will appear at the bottom of the history stack (they are applied earliest).