monotonic spline interpolations in Darktable

No. You can conceptualize a cubic B-spline as

  1. values and derivatives at nodes (+ end conditions), which can be
  2. mapped to polynomials.

The interpolations I am considering adjust the derivatives, inserting a step between 1. and 2.

(There are other schemes, eg Schumacher, that insert extra nodes to maintain monotonicity; I am not considering these).

Maybe just steal the code for curves from RT/ART?

I moved one node up and got these results:

ART curve:

DT curve:

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?

That’s a horrible workaround, not a solution.

Because it is horrible? :wink:

(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).

… can you remind me what this code does?

it’s been a looong time i had my fingers in this and i honestly forgot.

Looks like an implementation of the classic Fritsch & Carlson (1980) scheme.

There is an improved scheme by Fritsch & Butland (1984), and Steffen (1990). In practice, they are not really different for out application.

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?

Yes, they are generic, you pick the knots you like (so are B splines we currently have, fixed knots are an UI choice in DT).

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.

1 Like

Not sure what do you mean about DT and Hue, I see the same curve oscillations as with Brightness:

This is a math problem of smooth interpolation between points on 2D plane. What is the actual space (Hue, Brightness, etc) is secondary.

1 Like

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.:

https://en.wikipedia.org/wiki/Monotone_cubic_interpolation

1 Like

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.

1 Like

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 … :grinning:

1 Like