This is possible, but they would need to duplicate diffuse or sharpens code. Which might be acceptable to the devs but I have no idea.
I donāt think it would mean duplicate code - rather IOPs calling/using other IOPs. No idea if this would be possible architecture-wise in darktable.
Another thought: the DoS settings are not just gradually changed but completely different (for example) for the fast/normal/fine presets of local contrast. So it seems questionable to me, if the mathematics of the underlying PDEs can be easily consolidated in a few parameters for a specific function like local contrast.
But: If it canāt, how can we expect the user to make use of the DoS sliders purposefully, i.e. not just try and error?
For a technical perspectiveā¦ if code needs to be duplicated, then there is something wrong in the architecture. Code duplication is never a good solution.
1 Like
Absolutely. I am not advocating that at all, see my other comment.
This is something I have been thinking about, and I donāt think adding more modules - however implemented - is a good idea. My proposal would be to add a recipes tab. It would then have a menu to select a given recipe, with the default being none.
A recipe defines the default values and a number of sliders, each of which then controls the main section according to a formula. If the main section is adjusted, the recipe reverts to none. And other than using those bundled, the user could add their own by putting a simple text file in the DT data folder.
If you read his rants, youāll see that he cares a lot about UI/UX. But he is, arguably, not very good at it. He also has a bit of a blind spot when it comes to realising how much he really knows compared to most others and often has a hard time looking past the math. This is very evident in the DorS documentation, which probably makes perfect sense to him, but lacks a lot of details.
Iām actually not sure that the UI is the main hindrance, but rather the documentation, which is woefully inadequate in places. In particular, the wavelet separation and what the different orders map to need to be explained much better.
6 Likes
Or both? The module has 15 sliders, most of which all interact with each other, meaning endless combinations. I think thatās simply too many for a sharpening/diffusion tool. But even if we argue it isnāt too many, the lack of visualization really hinders the module. You canāt see what details you are working on. There is no mask view, details view, graph or anything to help.
One feature I always liked about Lightroom is that you can hold down Alt with some sliders to see a visualization of what the slider is affecting. In Darktable, the mask view icon provides similar functionality when refining masks, and some modules provide their own visualization mask views. Diffuse or Sharpen doesnāt have one but badly needs one in my opinion.
4 Likes
Can I add another perspective to this discussion?
I see Diffuse or Sharpen (an odd name as references to the module functionality refer to Blur rather than Diffusion - why not Blur or Sharpen? - anyway I digress).
The module obviously has a lot of flexibility as evidenced by the number of presets which have been constructed for it. Otherwise I see the module as an engine which supports those presets generally and can be used standalone for experienced/understanding users.
To use an analogy, consider it like an audio graphic equaliser which produces use case-specific results. The presets provide a guiding start point from where tweaks can be applied.
It doesnāt have visualisation, true, but with its time-consuming processing nature waiting for a final visualisation would be like waiting for a final render and would you want to display a visualisation at completion of each iteration? That might be confusing in itself.
Maybe retain the module as it is with refinement of the presets and document them with clues as to what the sliders represent for each one.
I really feel that DoS isnāt inherently broken. Yes, it offers technically advanced functionality but the presets mitigate that for many use cases but I think that attempting to simplify or relabel its operation would be detrimental to the ethos of the module itself.
Obviously, just my two cents but I think worth saying.
ATB,
Neil
6 Likes
While not an everyday user mode, you can blend the module in difference mode and see what is being impacted or a rough approximation for some testing and experimentingā¦
Yes, Iāve used that method a lot over the years, but itās really not a great solution. Small changes are barely visible and the way differences are shown are not clear because so much of the original image is obscured.
Then youāre thinking about it the wrong way, I would say. Due to how the algorithm works, itās simply not possible to reduce the apparent complexity without also reducing the functionality. In fact, opaque terminology and poor documentation notwithstanding, the design is very elegant and minimal, in my opinion. And @neildarlowās characterisation of it as an engine is also very apt. So I would really advice anyone hoping for the main interface to be a few ādo what I wantā sliders, to abandon that quest, because you will be eternally frustrated.
The blur is done through (simulated) diffusion, so that wouldnāt make any more sense.
I like that analogy.
@thumper Maybe if you ask nicely, AP can overcome his animosity towards darktable long enough for you to work together on improving the documentation for everyone, including Anselās users.
2 Likes
I donāt think Iām thinking about it the wrong way. Iām simply approaching it from a usability perspective, and I donāt think 15 interoperable sliders is very user-friendly. Contrast Equalizer offers similar functionality and approaches it in a completely different way. While certainly not perfect, it substitutes sliders for nodes, axes and effect radii, which in many ways is more elegant. Itās still very complex and offers a lot of functionality, but you only need to do a little scroll of your mouse wheel and drag a node to replicate what would require about 8 sliders in DorS.
While that is always a possibility, I donāt think AP needs me to make the necessary improvements, and from what I know, he believes the only way forward with improving DorS is via AI integration (I use the term āAIā in the loose, modern, no-foundational definition sense 
)
I wonder, what would a good visualization look like? Could it be like the contrast EQ, with a curve that spans a frequency scale? Or perhaps something like a Siemens star that is selectively diffused or sharpened?
The issue I think (if I understand the code and I am not a programmer but I have looked at several AI summaries prompting it for various explanations) is that the module ie DorS currently lets you define the equivalent of one axis location and span to select a range of wavelet scales to process with the wavelet scale radius closest to the central radius getting a weight of 1 and then it fades off to the border of the span. In the contrast eq you can drag multiple spots/nodes across the wavelet scale and in opposite directions if you choose. I think this is why there is just a set of sliders and not a curve in DorS.
But as I said I am not a programmer and I may be misunderstanding the how and why of things and how they workā¦
Iām sorry to say, I wonāt read AI generated slop.
5 Likes
No one ever claimed it was. Least of all AP. The question is if itās actually possible to improve it. Iām now more sure than ever that it isnāt.
I think I just managed to finally get the last pieces to snap in place in my understanding of how it works. Specifically what the orders are and how they map to the wavelet scales. I will need to think it over and rewatch some videos (if anyone has a copy of APās, please let me know), but if my intuition is correct, then it simply canāt work with an EQ-style UI.
2 Likes
I think one issue is that the CE is a single pass calculationā¦the DorS might have 30 iterationsā¦Moving the curve would just be a slog in its current formā¦
1 Like
Two things I read in the recent posts are very interesting: someone said DorS is an engine, not a module. Iāve been thinking of it as a library. Next, the chatbot suggested adding replacing controls with āmacrosā. This is of course not possible, but it leads to my next point:
I wonder if some of the presets could become modules that would invoke the DorS code in the background. For example, imagine a sharpen UI with a few settings that control effect size (the scale to be deblurred), the degree of edge attenuation, strength (local contrast at a micro scale), and noise protection. Lastly, there would be a ācpu timeā slider. The UI would not show the āspeedā or āiterationā controls, but increasing the cpu time would increase iterations and decrease speed to try keeping the magnitude of the effect constant, while running more slowly with fewer artifacts. Similarly, the noise protection slider would probably affect multiple speed and anisotropy sliders.
In short, DorS is a mathematical function with exposed parameters. Iām interested in whether it could be used (unchanged) to implement a Physics Sharpen module that drives those parameters while exposing a friendly UI.
I feel this was a worthwhile thread discussing a very challenging module. The module is challenging because it is powerful. Maybe āintuitiveā names would be desirable, but at the same time that may not be possible. Maybe one day AP will revisit the naming of the sliders and have appropriate suggestions. For me the presets need to be my go to because I struggle with the deep concepts of this module.