I understand that my confusion regarding the various Darktable modules stems from backward compatibility. Even an old XMP file for an image should be recognised and processed when the image is displayed in Darktable again.
Would it make sense to add a label next to the names of the legacy modules? This label could say “Legacy”. I imagine this option could be enabled or disabled in Darktable’s module search settings. That would make things clearer, wouldn’t you agree?
Just an idea. However, I don’t want to imagine the discussions that would take place before a module is labelled ‘Legacy’.
2 Likes
I think the delivered presets for the module groups in the darkroom should be sufficient to show the recommended modules. This has the advantage that for a beginner the modules are not even visible, while an advanced user can still use and add them to a custom module group.
3 Likes
It doesn’t hurt to ask your question, but I am unsure what advantage would be gained. If I search for the ‘legacy’ module defringe I get a bold warning not to use this module. What more would I need?
I’m not sure what “legacy” means in this context but I suspect it might mean “old” and not necessarily deprecated.
The amount of deprecated modules is quite small, but I can see something like base curve being considered “legacy” to some people.
Until recently I had a case use for base curve using the fusion module with strong backlit images. Now AgX seems to handle this scenario well and maybe base curve is becoming legacy to me.
Is the OP’s question really one of confusion about which modules are recommended to use and which are not? That would get many interesting debates started.
1 Like
Yeah I’m not sure that’s such an easy question to answer.
The module group workflow presets are a good starting point IMO, even if they have modules that potentially duplicate functionality.
1 Like
Just working out which tone mapper or mappers to include might start WWIII
1 Like
As darktable allows modules to be hidden from view without deprecating them, there’s no real reason to mark any module as “legacy”.
“Deprecated” is different: those modules have been officially retired and shouldn’t be used for new edit. You also have to muck around to get them available for new edits… Looking at the list of modules in the manual, all deprecated ones seem to have flaws, and much better alternatives.
Worse, it would start a religious war…
2 Likes
The ‘real’ reason is that you can use filters when searching for modules to sort out the ‘legacy’ ones. This means you won’t waste time fiddling with outdated tools and can focus on the latest modules.
Yes, like linux kernel debates…
As far as I understand it, even the order in which the modules are applied can be critical for the result, right? AgX f.e. seems to have the potential to inherit the base curve module as the “recommended standard”. I think it would be logical to mark the base curve model as inherited: legacy.
How would such a selection be made? By vote, perhaps. I am actually familiar with this from the Linux world. There are standard packages, extra packages, archived packages and always packages flagged as legacy. I am also familiar with heated and emotional debates from this world. In the end, however, every user can decide which package they want or need to use.
[Quote from rvietor, post 8, topic 54625]
As Darktable allows modules to be hidden without rendering them obsolete, there is no reason to mark any module as ‘legacy’.
[/quote]
How do you know when it is ‘advisable’ to hide a module? When does the realisation dawn that it is generally better to use AgX than the Basic Curve module, for example? And if that should happen, what would be the argument against making this clear?
What do you mean by inheritance? A replacement, like the deprecated defringe module is replaced by chromatic aberration? base curve is notdeprecated, it is simply the tone mapper of the legacy workflow.
1 Like
Tl;dr: marking a module “legacy” doesn’t make much sense within darktable, and uses up scarce screen space
(No “Basic Curve” module in dt, I assume you mean base curve)
If you want to know when I know if it’s advisable to hide a module: when I never use it in my edits…
If you want to know when it’s advisable for for developers to hide a module:
they dont. What they do is they create standard module layouts adapted to a workflow, with modules not fitting or rarely used excluded from that layout. (There is a default layout marked “All”: just right-click on the hamburger menu just below the histogram).
Also, AgX won’t be a replacement for base curve: they fit in different workflows, and currently, the default for the scene-referred workflow is “sigmoid”. Before that one will be replaced, we’ll be a year further along (at least): AgX isn’t even in a “release” yet.
I think you might have to learn about the different workflows and their characteristics, you cannot just replace a module in one workflow with a seemingly similar one from another workflow…
Also, your comparison with a Linux system is flawed: all modules are always installed in darktable, and “legacy” means something different from what it means for a package manager (e.g. you can’t have outdated/unmaintained libraries that are needed for a few relevant programs).
1 Like
With respect I presume you are fairly new to the Darktable workflow. I would recommend reading the manual, watching some of the video tutorials, and participating in the playraw category of this forum. You will learn that there is more than one way do things by design in darktable. I for one have moved on from using base curve as my tone mapping in my early days to learning about filmic and using that instead. Then Sigmoid was offered and gave me great results straight out of the box, and now AgX has been ported to DT and I have embraced that latest tone mapper. It doesn’t make any of the previous tone mappers invalid, old school, out of date or legacy. There are just different options for users to decide upon. DT is about choice and alternatives rather than a single ‘correct’ way of doing things.
Yes the order is important and you should not change the order of modules unless you fully understand when and why this should be done. The modules have carefully been placed in specific order by the developers of DT. There are limited times when it is advisable to reposition modules but that is for experienced users. But generally speaking if a module is found before the tone mapper it probably shouldn’t be placed after the tone mapper and vice a versa.
Good luck with DT. It is a great program and there is a very supportive community here. But in answer to your question I feel labelling modules as legacy is not a good idea.
56 posts were split to a new topic: Perspectives on Workflow Advice for Newcomers
Thread split in response to user feedback that the discussion shifted toward darktable.info’s educational philosophy and workflow guidance, separate from the original topic.
5 Likes