PL8: The new Tone Curve - - Discoveries and learnings

Creating custom Tone Curve presets … is straightforward and easy to do.

I’ve tweaked a couple to include “handles” for easier manipulation of Curve Points - Available here for download;

JohnMDefault(RGB & L[Gamma]).preset (1.0 KB)
JohnMLinear(RGB & L).preset (1011 Bytes)

They should work equally for Win and Mac.

  • Installation for Win users - - Save the ~.preset files into folder; “%UserProfile%\AppData\Local\DxO\DxO PhotoLab 8\ToneCurves

  • For Mac users … @Joanna or @platypus ???

2 Likes

That will be ~/Library/DxO PhotoLab v8/ToneCurvePresets

1 Like

Although I didn’t notice the subtle misdirection of the Linear preset (which really is not so much a preset as a reset), I did ask DxO to include the bracketed channels on user presets also.

But here’s the fun bit I just realised. It’s not as simple as “RGB” or “L” or “RGB + L”. It could also be “R+G+B+L”, for example. Because the “RGB” curve is separate and distinct from each of the R, G, and B curves.

You could boost the blue midtones, drop the red highlights and S-curve the greens, and also make some adjustment to the RGB curve and Luma curve.

At this point I think letters just get confusing. I imagine one or more coloured dots — red, green, blue, and white, plus a “triplet” RGB dot.

1 Like

As always – use the presets that come with the all-new tone curve as starting points.

Modify them if necessary and save them as custom presets.
Screen Shot 09-21-24 at 10.44 PM

Thanks, John. Very good summary of new PL8 features!

1 Like

This is not about editing but maybe some will find it interesting, if not already known and explained elsewhere.
I tried RGB and Luma “spike curves” on the 16 million colors 8-bit and 16-bit TIFFs, attached.
The experiments with these presets and Working Color Space choices make me scratch my head…

As a side remark: I wanted to add (99,0), (100,255), (101,0), (255,0) points but for RGB channel it wouldn’t let me add (101,0), so I used (102,0) instead. Looks like yet another minor bug.
You may also play with the gamma presets attached. They are all “full presets” in terms of tone curves.

Gamma_V0.50_L2.0.preset (577 Bytes)
Gamma_V2.0_L0.5.preset (576 Bytes)
Spike_L100.preset (624 Bytes)
Spike_V100.preset (647 Bytes)

16m8b_rgb.tiff (1.4 MB)
16m16b_rgb.tiff (2.7 MB)

You should send DxO a bug report on this, as it’s unlikely they’ll see it otherwise.


I just tried and succeed. On RGB, R, G, B and L channels.
Drag points or enter numeric values works and I can set desired values.

PL8.0.0 build 417 Win11.


How did you manage to get the tone curve presets you provide ? And how to load them in PL ?
I can save presets internally in PL, but find no option to save to and load from disk. Which can be usefull and should be a mandatory option for any preset.
Have you these options or did you copy them manually from where PL saves them ?


What makes you scratch your head ? What does not work as expected with those charts and presets related to color spaces ?


I suceeded for L channel but not for RGB. If I enter 101, PL resets it to 102, even though the “previous” point is (100,255). Strange. I’ll try to edit it directly in the file tomorrow.

ToneCurve presets on Windows are saved in “%LocalAppData%\DxO\DxO PhotoLab 8\ToneCurves” and that’s where I copied them from after saving in PL. That’s probably configured in the local user.config, which I don’t dare to touch.

It’s unclear how (r,g,b) is transformed by the curve. Look at RGB curve with WCS set to ‘Classic (Legacy)’. I don’t get the meaning of ‘x-axis’ and how the corresponding y-value is used. It seems that in this case the RGB channel x-value 100 corresponds exactly to (r,g,b) pixels with at least one component equal to 100. This is very strange to me.

EDIT: Removed an edit which was obviously wrong for linear tone curve.

I think that the mapping for RGB is simply (r,g,b) → (f(r),f(g),f(b)), where f represents the curve.

The problem with Spike_V100 was that it had (99,0),(100,255),(102,0) points (102 instead of 101 for the last one, because PL8 “corrected” entered 101 value to 102), and PL8 internally changed f(100) and f(101) values, probably to smooth the curve. This was what confused me.

