Improvement Suggestions

What about instead of merging , just starting over from scratch for the duplicate modules.

I have struggled over the years. Particularly if you take a break from intensive editing to come back and find all these changes! For me, watching Boris videos has completely changed my workflow. His output cannot be underestimated for understanding modules. However I do struggle with DorS and tend to leave this alone.

I donā€™t understand what you mean.

You mean, create more modules? To a large extent, these sort of issues are what the quick access panel is designed for - so that you can pull controls from multiple modules into one place.

1 Like

The Quick-Access tabā€¦ doesnā€™t it act as a ā€œbeginnerā€™s interface?ā€* I seem to remember that that is how it was for me. EG, basic sliders from Colour Balance RGB, exposure, etc. Add things that you know youā€™ll need every time, eg ā€œcrop,ā€ take away the ones that you donā€™t or seldom use.

The interface does not have to be overwhelming, because it is customisable. Cut it down to what one wants to see. Stuff can always be added back.

*edit: Oh! @elstoc just said that.

Isnā€™t that what we now have with the with the ā€œworkflow: scene-referredā€ and where we can select a filmc or sigmoid version where the other disappear and Quick Access Panel adjusts accordingly.

We could possibly remove Haze Removal ā€“ use DorS (preset) instead ā€“ and hide White Balance. The rest we need at least now and then.

What will you discard? (Yes, we all now DorS is complicated. - and I came up with an idea above - donā€™t know if it feasible at all, though,)

If there is anything ā€œwrongā€ besides this, I have for my own part wondered if some of the elements in Color Balance RGB, that are not particularly color related, could be presented in another form.

I must remark that for all the grumblings I have heard here in the forum about the UI over the years, I have not been able to register anyone trying to come up with a specific and more detailed proposal for an alternative that we really can relate to and elaborate further on. (Whatā€™s going on in github I have no knowledge about.) And without any such thing, what is said mostly act as just noise.

So the challenge is clear ā€¦

1 Like

Create Replacement modules , Does Denoise really have to have 2 different modules doing a very similar thing? Same thing for CA , white balanceā€¦ All 3 of those duplicate modules should really just be one module for each. Iā€™m well aware that you can customize the work flow to your liking, but it still feels like thereā€™s too much duplication.

As for WB I believe the WB module is needed at an early stage to do some coarse/prelimenary WB work necessary for some other modules later in the pixelpipe, but before we now do the CAT adjustments in CC, so I think you must redesign more than just a couple of modules to do anything with this.

2 Likes

First of all, everybody that has welcomed me and have send instruction videoā€™s etc, this is highly appreciated! I have seen already most of it nonetheless, very highly appreciated! And I really find it awesome that such an open source tool as Dark Table is out there!

I have read this whole discussion and - although I am new to Dark Table - I am a software developer for years. And I see a pattern in all the comments. Maybe I am completely wrong hereā€¦ but this is my freshman eyes.

It seems to me that a certain module represent a certain (or a group of) algorithm(s) and the sliders are inputs to the algorithms. (This is likely a simplification). This of course comes with a high degree of control. And I do understand that seasons users really like this. And of course as developer we like this :slight_smile: - Btw, I deducted this from the discussion on the why the crop and perspective are separate, the DorS module. And really I understand that the fun is in implementing the algorithms :slight_smile:

But from a user perspective, most users are not algorithm centric. But most are task oriented.

I want to crop the image rotate it a bit so my framing is correct. So it is maybe a bit strange that crop / perspective are not to gather (from a user perspective)

I also would like to do some dodge and burnā€¦ A user may not be into all the color of the color sciencesā€¦ that it is a maybe a bit strange that the module is called ā€˜tone equalizerā€™. When I read in the manual that the tone equalizer is like ā€˜Dodge and burn while preserving local contrast.ā€™, I really wonderedā€¦ Why is not called ā€˜Dodge and burnā€™ then (because this is a term that is so known in photography). (although of course it is not completely the same).

And I want to the increase the saturation of the colorsā€¦ So I googled on ā€˜darktable saturationā€™. My first hit was the DarkTable manual - but version 3.8 - and the module saturation seems to be gone?? So then I limited my search to 5.0 and I find the follow modules color equalizer, color balance rgb, color calibration. So which one to use?

And it might be that grumblings can be related to that differenceā€¦ and maybe it is change of mindset of the user, but on the other hand, maybe the developer can help as well?

So a couple of ideas / suggesties / remarks.

  1. I love the idea of a ā€˜simpleā€™ tab in some of the more complex modules, that offer more the idea of preset with a strength slider. That would be helpful!

  2. For the modules that discouraged by the documentation. Hide them in the ui by default (maybe this is already done). Also hide them in the result of searching for all modules. But, I a file is loaded in the Darkroom that is uses that (legacy) module of course show it. And provide some option in the settings to show that particular module. This would be my suggestion for the Velvia module for example.

  3. Ensure that (very) old documentation of darktable is marked with a warning something like: ā€˜your are looking at an older version of Darktableā€™. And maybe use a robots.txt file to discourage search engine to find those old documentation pages.

