The color balance node in the compositor can be switched to use the ASC CDL
How is it used?
How is this different from Lift/Gamma/Gain?
How do the Offset, Power, Slope options affect the image?
It's designed to create a standarized protocol to share basic color correction data across different systems form different vendors. It is a protocol that can be applied to either scene referred linear or log-like encoded imagery. The following outlines scene referred as Blender’s reference space is scene referred. Care must also be taken regarding white points and chromaticity, as using the CDL on work encoded differently to your reference will yield randomly different results, and the CDL is not a means to uniform grading changes alone. Reasonable advice is to not grade work prior to compositing, and grading should be the very last step of a pipeline.
It should be noted that applying the CDL on linear and log-like data has two completely different results. They include:
The functions that the ASC-CDL node provides in blender are:
Scene Referred Data is multiplied. 0 remains unchanged. Slope can be any number greater than 0. Default Value is 1. Corresponds to a uniform exposure adjustment when Power and Offset remain untouched.
Data is added. Raises or lowers overall brightness. Offset can have positive or negative values. Default value is 0
Note: Blender's CDL node currently allows for negative values via the strange "Basis" entry box because of Blender's decision to not permit negative values in the UI. (It is best to leave this one untouched, unless you absolutely know what you are doing).
Data is multiplied by itself ^ amount of times. Power can be any number higher than 0. This function is considered "non-linear", as it changes the shape of the transfer function. The default value is 1
To expose the values and do precise numeric editing of any of the values click on the color box at the bottom of the big color circle to expose the RGB values used for the node's transform operations:
NOTE The CDL works only via RGB values. Working on HSV or HEX does not work correctly due to their nonlinear encodings. Also, the input to the CDL node must be scene referred RGB ratios. No other colour encoding model will work, so avoid any transforms in your node chain that change the format from RGB.
Even though the node in Blender is arranged differently, the order in which the transformations should be executed is SOP
The final formula to calculate combined transformations is then:
Slope= input x slope
Offset= (input x slope) + offset
Power= ((input x slope) + offset) ^ power
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.
Lift, Gain and Gamma vary in definition between different systems and manufacturers.
In the case of Blender's color balance node, it is vaguely defined like this on the manual:
Lift Increases the value of dark colors. Gamma Will adjust midtones. Gain Adjusts highlights.
There is no explanation on what that means, and where the thresholds for shadows or highlight begin or end.
To appreciate the nuances of the difference, it helps to look at how the formulas behave, and in particular, behave with scene referred data.
Here's the code for the ASC-CDL node:
float x = in * slope + offset; return powf(x, power);
And here is the code for the Lift, Gamma, Gain node:
float x = (((linearrgb_to_srgb(in) - 1.0f) * lift_lgg) + 1.0f) * gain; return powf(srgb_to_linearrgb(x), gamma_inv);
So aside from looking like mumbo jumbo gobbly gook, I'd encourage you to look at the line in the Lift, Gamma, Gain operation where it takes the linearrgb_to_srgb(in) - 1.0 value. Sadly, aside from an extremely myopic function name, there is a subtract from one, and an addition to one in there. This is the tell-tale mark that some bad assumptions are at play.
This speaks volumes about the nature of the formula. That is, it is display referred the moment you make grotesque assumptions about the values you are feeding into it. In this case, the 1.0 represents a maximum assumed value.
Of course, in scene referred imagery, there is no such thing as white, no such thing as black, and no magical values you can lean on that mean anything in particular. Cycles generates just such scene referred values, and as such, feeding a Cycles render through Lift, Gamma, Gain will not only not work at all, any results it delivers will be absolutely and critically broken beyond belief.
So, using Lift Gain and Gamma only works on information with a range of 0 to 1, making it unusable for those trying to work with higher dynamic ranges with much larger values.
The CDL has no such limitation. It can work on RGB values of any range.
Many formulas passed down through Stack Exchange and other sites with information all too frequently assume things about RGB that shouldn't be assumed. While Lift, Gamma, Gain is one such display referred assumed formula, there are many other traps like this. The AdobePDF specification lists many of them, and many of those formulas have sadly ended up in scene referred image manipulation applications. Screen, Overlay, Hard Light, Soft Light, etc.? Yes... all display referred and all will mangle your imagery.
Beyond the basics of the formula simply not working, the ASC-CDL is a canonised function defined by the Academy. That means there is a specific specification that stipulates that in order to call itself the ASC-CDL, it must abide by the specification. Further still, because of this, you can find ASC-CDL transforms in many different applications. Unlike Lift, Gamma, Gain, if an application chooses to implement the standard, you can be reasonably sure (bugs notwithstanding) that it is identical across applications, assuming the caveats in the introduction are held to; different input data formats will yield different output even with identical CDL values.
Finally, because the ASC-CDL is a referential baseline, you can also find unique applications for the ASC-CDL, such as the ability to apply hand-crafted ASC-CDL values into a colour management system such as OpenColourIO, enabling an imager to quickly use Looks they have generated previously. Not only are you able to use a variety of different techniques to achieve this, as expressed in the previous notes, you can be quite certain that the formula is the formula you expect.
Even though ASC-CDL nodes in other apps have the ability to save their settings into a file, so that it can be used across different programs and vendors, Blender does not offer such capabilities yet. Manually creating an .XML file with the data is possible, and the color decisions translate (and can be reversed) across platforms. The beauty of this is that if you are saving to OpenEXR with no color correction baked into the image, you can set looks that can be reproduced on other systems. Or if the color correction has been baked into the image in an EXR file, it can be reversed on other systems for further grading.
How to create the text file would need to be the topic of other question.
In the end, it is up to an educated imager to be aware of the upside and pitfalls, and choose their tools based on solid foundational knowledge.
For more information on wide dynamic range rendering please refer to this post: Render with a wider dynamic range in cycles to produce photorealistic looking images
See also Mike Most's discussion about the CDL.
Main source used: ASC-CDL_Release1.2 by Joshua Pines & David Reisner, 2009