I managed to get a good RGB spike at 98, i.e. curve with points (97,0),(98,255),(99,0):
Spike_V98.preset (666 Bytes)
This curve is for some reason not “smoothed” by PL (how it could do it?), and the formula holds. Conversion to floating point numbers and roundings may also interfere.

For Wide Gamut, the input (r,g,b) (assumed to be in sRGB) are first transformed to WideGamut before applying the above formula, hence different outcome.

I used the 16 million colors 16-bit TIFF provided by @Wlodek (See above) to test this speculation … and confirmed that the Gamma slider on the Luma channel does do a better job of “brightening” an image - c/w using the Gamma slider on the RGB channel.

  • I created a VC of the image, and applied Tone Curve = “Linear” for both the (M)aster and the VC versions … then;

  • For the (M)aster version, I set the Gamma slider = 2.5 on the RGB channel - - and the Gamma slider = 1.0 on the Luma channel.

  • For the VC version, I applied the opposite settings … setting the Gamma slider = 1.0 on the RGB channel - - and the Gamma slider = 2.5 on the Luma channel.

  • Then, using the Compare button, I checked the result on both versions … to find much better colour retention for the VC version - whilst achieving “just-as-good” brightening (according to my eye) to what was achieved for the (M)aster version.

1 Like

Something I’m finding quite annoying, when for comparison purposes I’m applying different settings to different channels across multiple images, is that channel selection is not “sticky” !

That is;

  • Every time a new image is selected (from the Image Browser), focus always returns to the RGB channel.

  • So, if making (for example) changes to the Gamma slider for the Luma channel on multiple images - one must be diligent to re-select the Luma channel after switching to a new image.

2 Likes

You can copy/paste just the ToneCurve to multiple images and then fine tune the gamma individually, without having to select L each time. But you probably know it very well and so the “stickiness” point holds.
EDIT: Oops, that doesn’t work either. Sorry.

Some other basic observations:

  • On grey pixels L curve operates as expected, with a small error (up to 4% ?).
  • For constant L=0 curve (i.e. only with (0,0) and (255,0) points) you will not get completely black picture, like you would get for the RGB version (although all greys will go black).
  • Similarly for constant L=255 curve (i.e. only with (0,255) and (255,255) points) – you will not get completely white picture, like you would get for RGB=255 curve (although all greys will go white).

I think that most tools in PhotoLab return to a default state when changing images and in fact I prefer it. It may be inconvenient if you want to apply similar settings individually to multiple images, but most of the time I process each image separately and want a standard starting point .across all the tools. There are a few sticky features that I don’t care for, most notably the global HSL color wheel’s hue picker and the selected color range which I have to remember to reset when changing images . I also have to remember to deselect the most recent LA mask when changing images, which I find annoying.

Mark

Yes - that’s VERY annoying !!

A “nice to have” …

For the HSL tool we can Click-&-Hold on any of the channels and the settings for that channel will be momentarily re-set/undone … which is a great help in evaluating settings for that channel

It would be great if the same feature applied for Tone Curve channels … To reset (say), the Luma channel to a Linear curve (just for the time that we Click-&-Hold on the “L” channel).

2 Likes

YES, still a real bug since PL7 and if there is a reason to keep the LAs edit mode active,
it shows the need to reinsert a visible LA icon/switch in the top bar like in PL 6.

@DxO_Support-Team

4 Likes

I don’t believe it’s a bug, as such - - It seems to be a conscious design decision by DxO (since PLv7) to make PL “mode-less” … but I’ve never understood the supposed benefit of that (?!)

3 Likes

Whatever you call it, removing the prominent “You are in LA edit mode” indicator from the top bar is a mistake.

3 Likes

…I suggested this ten years ago…quite important in my opinion…and DxO liked it…well, it had been standard in Photoshop since the beginning if I remember correctly…
I couldn’t believe that a program that considered itself “professional” wouldn’t see this feature as something absolutely fundamental and necessary
(I’ve been using DxO since version 6 – DxO Optics Pro as it was called then)

3 Likes