I’ve always just poked around with darktable but decided, with the launch of v3 to learn to use it properly, so I’ve been reading some docs and watching some youTube videos.
On one of them there was a reference to default modules which you can’t switch off, and some modules being in the wrong place. 1) What is the correct order of the modules. Is there a best practice to apply here? 2) How do I know where the non-default modules go? Is there an option to reset to a sensible default, or a warning if I put them in an order which is sub-optimal? Lens correction is optional but would appear to make more sense applied early on, perhaps. Rotate/crop might as well go at the end - that is to say, the top of the list as it appears on the screen. (Is there a reason why the list of modules appears in reverse order to how it’s processed?).
…as long as you imported them into darktable 3.0 or later. If the images were imported in an earlier version of darktable, they will retain the previous order of the pixelpipe. Discard history to reset to the current recommended order, though this will lose any previous work.
Just to set your mind at ease: At the moment, and what I can see about the shortly upcoming release, this reordering is a per image thing. No need to be concerned about messing up your general module order. But do as paperdigits suggest: Get comfortable with dt first.
My issue is not with comfort - I’ve been using dt for years - it’s that I’ve been fiddling around and they’re already in the wrong order. But if the order is per image, then I can discover what the default order is easily enough by deleting a photo’s related .xmp file and seeing which modules are being applied and in which order.
My other question still stands though. I noticed that “filmic rgb” wasn’t in the list of all modules (which is what I heard described on a video as what you see if you toggle the top left icon above the modules), so I searched for it by name and turned it on when it appeared. Has that appeared in the optimal point in the pipeline?
What’s the “shortly upcoming release”, btw? I’m on v3. Is there something else around the corner?
Default order is the recommended one for most of your images. As we said on the article explained new features of darktable 3.0, article I suggest to all to read as it explains lot of things about darktable 3.0 :
The image processing chain (pipeline) has been thoroughly reviewed and optimized. It is now possible to re-order the modules via a Shift+Ctrl+Drag&Drop of these modules in the darkroom or via the instance menu and the up/down options.
WARNING: *It is VERY IMPORTANT TO UNDERSTAND that moving the modules changes the order in which they are processed, so it affects the rendering of the current image. The default order is safe and optimized for the majority of uses. It is recommended to move a module only if you know what you are doing and what effect it will have on your image. Under no circumstances should this change be used to “classify” these modules.
That only shows the used modules (the show only active modules button) or all if you turn it off.
Hmm. I toggled that button and it went between two states, but filmic rgb was not in either list until I searched for it by name and turned it on, at which point it appeared in both lists.
Everything is in the correct order (assuming RAW files here) and there is no need to fiddle with the order (exceptions not withstanding).
Is it possible to make reordered modules a default? I can point out at least one error in current module order: retouch module shall go before transformations. With current order if you try to retouch an image that was rotated (to align a horizon, for instance) the retouched spots appear in the wrong position. Moving the module solves the issue. But it’s very annoying to move it for each image…
Actually I left a comment about it in an open issue with no result. Also few my other issues were left totally unattended, some of them were automatically closed due to no activity. The bugs are still there…
PS: as a side note, I’ve been using DT since v0.6 or so. V3.0 is the buggiest version ever, a lot of things that worked just fine before are broken. Yet a lot of bug reports are orphans.
Oh, I’m aware of it and take it into consideration. As well as that it’s FOSS and it’s free (as a beer))). However, I may say that bug situation went out of control (or getting closer and closer). Even since v3.0 I see breakages and regressions, and expect that a “bugfix” 3.0.1 release will introduce more bugs that would be fixed. Which scares me a bit, because all my workflow is based on DT and I see no reasonable alternative to it.
I ended up moving on to master to get a couple of bug fixes I couldn’t live without. Unfortunately, it was only after doing a bunch of edits that I realised there’s no way back to a ‘stable’ 3.0.x version because there are changes in master that are now part of my edit history, and that probably won’t get into a stable version until 3.2 (I think the curved gradient shape was the biggie for me).
In terms of 3.0.1 I get the impression that the developers are fairly careful about what goes into bug fix releases, so I think the chances are that it will be in a better state than 3.0.0.
Yeah, I was trapped the same way. I used git versions of DT before, and the experience was all positive… until now. I effectively lost most of my early edits due to messed database after going 3.0.
I hope for this. Yet I filed a handful of bug reports and haven’t seen any progress on them (maybe they’ll be silently fixed). Some of them are quite annoying, like segfaults, or mess with the database, or using CPU when OpenCL is available which slows down the things like x3 (the last one was introduced after 3.0, BTW). At the moment using DT is not fun anymore, and I regret it.
I was more talking about the lower likelihood of introducing new bugs in 3.0.1.
Investigating and fixing bugs is often a very time consuming and not very exciting thing to do. Bugs do get fixed but with people contributing their own time to development, new features sometimes understandably get more attention.
TBH I love hunting bugs (and maybe fixing them too)! If I see some sensible bug and I have time, I try to help by at least investigating and narrowing down root cause or trying to replicate.
Huh, now that I think of it, fur “feature request” might’ve been misunderstood by @Pascal_Obry since what you describe isn’t really a feature request but it’s a bug in at least roi calculation. Changing order of those 2 modules uncovered it. Judging from the description I’d move the affected modules just to avoid bugs and in the mean time fix invalid roi calculation.