ACES open source software pipeline (blender, natron)


We are using Blender and Natron in our pipeline and we want to implement ACES.

We are using Blender with default OCIO (filmic) exporting in EXR (liniar) and we are compositing in Natron:

Blender render to => EXR (liniar sRGB)

in Natron:

[ ReadNode blender.EXR (using blender config.ocio for this node) File Colorspace:liniar // Output Colorspace:liniar ]


[ OCIOColorSpaceNode (Blender config.ocio) Input Colorspace:liniar // Output: display/Filmic sRGB ] (we would like to integrate filmic look in the process)


[ OCIOColorSpaceNode (ACES config.ocio for this node) Input colorspace:Input-Generic-sRGB-Texture // Output Colorspace:ACEScg ]


[ Color Grading ]


[ MergeNode (some Compositing here with some textures created in Krita in ACEScg) ]


[ OCIOColorSpace Input:ACEScg // Output:ACEScc ]


[ Color Grading ]


[ Merge with footage already converted to ACEScc ]


[ Color Grading ]


[ WriteNode Input Colorspace:ACEScc // File Colorspace:Output - sRGB ]


[ WriteNode Input Colorspace:ACEScc // File Colorspace:Output - P3D65 ]

Would that be right? Thank you

To honor the blender filmic look you would need some kind of LMT to modify the look right before the output transform at the end. I don’t know how you’d go about creating that or if it exists already.
What’s your general goal of wanting to use ACES if you want the Filmic look anyway? Why not just use the filmic output transform at the end?

1 Like

I would to decide too for one of the two view pipelines:

  • Use Blender (Filmic) to light, shade your scenes.
  • Render EXR (linear-sRGB)
  • Comp in Natron and use the view transform of Filmic as well.
  • If you need a DCI-P3 output, I guess the easiest would be to ask @Troy_James_Sobotka. Maybe this exists already?
  • Use Blender (ACES) to light and shade your scene directly with the working space ACEScg.
    (From my test results I would not recommend it, because of too many limitations at the moment.
  • 1.5. Blender & ACES Limitations – Brylka – TooDee – PanicPost
  • Render EXR (ACEScg)
  • Comp in Natron with the same ACES OCIO Config.
  • Use your desired output transforms.

Although I would find it very risky to go this route, at least you would view in all tools the same view transforms.

A third option would be to stay in Blender (Filmic) as in option 1. and import the finished comps as EXR (linear-sRGB) into Resolve and do the grading and mastering there.
You can use the Filmic LUTs there as well or use Resolve’s RCM2 or ACES with it’s view transforms.

The moment you change the view transform you also alter the look of the film. This can be okay or a problem and should be tested first.

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.