Right, you might want to keep context in your quotes. I started that phrase with " If it stays only that,".
If this is how you want to discuss, I’m out.
1 Like
@rvietor: but it was understood from the very beginning that the intention is to gather information before opening an issue, so it was clear that it would not “stay only that”:
I think that for non-obvious issues (eg feature requests, rethinking algorithmic decisions, etc), it is better to discuss in detail before opening on Github. That way we don’t waste the time of devs with half-baked proposals.
4 Likes
I just read part of the thread and I’m wondering what kind of solution would be better ?
- Find a new interpolation method that preserves the monotonicity
- Keep the current interpolation with all the good of it (implemented, tested and probably fast), but change the UI interface to automatically raise/lower the points in the neighbourhood to avoid the monotonicity problem ?
I have the feeling that the second option could be easier from a development point of view (Although, it could take time get right)
2nd solution is not a solution to me, computer science tricks cannot take over the math.
1 Like
I still don’t understand why this is a problem.
Speaking as a regular user, if the choice is between having the wiggles and not having them, I strongly come down on the side of not having them. I would rather modify what I intend when I make an adjustment without side effects that have to be readjusted afterward. I felt @gigaturbo 's example was very good. If I want to desaturate something, there is zero chance I want any part of the photo to gain saturation without specific intent.
Unfortunately I have nothing else I can contribute here. I’ve seen discussions get bogged down in user’s hopes, dreams, and opinions, and I hope not to add too much noise.
4 Likes
I would guess that finding a (non-iterative) algorithm that adjusts the nodes just enough to avoid the wiggles is at least as, but possibly more, difficult than just implementing a shape-preserving interpolation which already exists, and was linked above by someone who wrote a textbook about these methods (and a lot of other stuff) so we can ask him if we get stuck 
I plan to code a toy implementation soon so that I can compare curves, I will present it here.
2 Likes
But isn’t that what happens in the contrast equaliser (adjustable interactively, at that)?
And science is full of examples where (for various reasons) common practice deviates from what the math says is correct (given other sources of error, “good enough” works 
).
My point is that tricks are always dangerous and will just fail in some conditions. If we want to avoid the non monotonic curves… we want to use a monotonic spline not play with the node in random ways.
3 Likes
I agree, and of course they always fail in the worst possible way…
Are we sure we want to force monotonic splines in all situations? I asked that several times, and didn’t see an answer.
In what I suggested, you’re not playing with nodes in a random way. What happens is predictable, visible and adjustable, no hidden tricks. And the basic code should already be in darktable (as it’s used).
If the method in itself is wrong, fine with me.
I did a bit more literature search and found some other algorithms. Below I show plots for
- Fritsch & Carlson (1980), “Monotone Piecewise Cubic Interpolation”
- Fritsch & Butland (1984), “A Method for Constructing Local Monotone Piecewise Cubic Interpolants”
- Steffen (1990), “A Simple Method for Monotonic Interpolation in One Dimension”
using two example curves. The dark green is the cubic method we have now, while the dark red one of the alternatives above. For one adjusted point, all of them eliminate the wiggles, and all three methods are visually indistinguishable (in fact, if I plotted them on the same graph, you would only see one for most x values).
For two adjustments, they are again very similar.
I can make more graphs (they are all implemented in the Julia package Interpolations.jl, so it is easy). Just send me y values to interpolate, on an integer grid starting from 1. (if anyone wants the code that produced these graphs, just let me know, happy to share if you want to experiment).
When it comes to implementation, I think that the Fritsch & Butland is the simplest. It is a one-pass adjustment of derivatives, and could be easily adapted to periodic approximations.
6 Likes
Humbly speaking as yet another regular user™, I could see myself using the “color equalizer” tool more if one of these methods to preserve monotonicity were to be implemented. Especially since, for example, when I was turning down the brightness of cyan in my landscape shots, the “wiggle” brightened the green and blue tones, so I had to fine tune them in search of a compromise. It wasn’t terrible, but definitely was an undesired and unforeseen side effect.
If I can avoid that behaviour it would be more than welcome even if it was a selectable option, in case anyone prefers to keep the current behaviour.
1 Like
How do the guided filter settings play in to this… can they be adjusted to compenstate by making a “tighter” color selection??
does these examples respect that the horizontal axis in color equalizer isn’t representing a line but a closed path? -180° and +180° are the same hue value - so the curve must be smooth there too
These visualizations are interesting. They show how the interpolation function is always a tradeoff.
The current function has overshoots after neighboring nodes, but the effect width is constant.
The monotonic spline does not have overshoots, but the effect width varies depending on neighboring nodes.
I think the latter is more appropriate for our purposes (effect width relatively widens if neighboring nodes are raised, but then that was evidently the intention, so the behavior is likely appropriate).
Could you post another example with an up-mid-low-mid-up sawtooth curve, to see how the methods fare with intentionally smooth changes?
No, that is just a coincidence. I did not work out the periodic case, I will do that when I open the issue.
That is very good intuition! The math goes like this: B-spline basis functions span 4 adjacent intervals (for cubic splines), which are two times continuously differentiable. The monotonic algorithm breaks continuity to maintain the shape (Fritsch-Carlson and Steffen where necessary, Fritsch & Butland everywhere), so the “effect width” is indeed smaller, no action at a distance
Good suggestion, see plot below (if I misunderstood what you are asking for, please let me know and I will redo it).
I would like to thank everyone for the feedback and the suggestions — keep them coming! Since the reception is generally positive, I will wait a bit more for questions and suggestions, then work out the algebra in a way that is compatible with the current implementation, then open an issue.
7 Likes
Interesting! The new graphs show overshoots not just in neighboring nodes, but also the center node: the maximum is no longer centered on a node, but is shifted depending on the neighborhood.
At any rate, either of the three proposed functions seems to be an obvious improvement over the current code.
Backwards compatibility will be an issue, of course. We’ll likely need to have a selection for the interpolation function, as old edits will look different with the new function.
3 Likes