According to my understanding, that’s more or less correct. But with the added complication that each scale is split into two layers (high and low frequency). So for an EQ-style UI there would have to be two curves as well. But then there’s the question of how to fit iterations and anisotropy/direction into that, and if it even makes sense in terms of how the algorithm works.
I’m trying to work out if there was really nothing worthwhile in this PR. I accept that the goal of making the module easy to understand was not achievable, but was there anything learnt that could be applied? Matching the direction of the controls to the name (or vice-versa), grouping things by scale, putting the controls in the order that they should be adjusted, are any of them worth doing on their own?
I don’t think the introduction of a novel feature is a good fix for DorS.
Your proposal seems like an amalgamation of two ideas: modules and presets. Presets are sets of stored control values. Modules are self-contained, process abstractions. While adding this to the DorS module might make the module easier to use, it would be an inelegant solution IMO, because it would introduce an entirely new concept to the software, for only a single use case.
The issue is that the module is made for mathy people who want full control over image ±diffusion mechanics. It is not made to accomplish a specific use case, but is instead designed to allow the user to solve a wide range of image issues and to accomplish a wide range of image effects. This is a fundamentally bad design for a module. Modules should accomplish a specific need well, with a clear use case. Positive and negative diffusion is, in my opinion, far too broad a use case.)
The proper fix, in my opinion, would be to create 2 new modules: Clarity, Blur. Each would specialize in providing a still-wide range of effects via the DorS engine, but would be specialized for negative and positive diffusion, respectively. DorS would still be kept obviously. Here are the control layouts for the two modules I have in mind:
this module would perform negative diffusion via the DorS engine
this module would perform positive diffusion via the DorS engine
The controls I list above in my two “idea” modules, would be mapped to combinations/ratios of underlying diffusion parameters.
well that was a bummer. I think thumper’s work was excellent and made DoS much more approachable but here we are. I suppose I’m stuck with the presets.
Also I haven’t quite understood who/what decided to not proceed any further: was it AP’s comment on github? somebody else opposed to the PR? not enough traction?
I chose to close the PR for two reasons:
So I am thinking of other possible solutions now…
You are not stuck with presets. If the name changes made an impact for you and now you know how to use the sliders, then just use them.
No, you don’t need to. Members of this forum put some effort in explaining to us everything we need to know about this module.
E.g. @s7habo:
Would an improvement to the user guide be possible to better explain the action and interaction of the sliders be a part solution instead of changing the names.
I think improved tooltips and the manual entry would be helpful, but the interactions between parameters/sliders is complex enough to make it quite difficult to explain the effect of controls with visual based terms.
I think a better solution is to create re-skins of the DorS module as seperate modules, tuned for specific use cases. These wouldn’t be simple clones with differently named controls, but would instead have new abstraction layers to consolidate the movement of underlying parameters based on a set of more user-friendly controls.
Here are some alpha versions of the modules I am thinking of. Clarity would be focused on general sharpening and dehaze for images. Blur would be focused on blur, denoising, haze, etc. Basically, they would leverage the powerful engine of DorS, while providing better controls for the specified use cases.
@thumper thank for you work!
I find it a bit hard to visualize what that UI for clarity and blur would look like. Are you able to create a mockup of the ui. Just a simple picture of how you see this…
I am working on trying to create the code actually. Right now I am battling issues with my dev environment 
That should be the first order of action, if you ask me. As I said further up, there are absolutely crucial aspects that are simply not explained well enough or at all. The language is also often needlessly technical. I’d like to think I’m not entirely stupid, and I struggle to decipher the radius span explanation.
Yes, some diagrams would be a very good idea, in my opinion.
This sounds a reasonable suggestion. The DorS module is a Swiss army knife as it stands. Thanks for your patience with trying to develop and improve the accessibility of this technically complex module.