It is possible if that is what you require, yes, but it also gives you an opportunity to nail the white value by simply forcing a +0 EV correction at +0 EV exposure level. The color balance RGB gives you no such option.
I see. But then I would say that a true s-curve like this would be a safer default for increasing global contrast with the tone equalizer.
(and now I will stop talking about it here, because this thread is for color balance and Iām national champion in derailing conversations)
1 Like
But then what is the difference with increasing contrast directly in filmic?
My understanding:
- In both color balance rgb and tone equalizer, you add contrast to the scene-referred, linear data. In filmic, you adjust the steepness of the tone mapping curve, potentially āoverstrainingā it, which can lead to clipping due to the constraints placed on the curve, which you have to fix by backing off on the contrast or lowering latitude.
- Usually, you donāt mask filmic, and donāt apply multiple instance in the way you can do with color balance rgb and tone equalizer. (Though I have seen a ādouble-filmicā trick by @s7habo, but thatās bordering on black magic for me.
Even that one did not use masks, if memory serves me well.) - In filmic, you have no control over the fulcrum (itās mid-grey). In the other two modules mentioned, you do.
2 Likes
Filmic deals with remapping dynamic range between different media. Whatever you do in there falls back to the basic question : āhow do I want to drive the dynamic range trade-off when going to SDR ?ā.
Color balance is an artistic module that doesnāt care about output medium.
1 Like
In the documentation:
https://www.darktable.org/usermanual/3.6/en/module-reference/processing-modules/color-balance-rgb/#what-is-the-connection-with-liftgammagain
The lift/gamma/gain algorithm relies on a display-referred color space, since it assumes a bounded and symmetric dynamic range, with white point at 100% and gray at 50%. As such, it is simply unusable in a scene-referred space. However, the only incompatible part is the lift. The gamma is exactly the ASC CDL power, and the gain is exactly the ASC CDL slope.
The part quoted above, with lift being non-linear (addition), is about the original ASC definition, right? And in darktable color balance rgb, the same term, lift is used, but in reality, a gain (multiplication) is applied to the pixels deemed to be ādarkā based on the mask:
The color balance RGB module simply has two slopes instead of one: the gain, applied on the highlights extracted from the whole image by a mask, and the lift, applied similarly but on the shadows.
Is this correct?
In lift/gamma/gain, lift is a slope or gain applied to inverted RGB: RGB = ((( 1 - (1 - RGB) * lift)) * gain)^{gamma}. Itās not an offset, aka an addition. Only the ASC CDL has ever had an offset. So, to avoid the inversion by 1 (display-referred white), the modified CDL in the current color balance has 2 different slopes with alpha masks.
2 Likes
As people more often write with queries and problems, here is some feedback on how great I find the new colour balance rgb module in darktable.
If love the way that you can easily add more saturation to darker colours and less to lighter colours. It really allows you to add richness in colours to photos but avoid straying into garish territory. (I know this is just one of many ways of adding contrast and saturation to photos but it does easily offer you a degree of fine control).
Thanks everyone!
7 Likes
Yes, and together with the vectorscope I can now get perfect skintones, fixing the reddish skin out of my Sony cameras.
At every major release, I play with some of my old edits to see if I can get better results with the new tools and I have to say that DT keeps improving so much that I would like to reprocess/reprint al my pics 
A big thanks to the devs team!
4 Likes
Yes, this is the exact āproblemā Iāve had in the last 2-3 releases as well. 
Same here! Soon, reprocessing old photos will be my full-time jobā¦ but unpaid, which means itās a terrible job.
What is the use case for offset in color balance rgb?
Iāve been doing some testing of color balance rgb using a black to white horizontal gradient.
For offset, the manual says āThis is equivalent to the ASC CDL offset and falls back to adding a constant RGB value to all pixelsā.
In this screenshot, Iāve applied an orange hue at 1% chroma in offset. As you can see, the shadows have gone a purplish colour, then thereās a white band before a more gradual orange colour is applied to the midtones and very little in the highlights.
Iām sure thereās a good reason for this (out of gamut, clipping, screen profileā¦?), but Iām left wondering what the use case for offset is. When is it the right tool to reach for, as opposed to power for example? I watched AurĆ©lienās video and I noticed he used offset in his examples, but I didnāt really understand what offset was doing that the other sliders couldnāt do.
In a colour grading application (like davinci resolve), iāve used offset to lift/drop the entire waveform at a constant value (itās quite useful when dealing with under/overexposure, low contrast/log image/footage), and after that use the other slider (lift/gain/power) to set the contrast. And using the hue and saturation to add/remove colour cast globally (like in white balance).
What I found itās quite hard to do it in dt as I do in another software (eg. resolve), because filmicRGB is come after this module, it is influenced by the roll-off curve, thatās is why it goes to neutral/desaturated on the shadow/highlight portion. And, somehow thereās always something that makes the upper portion of the waveform sticks to its position or edge, maybe black/white point. So when I need to tint the overall image, Iāve used the 2nd instance of the colour calibration module, or create another instance of colour balance RGB after filmic (I donāt know if itās the right way or not).
I guess I just need to adapt this behaviour more because different software sure has a different processing pipeline.
I think I want to ask this as well, isnāt Offset slider (in ASC-CDL) supposed to be an addition/extraction to the entire value/range? When I used it in dt, it feels like itās not simply āoffsettingā the graph (exposure/colour).
I use it to shift a specific color to another color. Especially in my infrared shots. I will often use it with a mask to isolate specific colors
Yes, this was my understanding but the behaviour I see onscreen doesnāt seem to match.
Isnāt the hue shift on the master tab more suited to this? Maybe not, but my messing with offset doesnāt seem to be a reliable way to do it as per the screenshot above because the colour changes across the luminance range.
Yes, and thatās what it does in color balance too, although we have an YSL interface before going to RGB.
If you raise red at constant luminance, it makes green and blue plunge out of gamut at some point. Give it a slight luminance boost too, that should bring them back to positive values.
Ah, I see, thatās why it feels like itās not offsetting like I thought it would be, because it goes to the intermediate Y channel first. Even in applications like resolve (sorry if I mention another proprietary software, itās not like I compare it or anything, I just wanna understand this module more), thereās an option in preference to set the Y channel of YRGB parameter to zero, to become an ASC-CDL compliant adjustment (and i remember always turn this option on).
*Sorry if I used the wrong term up there.
I can always double the UI with a bare RGB instead of YSL if there enough demand. Itās just a re-encoding of the same thing.