1 Like

You can even customise it and build your own.
https://darktable-org.github.io/dtdocs/en/darkroom/organization/quick-access-panel/
https://darktable-org.github.io/dtdocs/en/darkroom/organization/manage-module-layouts/

Yes, they are hidden. Or can you find e.g. basic adjustments via the search? It will still be available on any old image you used it with (you can even create a style using it, and apply it to new images, if that is what you prefer).

https://darktable-org.github.io/dtdocs/en/darkroom/processing-modules/deprecated/

Thanks, Iā€™ve seen the play raw section - I will check it out!

in difference to most commercial software darktable allows you to be your own product manager and decide yourself, which module supports your workflow.
that might be a steep learning curve - but if you need a predefined way thereā€™re plenty of raw editors following that approach.
The UI is capable enough to hide all that stuff you donā€™t need - but enabling a alternative module thats better in some edge cases ist just possible, if it exists :wink:

if the developers removes all module that some users donā€™t need at all - thereā€™s not much usable stuff remaining :wink:

2 Likes

darktable.org publishes (so far) only the manual which is in average fairly well updated. All the other stuff around is not the responsibility of those who create dt. So that request of yours you must address to the content creators/publishers.

A problem may often be that parts of media may be more or less out-dated but other parts still relevant. What can easily be done then, is for the content creators to make it quite clear which version of darktable a video etc are based on, so that users can take that into account.

darktable.org publishes a list over amendments/versions in the form of all release notes, so itā€™s possible to compare. This information might admittedly be published in a more condensed form ā€“ so perhaps somebody, you or me?, one day take up that challenge.

If someone thinks the beginner module group needs an update/refresh, then letā€™s start a PR. Most of this is a guess from the experience of the last person doing an update.

I think I agree in particular with 1 item : the Lightroom masking interface is very nice from a user perspective.

In darktable it happens very frequently that I define a mask in a module, then re-use it in 2-3 other modules to correct other aspects of the masked subjects. Masking a few different subjects will then lead to an enormous increase in number of modules. I can end up with 5 instances of color balance RGB, 4 of color equalizer, a few tone equalizer one and also exposure, etc. The more modules I have the more difficult it is to find which one does what.

In lightroom has the opposite strategy : define a mask, then you can do very different modifications on this mask (exposure, saturation, HSL, sharpening, etc). From a user perspective, this strategy if very effective because you work at the logical unit of the mask (so, the subject). Also, it unclutters a lot the UI, displacing all the mask-related modules/settings in a separate section.

In know that this would be complicated to implement in darktable so it is not a kind of ā€œfeature requestā€ or something, but more a limitation I have myself with darktable. Also, it is not a technical remark, because I know this is absolutely possible to obtain the same results with darktable: I just go with the many modules and rename them to avoid being lost.

Maybe one limitation I have with this strategy is that in some cases, a modification in an upstream module leads to a mask breaking in a downstream module. I admit that I donā€™t know if LR masks suffer the same problem (maybe LR mask are all defined from the same pipeline step rather than the output of the previous module).

2 Likes

Why? You can e.g. combine parametric masks with multiple drawn shapes, each shape having its own transparency set separately.

You can put an no-op mask in a module early in the pipeline like say exposureā€¦so add an extra exposure instance and then use that as a raster mask in subsequent modulesā€¦it should not changeā€¦its just a place holder in the pipeline with your mask ā€¦would that help???

2 Likes

I was referring to older manualā€¦ This not related to content creators. Here is the 3.8 manual (on darktable.org)

https://docs.darktable.org/usermanual/3.8/en/module-reference/processing-modules/contrast-brightness-saturation/

And here is the 3.6 manual

https://docs.darktable.org/usermanual/3.6/en/module-reference/processing-modules/contrast-brightness-saturation/

Those are all indexed by search enginesā€¦ So the first hit for me when I searched for ā€˜Darktable Saturationā€™ was: darktable 3.6 user manual - contrast brightness saturation and that module is not being displayed any more

They already reuse masks:

This would work if you want to have the same module instance applied to a different subject, but where the intensity is not the same on the different subjects.

But many times I donā€™t need different intensities but different effects (different color changes, different contrasts, etc). Also, to select a subject I often need one particular set of values for the parametric masking, but this set would not be the same for another subject, so the values canā€™t be shared between the drawn shapes.

Also I think this does not totally solve the more general ā€œusabilityā€ problem of not having an interface with per masks/subjects grouped settings.


I often, as you say, to define a mask quite early in the pipeline, and then reuse it in the latter instances. I think it is the actual best solution to do it in darktable. But still, I see this as a ā€œsuboptimal hackā€ to achieve something that darktable cannot do at the moment. I say ā€œhackā€ because it is not a technical limitation, but a more general UI/functionality limitation, from a user perspective, especially when I compare with LR usability.