Ya and this is where talking about what should or could happen withouth a full grip on the code and what those sort of suggestions might mean is a handicap…and I am handicapped
I do peek at the code from time to time but often I get lost trying to follow how it all comes together outside of the individual modules…
On the surface when you don’t have that understanding you might think okay DT has a way to create custom groups and track that and within those groups you could have exposure in say all of them if you decided to. So then I think when you activate a module the code would just activate exposure or whatever and it will run where it is supposed to. On the surface that action would be the same for any group you are just triggering activation or a change to the editing of module. When the module runs its hard coded where to go and so if it can be in multiple groups then why also would the organizational order in any group really matter as the pipeline postion is controlled by the module type and the pipeline code one would think…but thats where the need to understand the code comes in… and I don’t yet and likely may never get there…
But that’s just it: that pipeline order is not hard-coded:t you can change the position of a module in the pipe-line (not that that’s useful for all modules…).
And the right side bar in the darkroom where you work with the modules is the place where you change the processing order. That’s not a matter of understanding code, it’s what is described in the manual.
Some notions of coding can come in handy when you want to get an idea what a suggestion might imply in terms of changing the implementation.
Could you imagine the amount of support issues if you had 2 ways to rearrange the pipeline display and one affected processing and one didn’t? We’d be faced with constant “Why did this…?” or “Why didn’t this…?”
Well, if I start processing a new image, the history stack has 12 modules. Six of those (marked with a “◉”) cannot be switched off, and can be ignored in most situations.
That leaves six, half of which can also be ignored most of the time.
The only ones of the start-up stack I use for initial processing are “color calibration”, “exposure”. and “filmic” (or “sigmoid”). And those can be used very well in pipeline order: start at the lowest and work your way up.
Add “color calibration RGB” for a bit of extra chroma or saturation (one of the presets), and the initial processing is done. Any further editing depends on the image, and its intended use.
So you can very well set up the modules to have “color calibration”, “exposure”. “sigmoid”, and “color calibration RGB” in one group, then put other useful modules in other groups.
(Usually I want to add a few more, but the order there is not critical. And some are just switched on and then forgotten: “denoise (profiled)”, “lens correction” should work correctly out of the box)
I believe denoise works on the entire image regardless if you crop or not, so it doesn’t really matter in a technical sense if you do it at the beginning or end. Several other modules work this way as well, such as the retouch module. In an artistic sense though doing denoise early gives a better base to work with in other modules like diffuse or sharpen and local contrast.
I agree with @priort that it would be useful to have an actual user workflow order, though I can also just live with what exists now. I think for most people the workflow related to the pipeline order kind of works from the outside in, and that’s where some friction is. Most people probably start with “big picture” changes: denoise, lens correction, cropping, maybe exposure and color calibration. Then jump all the way up to the tone mapper, sigmoid or filmic. Then back to the middle for the real details with color balance rgb, diffuse or sharpen, etc. There’s still a handful of display-referred modules that are popular, and those break the order even more.
We already have the quick access panel which works differently than the other panels, so in a general sense it seems possible to have a totally different view. This “workflow order” panel could disable dragging and changing the order like the quick access panel does. Allowing and dealing with multiple instances could be tricky though.
You don’t understand what I mean. Let’s assume I have a very dark sky in the night, which is very noisy and then there are light buildings. If I remove the sky totally and keep the buidlings only, denoising woult be different.
Anyway, if this is not possible what i want, I have to accept it.
Why would it be different?
If the building is your main subject, then you can set denoise parameters so it gives best results for the building and simply ignore the image regions you‘ll crop later. It doesn’t matter if cropped stuff looks strange
If you feel, you get better results when denoising later in the pipe, then you’re free to move the module.
But darktable defaults are intended to prohibit users of shooting in their feet.
Ya I think we are going in circles a bit…I likely do 90 % of my work in the active modules tab.There is where I re-arrange and add extra instances when needed and because the instance is already there… The workflow tabs would be for doing things as a set of steps from the start and for grabbing modules that I had not yet added from a list in a custom order of my choosing and not dictated by the pipeline….in practice I am not sure how much I would use it anyway…I would and do use a combination of auto-applied presets and the search box…if I want a module I don’t currently have in the active tab I just grab it there …. So I basically work almost exclusively in the active modules tab…
In anycase I am fine with how things work and wouldn’t really feel any need to ask anyone to do any work to change it…. others might??
)