Project

General

Profile

Bug #12524

Wrong order of operations in styles

Added by Francisco Cribari 9 months ago. Updated 8 months ago.

Status:
Closed: invalid
Priority:
Low
Assignee:
Category:
General
Target version:
Start date:
01/04/2019
Due date:
% Done:

0%

Estimated time:
Affected Version:
git stable branch
System:
unknown
bitness:
64-bit
hardware architecture:
amd64/x86

Description

I run Darktable 2.6.0 on Manjaro KDE. I noticed a problem with this DT version: when I create a style and apply it to a different image the order of the operations in reversed (in the history stack). Suppose, e.g., that I open image A and do only two operations (in that order): local contrast and tone curve. Suppose now that I create a style with these two operations. When I apply the style to image B and look at the history stack I notice that tone curve appears first and local contrast is listed after local contrast, that is, the operations appear in the history stack in the reverse order they were listed in the original image. This did not happen in versions prior 2.6.0.

History

#1 Updated by Aurélien PIERRE 9 months ago

The history order is more or less anecdotal, since it does not change the filter order in the pipe.

What is more important is the order of multiple instances of the same modules when you use them in styles, because that changes the actual order of operations. But that was broken already in dt 2.4, I had denoising presets with stacks of denoiseprofile instances that were completely messed up between the preset source and the preset application.

#2 Updated by Francisco Cribari 9 months ago

1) When the denoise operations show up first in the history stack (instead of being the final operations) the processing that comes later (mask drawings etc.) becomes slower. Am I wrong? 2) I believe it's important to preserve the order of the operations saved to a style because they may affect parametric masks in later operations. 3) If anything, a user may wish to go backwards in the list of operations in the history stack and he/she may want to see each operation undone in the correct order (even if in the pipeline the order of processing is determined internally by DT).

In short, I believe it's a bug.

Aurélien PIERRE wrote:

The history order is more or less anecdotal, since it does not change the filter order in the pipe.

What is more important is the order of multiple instances of the same modules when you use them in styles, because that changes the actual order of operations. But that was broken already in dt 2.4, I had denoising presets with stacks of denoiseprofile instances that were completely messed up between the preset source and the preset application.

#3 Updated by Pascal Obry 9 months ago

  • Assignee set to Pascal Obry
  • Status changed from New to Closed: invalid

No, Aurélien is correct. The order in the history window has nothing to do with the actual order of the pixelpipe. The denoise module has a static place in the pipe and is always processed at the same time. No bug around, at least not one that is related to the way style is applied.

#4 Updated by Aurélien PIERRE 9 months ago

Run darktable -d perf to see the actual order of application in the pipe.

The order in the GUI is something else entirely.

#5 Updated by Francisco Cribari 8 months ago

Aurélien PIERRE wrote:

Run darktable -d perf to see the actual order of application in the pipe.

The order in the GUI is something else entirely.

Thank you, Aurélien and Pascal. You are probably correct in pointing out that it is not a bug. It is not a bug in the sense that there is no impact on the pixelpipe. However, when editing an image the user has a given workflow. In my case: hot pixels, lens correction, monochrome, shadows and highlights, colors zones, local contrast, tone curve, equalizer, grain, denoise. Like many other users, I like to go up and down in the history stack to check the impact of each change made to the image. Sometimes I take a snapshot to compare the before and after of two or three changes to the image. It seems to me that it is natural that when we create a style and apply it to other images the order of operations in the history stack would be kept the same, even if it has no impact on the pixelpipe. That always happened until version 2.6.0. Now the operations show up in the history stack in the inverse order in which they were applied when the style was created. In my case: denoising, grain, equalizer, tone, curve, local contrast, color zones, shadows and highlights, monochrome, lens correction, hot pixels. Even if the pixelpipe is the same regardless of how the operations show up in the history stack,, it makes it harder to the user that has a well established workflow to go up and down the history stack and analyze the consecutive changes made to the image.

In short, it would be beneficial to me and perhaps to other users if the order of operations in the history stack was kept when a style is created and applied to other images, as it was the case prior to version 2.6.0.

Thank you for giving some thought to my considerations, regardless of whether you agree with them. And apologies for my imprecise language at the outset.

Also available in: Atom PDF

Go to top