Yes, seems like we have derailed a bit - with very interesting discussions, however 
So maybe it’s a good to summarize the findings and channel towards next steps.
First, I try to cluster the proposed designs into three clusters with pros and cons:
1. Keep initial Design
Benefits:
- As simple to use as it’ll get
- Does one thing well without redundancy
- Relatively easy to implement and maintain
- Later upgrades that add additional, independently calculated detail layers without changing the core logic can be added later with easy handling of backward compatibility
Cons:
- Multiple instances required for multiple detail scales
- Multiple instances are not equivalent to multiple scales within one instance because later instances process already altered image
2. Add multiple details scales relative to main scale
Masking settings refer to “main” detail scale. Only added sliders are coarser / finer scale, which use a scale that is defined in relation to main scale (e.g. 1/4)
Benefits:
- Still relatively simple as there is only one slider per detail scale added and it can be labelled in an understandable way
- Direct control over multiple scales
Cons:
- Detail scales depend on main detail scale → changing main detail scale changes everything
- fine independent adjustment of scale still requires multiple modules due to Fixed ratio between detail scales
- Effect of Parameters like edge refinement is dependent on detail scale → lack of individual control may again require multiple instances
- Increased computational cost
This version seems charming at first, but it feels like a half-baked solution to me because it is adding some multi-scale functionality, but then breaks with the concept of explicit control of detail scales and is hence only going half-way to a consequent multi-scale generalization of the module.
3. Add multiple independent details scales with individual control sliders per scale
Basically like this:
Benefits:
- Direct control over multiple scales, also regarding their scale and edge refinement
- Best substitute for multiple instances, as the scales can be controlled independently and precisely
- Each scale’s mask can be visualized independently
- For a user who understood the basic concept of the module, it should be intuitive that they can control different scales independently, whereas in solution 2, it may not be clear how the one refinement and feature scale slider interacts with fine, coarse etc. detail boost.
Cons:
- Significant increase of control parameters
- Increased computational cost
if the module should get multi-scale functionality, I believe that this one is the most suitable approach because it avoids entanglement of different parameters’ effects, is consistent with the original module logic and may still have a comprehensible UI.
4. Equalizer-Like
This would mean we have either a set of fixed scales (like tone equalizer) or freely placeable nodes (like in ART).
Benefits:
- Direct graphical control
- compact way to visualize settings for multiple scales
Cons:
- First and foremost, the concept of an equalizer with a continuous domain is not applicable to this module. With the scale parameter, we pick a single scale value. There is no smooth transition between different scales happening. So the visualization with a smooth curve between the nodes would be misleading
- A complete redesign would be required (which I would not like to do)
- Some disadvantages of option 2 apply also here. In particular, we would also like to control edge preservation or other parameters for each scale. Also, visualization of the mask for each node is not straight forward.
- Increased computational cost
- No key bindings like for sliders
Whereas I like equalizer-like designs in the tone eq and color zones, I would not like it in the local contrast rgb for the previous reasons.
Next Steps
I like the list:
I still very much tend to keep the module simple with only one scale for now. This mainly has the following reasons:
- From my experience, it is good to start small and simple with new functionality to keep it maintainable and flexible while gathering experience from users after a release. The chance is high that new learnings and ideas will come up. If the module is already complex, it will be hard to adapt and a pain to provide backward compatibility. If the module is simpler, it is much easier to adapt and develop the functionality in an evidence-driven fashion.
- According to my understanding (please correct me if I’m wrong dear DT devs @Pascal_Obry ), a later expansion (like option 3) of the module to multiple scales will be straight forward as the scales share the same basic controls (like feature extractor) and are independent in their individual parameters. The migration path from single-scale parameters would just involve initializing defaults for the newly added scales with detail boost value 1 (=no effect).
- To be honest, my current situation does not allow me to develop a complex module with the same effort and dedication as e.g. @kofa did with AGX. So I’d like to keep it simple and maintaineable at first!
I believe it’s relatively probable that the module will be developed towards multi-scale in the future and I am absolutely fine with that if it benefits the user and aligns well with DT’s principles.
Personally, I’d like to use multiple scales in one module in my workflow, too.
In this case, I’d prefer option 3 currently.
If I find the time, I’ll maybe also try out an implementation of option 3 to learn how this would behave. If anyone likes to do this before me, feel invited 
But an initial pull request from my side would most probably be option 1 - nevertheless it is still valuable to explore options and preferences for later changes!
Luminance Estimator and Feature Extractor
Quite a lot, yes…
I guess it can be simplified.
For the feature extractors, I’d guess that the averaged ones are not needed for local contrast.
The two options would then be eigf and guided filter.
Those really behave differently, so that it might be good to keep the selector.
For the luminance estimator, I’m not 100% sure yet.
It seems to me like some situation where in 95% of cases one will do and there is no real difference between most estimators. But in some cases, you may really need it?
So maybe a little challenge
Who can find an image where different Luminance estimators make a real difference that cannot be reproduced by adjustments of other sliders?
Also here, starting simple and expanding in later versions is much easier than removing a parameter, because that is a pain in parameter migration of existing edits.
So I’d also propose to start small and maybe even remove the luminance estimator selection.