> Does the history stack reflect the order in which modules are > processed in the pipeline?
Le 02/10/2014 09:19, jeremy rosen a écrit : > IIRC the history stack reflects the history i.e the order in which you > did things on the image > > it's the order of the modules on the right container that reflect the > order of the pipe (bottom to top) Exactly. For example, the history stack on the left might say that you first enabled bilateral filtering, then disabled base curve, then adjusted white balance. But at any time, the image processing first did white balance, then base curve (if enabled), then bilateral filtering (if enabled). Bottom to top on the right panel. This strict order may not be obvious at first. There are some reasons easy to summarize, and many others not easy. Examples of "easy" reasons: * Some modules don't operate on same data, so they couldn't be swapped. * Some orders would make debatable sense, for example apply white balance after non-linear transformations like base curve or tone curve. Or remove hot pixels after demosaicing. The semantic of the data changes along the pipeline. Changing the order would break modules in various way, from downright unapplicable to subtle inaccuracies that people may report as bugs: * Before demosaic, image data is (generally) one-plane Bayer-encoded, while after that it's three-plane. * Before exposure, image data is in a scale that allows precise sensor-dependent processing, like "denoise (profiled)", no longer possible after that. * "Input Color Profile" further brings the data to some "generic" (linear Lab) representation, independent of camera details, allowing to apply generic filters with generic parameters (that's important for shareable, reusable styles). In some areas (all over and especially after "input color profile"), the order may be more debatable, I don't know the details. Inside the source code there is a script that generates a dependency graph with (no kidding) probably over one or two hundred of inter-modules constraints hinting why this order is necessary. Cheers, -- Stéphane Gourichon ------------------------------------------------------------------------------ Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk _______________________________________________ Darktable-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/darktable-users
