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.
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.
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.
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.
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).
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!
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.
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).
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.
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).
Because this module is relatively new, and perhaps some users already learnt and get used to it, especially when itās their first time use a colour balance to colour grade a photo, I guess not many will notice the difference (itās just my opinion, sorry if Iām wrong), how about an adding experimental feature so that user can try and give their input of which one is more intuitive to use?
Personally, Iāve got no issue with current behaviour, but now that you mention it, Iām curious about how to use it in bare RGB. So either way is fine for me.
*edit: now that I look at it again in resolve, I forgot the luminance mixer is also adjustable near the colour wheel, so I guess it always works in YRGB, and I occasionally adjust the mixer to zero or 100 (or in between) depending on the task. Kinda like normalize channel in colour calibration/mixer.