Darktable base curve

Genuine curiosity: why the base curve is considered nonsense? I’ve used the base curve fusion method with success, up to now…:sweat_smile:



The base curve is a way to get a quick emulation of various camera styles, which introduces nonlinearities, which propagate through successive edits. Depending on what those edits are, there will be gamma errors, hue shifts, etc. Whether this is actually a problem for a given image depends on the user’s goals and also on what those other edits happen to be.

Personally I don’t use the base curve except for very quick edits when I just want an idea of what a finished image might look like, in which case I’m probably using UFRaw instead of darktable, and almost certainly I’m not using any of the presets.

But I’ve always thought all raw processors should have that base curve code because it really is such a quick and convenient way to stretch midtones. So I don’t have a clue why anyone would call it silly.


I’ve recently settled on a workflow that starts with a batch-process to 800x600 JPEGs for proofing, and I use what you would call a base curve to make them look presentable. In reviewing them, if an image looks promising I’ll re-open it in the interactive program, which will use the proof processing as a starting point. From there, I’ll remove the tools I don’t like, or re-work them to some other end. My basecurve is an actual curve, so I usually use it to do some other tonal manipulation.

I’m curious about working a log profile into my workflow, so that’ll probably change my use of a base curve. All good fun…

@Elle: this is exactly where the base curve comes from, it’s ufraw code. The initial raw processing pipeline in dt was run through a libufraw.so Frankenstein thing… I always appreciated the results over the somewhat cleaner pipelines such as in rawstudio in the days, that gave much duller results. Fwiw, I liked ufraw as a tool, only working with >1 images was a bit cumbersome.

FWIW: I still believe that the darktable basecurve has some unexpected behavior: Base curve interference with (clipped) highlights? Just be aware what you do with it :slight_smile:

I also don’t use the base curve, even though I find it sometimes handy.
However, if it’s thought to be ‘silly’ by some of the developers, why the module is still there?

It would be very useful to hear opinions from some developers who doesn’t think it’s silly and maybe can tell why it’s still there…

Maybe no one can explain it and it would make sense to remove it. But it seems to me that this module is still actively maintained, so there must be something not ‘silly’ about it…

OKish first restult to inspect the image and backward compatibility. You don’t want that your edits you did some years ago still work and not break some day.

Yes, I was using UFRaw before and also while darktable was being first coded up. I stopped using UFRaw because I discovered and reported a bug in how it handles negative exposure compensation, that was causing clipping of valid highlight information. Afaik that bug still remains in UFRaw, which is a shame.

UFRaw provided a nice quick way to output a scene-referred image (not using the base curve or any other post-interpolation processing) for further processing elsewhere. But there wasn’t any easy way to tell when “the bug” was influencing the output, other than by tedious sliding and resliding of white balance sliders with a trip to Rawnalyze to check whether the raw file actually had clipped channel values or not.

Checking the link, those are some extreme base curve moves! I wonder if there’s any chance that the old UFRaw bug somehow snuck into the darktable base curve code.

On a related topic… I’m sure it must be somewhere in the docs, but I couldn’t find it.

Upon import, darktable always enables the ‘base curve’ module and applies a certain base curve (with the ‘core option’ settings you can only set which curve is selected by default, as far as I understood).

Is there a way to prevent darktable from applying the ‘base curve’ module upon import?
Right now, I disable it in all images after import, but I guess there’s a faster approach…

I have created a style called FLAT that I apply to all imported images. The style disables the base curve module.

Thanks @DerKnipser. I’ve seen already this approach, I think, somewhere in a comment to a bug, opened to ask about this exactly.
I hoped this was not the only approach, a bit too Penelopee (doing then undoing)… And not very elegant nor robust…

However, I’ll live with it for now, since it actually seems to be there no customization for that.

Give some recent developments, e.g. this latest ‘filmic’ module being merged to the master, it would be so cool to add a check-box for this somewhere in the settings… :roll_eyes::innocent:

Regarding “messed up colors” I put up a post with some metrics for measuring “how messed up”, evaluating a test image processed using darktable, comparing a sample “base curve” to the new “unbreak profile” and the new “filmic” module:

Thank @Elle!
I liked your topic about “messed up colour” a lot. I love the scientific and quantitative approach :wink:

Now it’s also more clear to me why the “base curve” module is still there and how it could be of use.
I also didn’t think it was so bad and I couldn’t understand why it was so much dis-recommended.

I see now that it’s not a spread opinion to get rid of it.

I don’t use dt very often. I see base curves as a quick way to achieve a certain camera’s “look”. I used to do that all the time when I used Photivo.

Oh, we should definitely have a photivo section here. The quality I got from it back then was much higher than what I achieve with darktable these days, especially with landscapes, what is of course only due to my lack of skill. :wink:

Thanks to everybody, now I have a clearer idea of the base curve.