ACES open source software pipeline (blender, natron)

I would ask, why not grading in linear? There should be no reason to grade in a tool like Natron(Nuke) in a log space.

We would like to composite CGI (made in blender) with real camera footage (different cameras with different colorspaces). We thought ACES could be useful for camera matching and we are trying to figure out how to add blender in the ACES pipeline. We aren’t interested in keeping the filmic look for the real footage, and after some testing using 100% ACES in the pipeline it’s not working for our eyes.

After reading Mr. Brylka’s Blender-ACES approach (thanks!) & this discussion devtalk.blender(dot)org/t/blender-support-for-aces-academy-color-encoding-system/13972/193

I will summarize in my own words and understanding:

  • ACES v1.2 comes with a lot of issues in it (wide gamut compression, etc)
  • Blender has its “limitations” in a ACES pipeline

I’ve also read this really interesting reflection chrisbrejon(dot)com/articles/ocio-display-transforms-and-misconceptions/

So maybe we could use this approach:

We are not sure how to implement this the right way.

Will it be practical and possible to implement this workflow using Blender and Natron? (we are trying to keep the pipeline in a 100% open source software environment)


Curious as to why you think that ? One could grade in log in Nuke quite easily and would obtain interesting results.


Hi Chris,

sure, you can grade in a log space, but the Grade node and the ColorCorrection node expect a linear working space, right?

I would see it like working with log images in Photoshop under a SoftProof LUT: It’s a workaround, but PS tools are expecting pixel values between 0% - 100% and are harder to control when they are all compressed to a small range in a log encoded image.

Or take Resolve:
Another way to look at it is to use a 0-1 ramp from Nuke as an EXR and DPX (logC for example) and load them into Resolve (without ColorManagement).

Lift, gamma and gain work best on the linear ramp when you check the waveform.
And the log tools shadow, midtones and highlights are working best to manipulate the DPX image.

Nothing is holding you off to use whatever combination you like, but tools are made for a certain type of input. So you are right, sometimes you can achieve interesting results, other times you might fight against the material.

Does Natron support OCIO nodes or something like the Vectorfield node to apply a 3D-LUT? Then the described workflow is easy to setup.

But, be aware that certain highly saturated colors might shift (I saw it with reds and yellows) and the black level of the signal as well when using the so called “no-operation”. It is still a hack.

Another way I could think of is:

  • unify the camera colorspaces to acescg in Natron
  • working in blender in linear-sRGB/Rec709 (view with Filmic) and load them into Natron as linear_sRGB/Rec.709
  • now you have everything in acescg
  • more color matching might be needed, because couldn’t light the 3D in the same working space as the plates.
  • You can use the RRT &ODT of your choice.

As far as I’m aware lift, gamma, gain has always been an essential part to color grading and I don’t know any colorist grading in linear aside from switching temporarily to it to adjust scene exposure perhaps but not tonal/artistic control. Maybe this is different in the CG/VFX industry but you can make both methods work I guess.

The latest OCIO config of ACES does support the Reference Gamut Compression. Haven’t tested it yet though.

Workflow wise limitations in Blender can be worked around by adding the RRT+ODT as a display transform into the Blender filmic config so you can keep working in linear srgb but previs with the ACES look so it will match what you’ll end up seeing in Natron. This isn’t the same as rendering in ACEScg ofcourse but this can be a choice.
I’ve tested this setup some time ago and worked quite well from what I could tell. Sharing my config here.

As to having the look of other rendering systems inside ACES maybe this topic can help.

For the rest of the workflow I’m with the what Daniel suggested above this post.

1 Like

I only said, the grade and color correction nodes in nuke expect by default a linear working space.

For the Resolve example: Its only showing where the grading tools “work” on the image data.
Sure, I also don’t know any colorist in Resolve who is working in Lift, Gamma, Gain with linearized image data.

Hi, could you “simply” build an ARRI K1S1/ALF-2 OCIO Config and roll with it ?


I often refer to this thread when I talk to my colleagues about this interesting topic.

Maybe it helps a bit,



One approach could be to read all the camera footage into (free) Resolve, possibly applying the ACES gamut compression if needed, and export as ACES-2065-1. That would bring all your stuff into a unified color space.

Thanks Chris,

just yesterday I watched the amazing video from Jed about the " The Math of Color Grading in Nuke" (and I guess in most cases this also counts for Natron).


