2

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:

enter image description here

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

4
  • This sounds more like a customer support question, best addressed to the software manufacturer. – Tetsujin Dec 29 '20 at 17:31
  • Maybe you are right. Unfortunately, the software manufacturer is rude and ignores bug reports: github.com/darktable-org/darktable/issues/6072 Anyway, this sounds like a bug to me. – Luis A. Florit Dec 29 '20 at 17:41
  • Hmm… that would be about the point I'd vote with my feet ;) – Tetsujin Dec 29 '20 at 17:43
  • 1
    @Tetsujin Absolutely. As I wrote in my bug report, I was just trying to help Darktable since I actually use RawTherapee. In this case, I was trying to see if there's something interesting in the new Darktable 3.4, and found this. – Luis A. Florit Dec 29 '20 at 17:48
3

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

3
  • I understand what you say. But, as I wrote, the order in the left panel history when I open an image for the first time is determined by Darktable, not by me. I did not even touch the UI. So, Darktable applies the initial 10 modules in a different order of what it says it is optimal. But, if I understood you correctly, Darktable do not care about the order Darktable applies the first initial 10 modules or so. It reorders then when rendering. Confusing, to say the least... – Luis A. Florit Dec 29 '20 at 22:29
  • As a side effect, now I understand what exactly the compress history stack does. Thanks! – Luis A. Florit Dec 29 '20 at 22:34
  • @LuisA.Florit Your conclusions are correct. I added sections on your comments to the answer as well. – sebix Dec 30 '20 at 9:11
1

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).

2
  • Not quite. The fist elements in the history stack are introduced by Darktable, not by the user. Please see my comment to @sebix. But I understand what you mean. Thanks! – Luis A. Florit Dec 29 '20 at 22:31
  • @LuisA.Florit Not quite. The first modules on the history stack will be those applied automatically. In recent versions of Darktable the user can disable the automatic application of Darktable's defaults. In addition, the user can set preferences for automatic application of a module with a specific preset. – Bob Macaroni McStevens Dec 29 '20 at 23:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.