I occasionally use the Simple sliders for all of the reasons below:
If this functionality could be implemented on the graph sliders, then I would be ok with removing the Simple sliders. But if this isn’t done, I definitely see merit in keeping them.
One aspect of the Tone Equalizer that always irked me is that moving a node on the graph will always affect adjacent nodes. It makes it very hard to be precise when the need arises.
But the curve represents the exposure compensation applied to the image, so any variation in the curve will have an effect on the exposure. Here for example, increasing zone -4EV by +1EV will decrease zone -6EV and -2EV by -0.25EV. I think this was not intended by the devs but more a consequence of the model/math behind the curve, and also not expected by (beginner) users.
The exposure of each pixel of the input image is adjusted using the mask and the equalizer graph. For each pixel, the module looks up the brightness of the mask at that point, finds the matching brightness on the horizontal axis of the equalizer graph, and increases or decreases the exposure accordingly (using the vertical axis of the graph).
the curve is calculated to avoid artifacts or banding - so it’s intended by the developer who chosed the mathematical function (there are different options e.g. in tone curve where the user can switch between 3 curve types) . The developer assumes the user knows what he’s doing - and so didn’t protect the user from doing silly settings. You don’t edit ranges like in the old zone system but you set the control points of a curve.
At least that behaviour is a good argument why adding the sliders to the advanced tab below the graph doesn’t make sense at all …
the module isn’t designed to do edit by numbers but by result
I think I give the devs a bit more credit, and expect they did intend that behaviour. For a very simple reason: the curves in “contrast equalizer” show the exact same behaviour, and that module predates “tone equalizer”. So the math used to interpolate the curve was already known. And yes, the “wiggles” are a consequence of the math used.
I’d also suggest that the naming “simple” and “advanced” refers to the interface, not the use of the module: correct use of the sliders requires more insight than use of the “advanced” interface (or just scrolling in the image on the zone you want to modify).
“Simple” tools can be a lot harder to use than “advanced” tools 
Thanks for looking into this — I agree with your reasoning. In fact, I implicitly assumed that the current implementation uses the scheme you suggested because it makes the most sense to me.
I would propose a more radical UI change: if f is the luminance mapping, the current UI makes the user set f(x) - x, so f' < 0 or f' \approx 0 can happen very easily without intention.
The user should set just f, extrapolated with slope 1 at the edges. This is how most tools do it (eg Photoshop, Lightroom, although in finite display-referred domains).
Also, the interpolation can give wacky oscillations around control points. Cf
Too bad the thread got stuck. I agree, those oscillations do not help anyone.
You could see them as an indication that you are pushing the module a bit too much.
But if there are alternative spline interpolations that do not cost too much more calculation power, that would be nice. I’d like to know the original reasoning behind the choice of interpolation before spending too much time on looking for alternatives, though. (That of course assumes the original coders aren’t complete idiots.)
Its an AP module.
Dunno if you’ve seen this but might be of interest
Yes, it’s intended, but I still see where the frustration lies. As per @gigaturbo’s example, increasing one node by 1EV can hardly be regarded as “silly”. But it’s enough to create oscillations.
The Tone Equalizer is simply not designed for moving one node. It’s excellent at more subtle adjustments over a range of nodes, but I’m thinking a lot of people are looking for something more like the old zone system module where you could pick a zone, and move a slider to just affect that zone.
Of course, that doesn’t mean that the Tone Equalizer isn’t working properly, but I definitely see where frustrations come from. It’s clear that it’s a polarizing module, with some eager for it to change and other liking it as it is.
Perhaps it garners such strong opinions because there’s really nothing else quite like it available. Other than using parametric masks, there’s only this module that attempts to split the tonal range into zones for dedicated dodging and burning, whereas we are spoiled for choice with tone mappers, colour grading, sharpening, denoising, etc.
using a tool for a task it’s not designed for and then wondering why it doesn’t work as expected is something I’d call ‚silly‘ …
The question is why would it be “silly”?
I wouldn’t be so harsh, I believe moving one node as shown here is a valid use-case.
The oscillation which is shown is only caused by the mathematical function which describes the shape of the graph.
The idea behind this function is to have smooth transitions to avoid banding.
Moving only one slider could be also described by a gaussian-like function with a smooth roll-off
That is true.
But (of course there’s a but) the mathematical function needed has to describe a curve with 9 predetermined points (start, end and 7 intermediate points). That means you have 9 parameters influencing the curve (and preferably with the curve passing through the points). You can’t do that with a gaussian-like function (which, for me, gives a bell-shaped curve with one local extreme).
You can also use piece-wise interpolation, but you’ll still have to use something that can yield a curve with multiple local extremes.
On playing with the curve in tone equaliser I noticed something else which makes me doubt the “simple” interface: it’s very hard to get a curve that does not go through all the “fixed” points with the “advanced” interface, but that’s very easy to do with the “simple” interface (just pull two neighbouring sliders in opposite directions). But after “messing up the curve” with the simple interface, the slightest correction in the “advanced” interface gives a curve that fits the points…
And this probably was the main reasoning behind a spline function instead of other multi-modal functions.
Either that, or you could use a (gaussian) mixture model, which arguably is a little bit more difficult to handle but is also a continuous multi-modal function 
Where does it say in the manual or anywhere that the module is not designed around moving just one node? We’re talking about moving a node by 1EV in a panel that allows you to do exactly that. I think calling people “silly” for doing that is way too harsh.
It’s not silly, but the curve undulates in this case to give you smooth transitions.
I know that, and I think most people realize this after using it for any length of time. But this whole discussion is about potential improvements and why the module causes frustration for some people. I know its limits, so I stay within them, but those limits can be hit very quickly (for good reason, I know), especially in the Simple panel.
Anyway, I won’t beat a dead horse. The module does work as designed, but I understand why people want changes to it.
There seems to be a lot of focus on the exact shape or response of the curve and I wish I knew the math better but taking a glance through the code there seems to be a lot going on in the background such that I start to feel like it’s a more general representation of the change applied and not a direct visualization of the outcome…for a certain mask might it not be that the oscillations might not even have a noticable impact…or produce a result similar to one without oscillations?? I think the simple interface almost leads one to a sort of perception of fine control of discrete zones which if it behaved that way would likely break the image . But again this could just be my opinion as I can’t follow all the math in the module.
I think this is one of the points I was trying to make, but you put it in better words. The module in general, and especially the Simple panel, gives the impression of fine control, but the curve soon falls apart.
But I’m also interested in how much the oscillations actually break the image. I’ve always backed off immediately when I see the curve start oscillating, but the effect is not always visible on the screen until you push it really far. But even though you can’t see negative effects, if the curve is correctly reflecting the underlying math, then surely we should always be avoiding the oscillations.
It’s similar in Filmic when i see the curve turning orange. I always back off, but I don’t always see the problem in the image.
Well again its my failing an perhaps my poor understanding of how things work but if these sliders are scaling points to apply changes the resulting changes imparted on the image also depend on the underlying mask which can vary tremendously depending on the settings used so I think if that is somewhat representative then the exact same curve could give different results depending on the mask as much or more so than the …so if the user creates a highly blurred mask or one much less so I think the impact would or could be very different… But again I think this is why it works so well is that things blend so nicely and it’s not introducing sharp changes… I admit the “wiggles” as many have described them are visually concerning I suppose but I have never tried to introduce many weird curves and I tend to keep things smooth … often I find if an image needs a boost the simple relight preset works great and then i just modify each end if needed if it doesn’t fully compensate in a way that I am looking for… Having said all that it never hurts to question and investigate to find ways to improve things…
