color balance rgb is a very sophisticated module, and supports scene-referred editing. By default, it comes before the tone mapper, but if course can be dragged above. It expects linear scene referred input, so feeding it display-referred data may not be optimal.
As for separating out the look: moving it outside the agx module would create different results. Here is the order of operations and adjustments – notice that look is not the last element, and its location cannot be modified without altering the effect:
- linear, scene-referred data arrives in the pipe’s working space (e.g. Rec 2020 or whatever is set in the input color profile)
- if needed, it is converted to the selected ‘base’ space
- colours that are out-of-gamut for the ‘base’ space (RGB triplets that have any negative component in that space) are ‘slid’ into gamut (I use this term instead of compression, because in-gamut colour are not modified; it’s possible that a previously out-of-gamut colour ‘lands on top’ of an in-gamut colour). sigmoid does something like this, too, but the method is different.
- the ‘inset’ matrix is applied: this desaturates the colours (mixing channels into each-other), and rotates the primaries. This is the same as with sigmoid.
- the HSV representation is calculated from the inset+rotated RGB; we keep only the hue as reference. I didn’t check at what point sigmoid records the original hue.
- for each component, the same processing steps are executed independently (but, since the desaturation mixes channels into each-other, this means that in terms of the original colour, the processing is not independent at all):
- for input_x, log2(x) is calculated (log encoding) (x would be the value of the red, green or blue channel)
- the log value is scaled and shifted according to the selected exposure parameters, so the selected black point becomes 0, the white point 1, and incoming mid-grey (18%) ends up on the x-axis of the curve in a ratio BLACK_RELATIVE_EXPOSURE : WHITE_RELATIVE_EXPOSURE (by default, 10 : 6.5) (well, it’s not really grey, as we are processing a single channel…)
- the curve is applied; this produces and output that’s considered to be encoded according to the ‘gamma’. If you wish, think of it as a ‘virtual monitor’.
- the ‘look’ is applied (this is pure ‘display referred’, and is not even display-referred but in linear RGB encoding, but in ‘gamma’ encoding, like old-school editing in non-linear sRGB, but the gamma is whatever is set in the module):
- first the slope and the offset
- then the power
- finally the saturation
- these are inspired by the ACES CDL operations, but I’ve modified offset so it does not push the whole range up: it acts strongest on blacks, and becomes weaker for higher values
- the gamma-encoded data is linearised by applying linear = gamma_encoded ^ gamma (so it’s scene-referred 0…1, BUT the encoding is linear, like always in darktable’s pipeline; mid-grey is at 0.18)
- the HSV representation is calculated; its H and the original H are mixed together according to the preserve hue setting to produce the final hue. This does not guarantee complete preservation of colour, as the ‘original’ hue was already recorded after the input matrix, and after this mix, we apply the output matrix (see below), which again twists colours.
- the output matrix is applied, which:
- performs the rotation reversal (this is a difference with sigmoid: the latter always completely reverses the rotation, in agx, reversal is up to you)
- applies the purity boost (just like sigmoid)
- converts the result back into the pipe working space.
I hope that was detailed enough, without being too detailed.
If too complicated:
- conversion to ‘base space’, including gamut handling
- inset (desaturation) + rotation
- input hue is calculated
- log encoding
- curve
- look
- convert to linear encoding
- restore hue by mixing resulting hue with original
- rotation reversal, purity boost
- back to pipe space