I don´t think this supports the Reference Gamut Compression. It is an ACES 1.2 OCIOv2 config, right ?

Thanks !

I might have misunderstood perhaps, but from that thread:

The Reference config from that same release does have an LMT for RGC and the legacy Blue Light Fix.

- !<Look>
    name: LMT - ACES 1.3 Reference Gamut Compression
    process_space: ACES - ACES2065-1
    description: |
      LMT (applied in ACES2065-1) to compress scene-referred values from common cameras into the AP1 gamut
      ACEStransformID: urn:ampas:aces:transformId:v1.5:LMT.Academy.GamutCompress.a1.3.0
    transform: !<BuiltinTransform> {style: ACES-LMT - ACES 1.3 Reference Gamut Compression}

Those are two different configs :

  • The CG one without the RGC, usable in production.
  • The Reference config is for developers to check their OCIO implementation.

Sounds correct ?


Yes that would be correct! Would it be a bad thing to add the LMT from the reference config to the CG config?

I don´t know… It is worth testing ! The RGC would only be available with a software which has implemented OCIOv2.1.0 ?


Yea I know, I looked it up before making that suggestion initially and Natron does already support OCIOv2.1. I didn’t do a proper difference test yet but dropping it in Natron on the lightsaber exr gave me the same result as in Resolve with ACES Transform node ACES1.3 + RGC judged by eye.

Cool ! You did your homework ! Much better than me !

Thanks for cheking :wink:


This is all correct. The configs are for ACES 1.3 which requires OCIO 2.1 which is not currently supported by any DCC software to my knowledge.

If folks are interested, I do have an OCIO 2.0 config that has Reference Gamut Compression implemented as an LMT using the LUT made by @matthias.scharfenber.

I wrote up some docs for the configs, the Gamut Compression section is here:

Here’s the relevant part:
The ANM config uses Reference Gamut Compression (RGC) to address hue shifts in CG colors. Here the RGC is automatically applied in the view transforms of the ANM OCIO config, and also baked into the output when writing out to sRGB using 3D LUTS. This is accomplished with a 1D shaper function that transforms both negative and positive input value ranges into the 0.0→1.0 domain, essentially the ACEScct function mirrorred at the Y-axis.

The VFX config in contrast does not have RGC as a view transform or output and instead uses the Nuke Gizmo.

Feel free to play with it. No warranties, and note the caveat that there are limitations of the implementation of this as a LUT (as opposed to the analytical transforms). Because of this, the way I work with it is to only use the LMT for viewing, and never for output. For that I use the Nuke node.

1 Like

Really interesting thread about the grading physical phenomena aspects in linear and grading perceptual phenomena in log. We’ll apply that in our workflow.

We thought ACEScc was the designed space for grading (as indicated in the oficial ACES documentation), but we agree: “ACEScc is quite difficult to use because it is not a physical nor a perceptual space”.

ACES pipeline

  1. We discard any Resolves approach (Resolves it’s partially free, but not open-source, our goal is implement the pipeline 100% open source-software for this project)

  2. The OpenColorIO-Config-ACES 0.2.0 approach using the LMT from the reference config it’s really interesting but maybe is quite experimental for our production, at this moment.

The ARRI-LUTs approach seems the way to go for us. But we are stuck in some points in the workflow:

  • in Blender render [.exr in srgb-liniar]
    • adding the RRT+ODT as a display transform into the Blender filmic config for the previews as suggested by Mr. Shebbe
  • in Natron Read blender.exr [FileColorspace=Utility-linear-srgb Output=Utility-liniar-srgb] →
  • → [Color Grading] (for physical phenomena)
  • → [OCIOcolospace (Input:Utility-liniar-srgb // output:ACES2065-1)
  • →Merge with real footage (previously to ACES2065-1)
  • → OCIOFileTransform (ARRI-LUT => Scene-linear WG to Log-C WG)
    • At this point the generated arri-lut gives us all these EI options:

    • Which Exposure Index should we use? Are we using the right ARRI-LUT to get the LogAWG?
  • → OCIOFileTransform (ARRI-LUT => Log-C to Classic 709=K1S1)
  • → [Color Grading] (for perceptual phenomena)
  • → Invers ODT & Invers RRT = Help needed here! OCIOcolorspace (Input:??? Output:???)
  • → WriteNode (Input Colorspace:??? Output:Output-sRGB /// Output:Output-P3D65)

We really appreciate all your tips and insights! Thanks a lot!