I did start using no preservation with filmic a long time ago. It seemed to counter act the desaturation but there are occassions where one of the modes was better than using no depending on the image.and the edits added…The base curve can be the same with all those modes …on this image some modes evened out the skin tones and some introduce some tone and shadows to the face…I also tried the Panasonic curve as opposed to the one you used and the look was quite different again…so many options…
1 Like
There is one issue, though. I noticed with filmic set not to preserve chroma, althoguh the colors look nice, sometimes even a soft colour boost in colour balance rgb produces black pixels in difficult colours.
I have never encountered this with base curve so plus one point for me to liking it 
1 Like
My problem with base curve is that it lacks the cubic spline interpolation method. I filed a feature request on GitHub. 
@mikae1 Why do you insist on a cubic spine interpolation? Normally you really want your basecurve to be monotonic (to avoid gradient inversions, aka horrible artifacts), and a cubic spline will not guarantee that.
2 Likes
What benefit does it give?
If RGB code values are bounded in [0; 1] AND middle-grey = 50%, you are in non-linear display-referred.
To go to non-linear display-referred, you need some sort of non-linear tone curve that raises the midtones while keeping white as-is.
You need non-linear display-referred if you are using blending modes like soft light, overlay, hard light, darken, etc. because they rely on grey = 50 %. You also need display-referred if you are using HSL operators because if RGB > 1, S < 0 (I think colorize and split-toning modules work in HSL, I would need to check).
If RGB code values are bounded in [0; 1] AND middle-grey = 18%, you may be in linear display-referred or in scene-referred that happens to have low dynamic range. This will make blend modes like soft light, hard light, screen, overlay, darken, etc. fail because of the grey value.
If RGB code values are unbounded, you are in scene-referred.
You need scene-referred to apply white balancing/chromatic adaptation, apply input profiles/correction matrix/channel mixing in color calibration, emulate optical effects such as lens blur, or undo optical flaws such as lens blur or hazing.
Notice that the end of the pipeline is necessarily display-referred because it ends in a display. So the scene-referred pipeline ends with a display-referred part. The scene-referred workflow only means that you work your colors before the display transform. Which is why you need to mind the place of the non-linear transform in your pipeline.
15 Likes
Excellent description. The only thing I’d feel compelled to add is that profiles you use for exporting may contain that display-referred transform, so it might not be in the workflow that you see in your toolchain…
1 Like
Yup, basecurve itself has a nonlinear output, but it does not yet itself have the actual display transform applied, so it’s pretty much an “artistic” nonlinearity.
This can sometimes be seen if you look at HDR/wide-gamut video content (Such as Rec2020 + Dolby Vision or HDR10+) - a lot of it still obviously has an S-curve applied to it to compress dynamic range prior to the final display transform when it was mastered, partly due to the fact that while HDR displays have much better dynamic range and gamut than SDR (Rec709/sRGB) ones, they still do have limitations - plus at this point we are for all practical purposes conditioned by legacy content to perceive certain behaviors (such as film’s nonlinear response to light, and 24 frames per second with a 180 degree shutter angle) as “cinematic”.
2 Likes
I’m not sure this is quite correct: iirc the output from basecurve has a log transform included, so that it’s perceptually linear (with “middle gray” at 50%. That that transform isn’t explicit doesn’t change that.
After that, there’s another transform to the output color space, but that’s a different story.
Referring to HDR iin this context is a bit of a red herring, as basecurve was never designed to handle HDR input, it expects its input in the range 0…1 and gives output in that same range. So for HDR imput, the dynamic range must be compressed before you apply the basecurve.
Nope. If you set basecurve to be a straight line (only nodes at 0,0 and 1,1), it basically becomes a no-op except for clipping above 1 - linear in, linear out. Or at least that was the case back in 2019. There is the ability to have the shape of the displayed curve be in a log-log space for easier editing in the blacks though, but that’s just a UI thing.
In fact, this aspect of basecurve is exactly why the built-in exposure fusion performs so poorly in the current implementation. All of the weighting functions in Mertens’ original paper are designed around image data that has had an sRGB display transform already applied to it. (e.g. assumption that 0.5 = middle grey)
Sorry, you’re right, I was thinking of its use with the presets. While those do include the log transform, the module as such doesn’t, like any tone curve.
Adding extra control points on the cubic curve can always give you the same result as monotonic (but with more fine grained control).
However, attempting to undo the effects of the monotonic curve by adding control points is difficult.
I create a custom curve for each image and I’m constantly battling the monotonic interpolation that is mostly doing damage by trying to help.
I associate darktable with more control, not less.
So I am not sure if this would work for you. It may just be a fluke with the two images I tried…I transcribed the base curve values to the rgb tone curve and took a snapshot to compare each and there was little to no difference between the base curve and the transcribed tone curve…so maybe you can experiment…base curve is in 0-100 and rgb is 0-255 so you need to do a bit of math to convert…but if that is your workflow you might be able to go that route and have your spline??
Thanks for answering @priort! Not sure I understand what you’re saying. Is your suggestion to use rgb curve intead of base curve? That’s what I’m resorting to now, only to get cubic spline.
But from what I can gather base curve would be the better options because it operates in linear space. But I’m not sure, hence the spamming of this question: 
Have you checked the manual (modure reference section) and/or the tooltips in darktable? Those should answer your questions.
And if a question doesn’t get an answer, there’s usually a reason for that, and it’s not lack of readers…
So why would spamming a question change anything? (apart from annoying those that could have an answer…)
1 Like
I guess my hope is that someone would eventually pick it up. Sorry.
rgb curve says:
RGB is a linear color space designed to capture and display images in additive synthesis. It is related to the capture and display media and does not isolate color and lightness information in the same way that Lab and XYZ color spaces do. This module works in ProPhoto RGB.
Which sounds good, I guess?
base curve on the other hand mentions nothing about linear. I’m still not sure if rgb curve can be a just-as-good replacement for base curve.
As noted above check the tips…they are identical except for the output which is not linear from the base curve and linear from the rgb curve … I tested it on a few images and I could not see the difference in output when I plugged in the same curve…
Base
RGB
I was suggesting that as you needed that option of the spline… my suggestion was to port the basecurve values for your camera as a starting point and go from there or tweak that to get a starting point and then you could add your per image tweaks…
By no means did I do any in-depth analysis but the results were visually similar for me if I toggled basecurve vs rgb curve with the same values and chrom preservation settting… FWIW
I think the main difference is that with the legacy pipeline order, the base curve comes early in the pipeline, before input color profile, so it is applied in camera space. On the other hand, rgb levels/curves are applied in the working space, after input color profile:
With the current workflow, base curve is at the end, just like filmic (one would normally not enable both, this is only done for demonstration):
Functionality-wise, base curve has the exposure fusion, which rgb curve does not have; and, as you have noted, the way the curve is constructed is different.
2 Likes
By definition, once you’ve applied a curve that is anything other than a straight line, it’s not really linear any more. If the “rgb curve” module states that the output is linear for any setting other than what is effectively a nop, it’s lying.
I guess you could call it psuedo-linear - it’s linearly encoded, but is no longer a linear representation of the scene. But in that manner it’s exactly the same as basecurve - basecurve’s output is linearly encoded image data, but it’s fundamentally no longer linear because if the inherent nature of a tone curve.