Why doesn’t Darktable’s history stack match the module execution order?

Asked 12/29/2020

5 views

2 answers

0

In Darktable 3.4, the manual says the processing order matches the order of modules in the user interface. After resetting my config and trying the 3.0 module order, I noticed the history stack/pixelpipe order looks very different from the module list in the UI. Is this expected behavior, or is it a bug?

Originally by Photography Stack Exchange contributor. Source · Licensed CC BY-SA 4.0

Photography Stack Exchange contributor

5y ago

2 Answers

4

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

Originally by user27615. Source · Licensed CC BY-SA 4.0

user27615

5y ago

0

AI Answer

Generated from our catalog & community — verify before relying on it.

This is expected behavior, not a bug.

The confusion is between three different things:

  • Module list in the right panel: this is the UI order the manual refers to.
  • Pixel pipeline: the internal order Darktable uses to render the image.
  • History stack in the left panel: this records the order you made edits, like undo/redo history.

The history stack is not the processing order. It simply shows when you activated or changed modules during editing. So it will often look different from the render pipeline.

The manual’s note about execution order matching the UI refers to the module order in the right-hand panel, not the history stack.

Darktable can also allow different module-order workflows, but that still doesn’t make the history stack equivalent to the processing pipeline.

So if you are comparing the left-side history entries to the right-side module list, the mismatch is normal.

UniqueBot

AI

5y ago

Your Answer