"Aurelien said : basecurve is bad"

Software darktable
201

Chroma/saturation are defined as the distance to achromatic (and white = brightest achromatic). That’s pipeline white. If the image white ≠ pipeline white, then any chroma/saturation increase will make it even less white (and also possibly will not happen at constant luminance). Which is probably not what you want. There is an usual consensus on the fact that white is achromatic and should not be affected by chroma boost.

So, there is no blasphemy in there, just a big bullet in your own foot. Which, ultimately, is your problem. Just watch out for not-so-white teeth that may take a real turn to yellow in “warm” lighting.

1 Like
202

As always I really appreciate your comments….for sure when you go against the grain there can be unintended side effects… I think this is what you are trying so hard to preserve in all the modules as you develop and integrate them. On my end I think some of this comes from the many DNG I edit from my phone. The pixel from google seems to add a sort of blue boost to JPG and it bumps contrast at least perceptually but the jpg are often cold looking to my perception….mine is a 3a …newer ones are supposed to have better skin tones etc nonetheless skin tone on these images are a bit pale looking for my taste so I have to mess with them….so in my case my process may be a function working with a specific camera rendition so much…and the fact the I am somewhat color blind doesn’t help. I have been playing with your color matching and the published so called normative values from the paper you presented…The skin tones on my family members get much better than out of the camera to my eye but can tend to be a bit too warm…I usually try an exposure bump which often is all that is needed but when that is not the right fix I can then tweak them in the color match rather than mess with wb…

203

@anon41087856, does that only apply to base curve or does it apply to the rgb curve and tone curve module too?

base curve lacks the cubic spline interpolation method.

204

I’ve been following several interesting discussions here. To be honest, I may be mixing all of them in my mind, but I’d like to clarify one thing :slight_smile:

Here and there I see: “You can switch to scene-referred in preferences” [in order to work the modern way], and if:

my question is:

What determines if I’m working in display- or scene-referred way?

I suppose choosing one option in the program settings and then using the modules from the other “world” doesn’t mean I’m in that previously chosen workflow :thinking: It’s just a set of defaults applied when opening imported RAW, isn’t it? And my further actions can override it :thinking: ?

So… taking my currently established workflow:

  • in preferences set to “none”
  • using CAT, tone equalizer and…
  • …base curve at the end of the pipeline

it looks like I’m basically working in scene-referred, but I’m just using different tool to make my image ready to be displayed on screen / printed (i.e. base curve instead of filmic RGB).

205

It’s mostly determined by the position of the modules you’re using with respect to filmic or base curve (the modules that transform the data from “scene-referred” to “display-referred”). If you use the “v3.0” module order (as you are with “none” selected) then everything before filmic/base curve in the pipeline is working in scene-referred space and everything after in display-referred.

The legacy way of working (display-referred) basically assumed that you do your scene-to-display tone mapping early in the pipe and then process further on top of that data. Scene-referred does the tone mapping as late as possible (ideally right at the end of the pipe). However, I’m not sure what the effect would be of putting base curve at the end of the pipeline but still using modules that assume display-referred input. You can hover over the module headers to see which inputs/outputs they assume (those that assume display-referred input should really be after filmic/base curve in the pipe). If you’re not moving modules around in the pipe, and base curve is the last one you use, then yes you are working in scene-referred.

1 Like
206

Well… simply the effect I like so much :wink:
Really effortless, most often just a single click to choose my preset in the base curve module + sometimes another preset to fill light with tone eq.

You can compare my quick edit of this PlayRAW.

Thank you for your answer and explanation! :slight_smile:

207

I took a quick look…on my screen your edit looks a bit better …to my eyes if you dial in some shadow bias on the base curve…you have it at 0.6 with 3 exposures and no bias to the fusion…for me adding the bias yields more color less haze and highlights on rocks in background look a bit better…could be my monitor and personal taste vs yours…:slight_smile:

208

Yes, personal taste is important. For me, using the base curve with “no” chroma preservation completely resolves skin colour issue, I get more pleasing (to me) colour overall and nice pop contrast.

Plus, what Aurelien mentioned in his last video, it hides the problem of blown highlights. True, he’s right, the problem IS still there, but… if it cannot be seen :wink:

So I believe I take what’s best from both worlds. To a degree I reflected the way of working with all those programs known for decades - fixed curve + minor tweaks with superb tools like colour calibration and tone equalizer. Also colour balance from time to time. Not to mention cropping, watermark etc.

Anyway, I’m extremely happy with darktable. The output I get is top notch, UI and masking convinient & powerful.

2 Likes
209

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
210

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

1 Like
211

My problem with base curve is that it lacks the cubic spline interpolation method. I filed a feature request on GitHub. :slight_smile:

212

@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
213

What benefit does it give?

214

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
215

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
216

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
217

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.

218

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)

219

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.

220

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