I can see two ways of implementing it. As a single slider that defines the mid-tones zone in EV around mid-grey (as set in exposure), or a slider for each that set the distance from mid-grey.
Simply above it below middle grey of the low pass version of the image. Its however a slope adjustment (in log space so a changing the power) so the effect is zero at middle grej and then gradually increases. Note the special case of setting highlights to â-xâ and shadows to "+x) this is straight slope equal to what a âcontrastâ adjustment would give you. There is a small segment of smoothing that is able to affect the middle grey point if you apply large unequal changes. Like only pull down the highlights but not changing the shadows.
Could you share a example edit where you feel like a strictly flat region would be beneficial?
Strange, maybe some special combination of settings? Mind sharing more details? Like a screenshot or similar.
On the topic of edge protection or sensitivity.
How about we rather talk about halos? Because that is what we actually control with that slider. Less protection means more halos more reject halos.
Halo protection?
Halo sensitivity?
Halo rejection?
Even âedge halosâ might be fair game.
My pick (after edge sensitivity
).
I know adding more vertical space in a module isnât normally popular. But as I understand it, the base detail level slider determines on the one hand the total band that the three clarity, texture and detail bands divides between them, and on the other hand the remaining band that shadows and highlights work on.
Could it then be an idea to add a new line under the base detail level slider with these three mask icons with corresponding labels in a row (and possibly add a mask icon also for shadow and highlights?) ? That could perhaps better explain the connection that base detail has with the rest of the controls, and eliminate the possible confusion you point to.
For me, (a non-native English speaker who have little understanding of the maths behind), âStructureâ gives association to some larger, underlying thing that I do not understand where come into the picture - (I would rather think it has something to do with composition âŠ). âTextureâ I can understand and find descriptive, and I can relate it to the local contrast aspect.
Did you mean âTextureâ?
Squash Halos ?
That sounds a bit more active, and also implies you donât need to touch it if you havenât got any halos.
I donât want to protect halos: I want to do away with them. ![]()
Halo prevention, halo suppression?
One day halos will be on the winning side and they will present you the bill!
Halo oppression?
Letâs be kind to halos:
Halo control?
Halo: Control Evolved?
Halo killer
Halo Killer
Quâest-ce que câest? *
@Soupy has officially won. We now have to call it that. Or Edge Sensitivity
.
'gain_Klarheit' is not a float/in.. ![]()
I think part of the challenge with naming this control (and the similar one in DorS), is that there are pros and cons to it. If we name it something like âhalo avoidanceâ or âHalo suppressionâ, etc. it sounds like something you would always want to crank up to max (everyone is trying to get rid of halos
).
I think I agree with @mino, that it make more sense to reverse the polarity and call it âedge sensivityâ, or maybe âedge contrastâ (this is a more neutral term, in that everyone knows that more âcontrastâ is not always better, as opposed to âhalo <avoidance, rejection, etc.>â).
We probably want to avoid doing the whole âavoid halos â emphasize edgesâ as well. I know no one suggested that, but I think it is less than desirable. Fine for a tooltip, but not the best design for a control name.
I think this module is incredible. I think itâs extremely well done. It also doesnât seem as broad as the previous approach. ![]()
That looks like a bug! I tried to make the parameters loop over its settings but i think i might have put the wrong dependency on strings in that logic. Try it in English until i fix that, probably works.

