Why grading in log instead of linear?

I’m a compositor using mainly Nuke in ACEScg and I wonder why a log working space like ACEScc(t) is used most often in the grading tools?

Isn’t it “better” to use the gain in linear to adjust exposure by instance?
Davinci Resolve does not even have ACEScg as working space, so, what is the reason?

The maths of traditional grading operators was designed to operate on perceptually uniform image data, limited to the 0-1 range (and maybe a littler bit outside that at either end) such as log or “video” encodings. Scene-linear image data is not perceptually uniform, and can have values way outside the 0-1 range. Traditional grading operators working on this kind of image data may not respond in an intuitive and easy to control way.

Simple gain is an exception to this, and plenty of people transform to linear and back in order to apply linear gain for exposure adjustments. I have actually written a DCTL for Resolve which incorporates the transform to linear and back, and adjusts exposure with linear gain, although the user control is logarithmic and marked in stops.

Shouldn’t offset do just that in ACEScc? Looks the same to me. Although you don’t have the luxury to see stops as a value anywhere.

Maybe this is because I’m used to work in linear with Nuke but using color corrections in ACEScc feels a bit confusing. Two examples:

  • trying to match and adjust white balance (which is nothing more than a gain) seems to give better results in a linear working colorspace.
  • using the lift tool in ACEScc(t) does not look lifted. I understand that particularly the lift is made for a range between 0-1 because the pivot is at 1, but in ACEScct, this tools does not look to lift the black. It looks a bit more like a slight variation of the gamma/power.

The offset is a pure addition on all the values. Gain is a multiplication which is equivalent to 2**stops I think. I’m not sure that using offset to adjust exposure is the way to go because it will change your blackpoint.

EDIT: I compare and indeed you’re right: gain in linear is offset in ACEScc!

For values >0 it is. ACEScc does not code negative values because it is a pure log coding, with no “toe”.

With ACEScct (or any camera log coding) offset is equivalent to linear gain in the logarithmic part, but is noticeably different where the offset moves values into or out of the linear portion of the curve.

Here is a plot of the curve adjustment needed to match exposure changes in ACEScct. As can be seen, it is a simple offset in the upper part, but very different at the bottom:



the whole subject is a bit more subtle:

The ideal space for an operation depends on what you want to simulate.
If you are after modelling physical phenomena, then some sort of scene linear is probably the right domain. If you want to model perceptual phenomena, then typically a perceptual space (like a quasi-log or opponent space) is the right thing.

Some example:

  • If you want to do white balance/exposure, multiplication in the linear domain is the right thing to do.
  • If you are after simulating an optical blur also linear light is the right space.
  • If you want to sharpen an image, then log is the right domain because there is no physical process of sharpening a scene. (Sharpening is probably happening in our neural pathway)

It becomes tricky if you do things that incorporate several things at the same time. Scaling, for example, has both a physical component (anti-aliasing) and a perceptual component (sharpening). So there is not really a right or wrong way. Most of the time, you scale in quasi-log because the disadvantages of the sharpening components produce artefacts in linear (overshoots).

Modern colour correcter tend to develop into the direction that each operator is operating in the space appropriate for its design goals.

For the argument of addition in ACEScc vs multiplication in linear:

The result might be identical for the operation of a white balance or exposure change. But you should not forget that ACEScc will put the image into a state which overemphasises the energy in the shadows. Subsequent operations like saturation changes or scaling might not work correctly in ACEScc with lots of “dark energy” :-).
So ideally you do white balance in linear and then convert to a quasi log representation for things like sharpening or scaling.

I think generally ACEScc is quite difficult to use because it is not a physical nor a perceptual space.

Then legacy tools have lots of “assumptions” build into them.
FilmGrade (Offset/Contrast) assumes that the image is encoded in a cineon like quasi-log space. This is for what this particular tool was developed for.
Same is true for legacy keyers and other tools. The same way most of the compositing tools were designed with the assumption that the image data is presented in linear light.

I hope this helps.


Great post @daniele, there were quite a lot of discussions recently around that topic and you brought some really good examples!

1 Like

Amazing post Daniele, I wish we can have your knowledge more often around here :slight_smile:

Thanks ,

I am glad it helps.

1 Like

Thanks @daniele I really enjoyed your post.

It really does highlight the base need to understand where and why you’re performing the specific colour processing that your are. There is too much mis-information driven by antiquated pipelines and photochemical film based advice, than warrants.

Thank you for speaking frankly in that there are real trade-offs between a physical-based phenomenon and a perceptually based phenomenon…

These are the details that regularly get swept under the rug and provide a true disservice to all that don’t even understand the basics. It all falls back to conventional-ism…

Hi Vincent

This is a link to a Flame workflow, but some situations might also apply to Nuke but I’d guess Nuke is more scene linear oriented .


Daniel, thanks for your comments. BTW, I’ve appreciated your videos, if anyone else has missed them: https://vimeo.com/298129056 https://vimeo.com/298131298


Welcome Peter! Thanks for your first post on ACESCentral!

1 Like

Thanks Steve,

So much helpful information on this site, it’s a great resource.


1 Like