Hi @aurelienpierre, thanks for the link! Very informative. I think it would be very interesting to see how this translates into a darktable workflow using the new tools that you are developing. A little demo would be a great way of highlighting the advantages over a more “traditional” (“display referred”? “wrong”?, I don’t know how to call it actually approach.
For my part, I tried to work with the tools that I know, which is essentially just RawTherapee. Here’s my way of trying to emulate what is shown in the tutorial you posted (just to be clear: without any ambition of being comparable!):
It translates in darktable straightforward, the only difference is the 2.5 D color wheels of Resolve are 3 × 1 D sliders in darktable. I hade even embedded a default style to produte just that teal-orange look.
I’d still love to see it in action… do you have examples that show to the uneducated (that would be me) the benefits? I’m trying to understand. I know you posted some examples earlier (or maybe in a previous thread) but iirc there was no raw/source pic attached to try things out. thanks in advance!
@phweyland, are you using colord or xatom to fetch the system display profile ? I think I have spotted a bug with xatom that applies the gamma correction of the display twice on the same picture. Using colord, I still get wrong color picker values (but that’s expected, and I know why - bad but under control), but the image looks as it should. Can you reproduce ?
@agriggio sorry, no time for that at this point, feature freeze is coming, and big colorimetric errors need to be fixed asap. Critical stuff (at least for me).
no worries, I understand. fwiw, I just implemented a basic log compression in (my copy of) RT, so I can experiment while trying to understand what’s going on… I’ll report here when I have something if anyone is interested
Sorry, I don’t know and I cannot check for few days. Not sure that I can choose on Windows, but in any case I’ve kept the default value. I’ve tried to select the specific monitor profile but dt doesn’t retain it from one session to the other.
Grading could be just the simply rgb curves or brightness/contrast sliders.
I interpret it in this way:
“You can grade on Log too with benefits compared to grading rec709 gamma transfers where the tone distribution is intended for viewing and not for processing( with a base curve and a lot of post processing like jpegs from camera).”
This is with default orange-teal colour-grading I have added as a preset in the color balance, + the filmic module I have developped these last few days with the help of Troy Sobotka (who is now estranged from here and yet was one of the few helpful, accurate and relevant contributors).
I have started to code a color correction module in photoflow, based on the ASC-CDL formulas, with the idea of making it compatible with the DT tool (I.e. same parameters = same output).
However, the DT code seems to deviate from m the recommended implementation in at least two places:
if I understand correctly, the RGB parameters are always re-normalized to keep the luminance unchanged. Is that correct? Would it makes sense to make this optional?
looking at the code it seems to me that the saturation step is applied before the SOP. However, all the documents I have found recommend the saturation adjustment to be the last one. Maybe I have mis-interpreted the code?
I am mostly referring to this post, where Troy mentions:
“Also note that blender does not provide functionality to affect saturation as part of the CDL node.To control saturation on scene referred data a custom node group needs to be created to operate after the CDL node. Maybe a topic for a new question”
The CDL transfert function in darktable is the standard one.
What you have seen, the luma correction, applies on the user input (interface) since we have HSL and RGBL interfaces, you want your HS/RGB parameters to affect only the color since you control the luminance separately. That would be super weird to control the module from the HSL interface and see the changes on HS affect the luminance.
The ASC CDL normalizes the transfert function, it doesn’t say anything on the UI implementation.
As for the saturation, darktable has other modules to control the saturation after the color balance. The interest of the saturation before the CDL is it allows split-tonings effects, by desaturating first, then changing the colors selectively.
Finally got to try color balance. So far I am only using it for neutralize colors with output saturation after using the filmic module. It matches the way I generally neutralize colours, so I like using it.