stealing the curve is just possible if the underlying math dealing with color information is the same.
There hasnāt been a convincing solution to deal with the curve in a different way than itās done by darktable yet - if it wouldāve been that simple, Iām pretty sure we had already seen a RFC pull request ā¦
There is a way to deal with those overshoots, and itās used in the color equalizer (hue tab)⦠So probably the author of that module had a good reason not to allow that solution for the other tabs⦠See hereā¦.
As other places have a way to limit the overshoots (contrast equaliser), perhaps a good question would be why thatās not done everywhere?
(To expand on why I think so: it is horrible because it changes the whole curve in a fundamental way.)
As to why monotonic spline interpolations were not used in Darktable originally: probably because they are a pretty esoteric topic and few people know about them.
Incidentally, the whole spline interface of Darktable could be improved significantly by allowing the user to insert, move, and delete control points. A single widget would take care of this. Combined with monotonic interpolations, it would be a single breaking change for a significant improvement.
(I still have not forgotten about implementing this but currently have no time because of work & private life constraints; I will get back to it soon. If someone beats me to it please announce here so we do not duplicate work).
For the tone equalizer, it is essential that the user can drag the curve up and down at any point, not just at the (fixed) control points. Control points close to the point that the user dragged must adapt, so the curve reacts in the way the user expected.
Can the curves that were discussed above fulfill this requirement?
What I meant to ask is this: Are these curves suitable as a drop-in replacement for the TE, keeping the current UI the same.
So the curve would have to work with the existing 9 control points in fixed intervals. The curve can be modified with sliders that move the control points up and down, but also by dragging the curve at arbitrary locations (between the control points) and by scrolling over the image with the mouse. In this case no extra control points would be added, but the existing control points would be modified in a meaningful way.
So in short: Keeping everything the same, while just getting rid of the wiggles.
Thatās the whole problem: you cannot keep everything the same in that case.
In the examples Iāve seen so far, the āpeaksā get narrower in a way the user cannot control. I have no idea what that does to the image, but Iād expect ānothing goodā, seeing that color equaliser did not implement the width setting in the brightness and saturation tabsā¦
(Note for @tankist02: if you want to compare things, make sure you show comparable views. As I read the screen shots, for ART you show the Hue curve, for dt the brightness curve. In dt, you can already get the āART behaviourā for the hue curveā¦)
Note that in the current GUI, the āwigglesā appear most strongly when you use the āsimpleā tab. āAdvancedā or scroll wheel on the image are much less likely to produce wiggles, and those were the intended interface for normal use, iirc.
Play a bit with the āhue curveā slider. A value around 0.3 could be interesting.
Also, note that that parameter is not present in the saturation and brightness tabs, by design (this point came up recently in another thread).
Yes and no. From a pure math point of view, the actual space is irrelevant. Iām not so sure about the effect on the image. For starters, human vision is much more sensitive to variations in luminosity thanto variations in hue and saturation (which is why we treat luminosity noise and chroma noise differently).
(We are using those tools to edit images to our liking, after all).
Iām talking here purely about the curve between the points regardless of values it represents. A good interpolation should be smooth enough and do not produce non monotonic parts. E.g.:
They are a replacement, but they will change the effect so the change is breaking.
This is a possibility, but fixed control points are limiting in some cases. My suggestion was that if we do one breaking change, we might as well improve the UI. But of course this can be done later as the fixed control points case is nested within the flexible control points.
I am not sure what you are talking about here, but in any case the curve is computed using the control points only. The UI may present controls that seem to ādrag the curveā, but that still works though the control points.
The problem with that approach (as described here in APās post in detail) is that the smoothing required to kill oscillations makes the peaks really, really sharp. This is generally a problem whenever you use exponential dampening.
It is unclear why AP used RBF for periodic smoothing. This can be handled just fine using B-splines, by imposing a continuity condition on the edges. The smoothing approach he invented in that blog post is quite clever too, but again, monotonic spline interpolations make that unnecessary.
As a reader with fairly limited mathematical background I skimmed APās article to see if I could understand what this is about.
I did at least note the following from the conclusion:
āThe radial basis functions can be fine-tuned for more or less damping, by allowing more or fewer harmonics, through the smoothing parameter. But they might be gay since they usually have an hard time conforming to straight patterns:ā
Maybe this is an old and well-know joke among those who normally engage in this type of issues. My day was anyhow brightened ā¦