Using ACES in Natron

A few days ago I made a post about some issues I was having setting up ACES color management in Natron. It turns out I was stupid and did something wrong while copying files and I fixed it so that post has been deleted from this forum.
I’m writing this post so that you all know how to set up ACES (or any other) color management in Natron.
Download the Color Configurations ZIP file from

Extract it somewhere
And copy the aces_1.1 folder to this location:
Then open Natron preferences and in the Color Management settings select aces_1.1

Save preferences and restart Natron.
And voila.

  1. Natron will automatically detect the color space of sRGB files as sRGB (D60 sim.) so you’ll have to manually change it to Output - sRGB.
    You can select which ACES color space you want to use for compositing (All compositing will take place in the selected color space and not default Linear):
  2. You’ll also need to add an OCIOColorSpace node AFTER all the compositing is done and set it to convert from ACES to the delivery color space.
  3. You’ll need to set the viewer color process to Linear (None) to be able to view a “correct” preview. I don’t know whether there’s any way to load custom viewer processes in Natron and The ACES RRTs are not showing up in the menu so Linear is the closest you can get to the correct image.

Now you can use ACES in Natron.


Can’t you put an OCIODisplay node before the viewer to apply the RRT?

1 Like

Yes that’s one way to do it
But I think it would be better to have the RRT in the Viewer Process menu like how Nuke offers them:
(From Color Management in Nuke: OCIO and ACES on Vimeo)

Having the one OCIODisplay node makes no difference though, especially because its always at the end before the viewer node.

Although it must be noted that even with the OCIODisplay node added, the Viewer Process must be set to Linear (None). I don’t know what is the reason for that.

When you select the RRT, Nuke actually inserts a hidden OCIODisplay before its viewer.

In Natron, when you select sRGB in the viewer, the viewer does the linear->sRGB conversion. If you insert an OCIODisplay before it, the OCIODisplay does the linear->sRGB conversion, and the viewer must then be set to linear (which means “no conversion”), since its input is already sRGB.

1 Like

Ohhh OK I understand now. Thank you!

A little late but here’s the updated version of the OCIO config website with ACES 1.2:

HELLO im on a chromebook and i need help on knowing how to put images into NATRON read system thing???

PlEaSe HeLp

Hi, If you’re not precisely interested in ACES please open a different topic. Or maybe I misunderstood your question.

1 Like

I have tested the ACES output from Blender and it works well in Natron as described (even using my custom OCIO config including my monitor profile).

However, as mentioned, the OCIODisplay node is required right before the Viewer, which brings a usability drawback:

After that it is no longer possible to use “1” key and others to quickly connect any node to the viewer for a quick debugging. It will avoid the OCIODisplay node and the display is not useful.

The hidden-node approach as illustrated by @El_Artista would be really useful. Also, I wonder that the Write Node contains the OCIO color transformation settings, so it doesn’t need the OCIODisplay node. The Viewer node has no such settings tab/page, so I guess adding that would be another way. Or perhaps make a setting for “1” key to connect to a specific node instead of just Viewer :slight_smile:

Edit: Now it seems that the conversion in the Writer node is doing something else, so I have to add OCIODisplay node before that as well. It is not an issue there though.

You can exchange the OCIODisplay node with the OCIOColorSpaceTransform node there.

That is not advisable because pressing 1 to connect to the viewer has been standardized for a long time and changing that would cause confusion. It should just be updated to work like Nuke.
We could make it so that the Viewer node has OCIO settings so that the OCIODisplay node is not needed in this specific scenario. In my opinion, that would be a much better solution but I’m not a developer so I can’t say whether that’s doable or not. It doesn’t sound like it would break things, though.

An alternative solution would be to add a Switch before the OCIO Display, which avoids switching manually in the node graph. You can select the switch value with the mouse, and use up/down arrows to switch between inputs. I never fiddled with that, but maybe there’s a Python way to use keys to change the Switch value without having to select it.

Note that if you use two viewer inputs, you should have two ociodisplay nodes.

When using OCIODisplay, you must set the viewer input colorspace (above the viewer) to “Linear”, or the viewer will compose another transform with the OCIODisplay transform.

Never use OCIODisplay for anything else than viewing: This is not a colorspace conversion node.

The Writers have “Input colorspace” and “File colorspace” parameters and do the conversion internally, which is exactly the same conversion that is done by OCIOColorSpace, so you shouldn’t have to prepend an OCIOColorSpace (). You must set both correctly in the Writer.

If you really want to use an OCIOColorSpace node just before the writer, you must set both the “Input colorspace” and “File colorspace” in the Writer to the “Output colorspace” of the OCIOColorSpace node, so that it doesn’t perform any further conversions.

I know that OCIODisplay should be inside the viewer node (as in Nuke). This was done in the (abandonned) Natron3.


@El_Artista once you get something that works correctly (maybe using the tips I suggest in my previous message), could you write a doc on it?
Basically, that’s compiling the messages in this thread in something easy to read, with the same screenshots you have.

1 Like

I will be busy this entire month and maybe the next month too but I’ll definitely add it to my to-do list.
@Shrinks99 and @Songtech-0912 are working on a new website and maybe a new page for the docs too, so I think we can wait till that’s sorted out.

In that case, @vkovalcik you need to add an OCIOColorSpace node/set the color management settings in the Write node as Frederic said.

That is true but I still prefer to leave those settings to the working color space and add a separate OCIOColorSpace node for better comp readability. Both ways are valid.

Got it.

This post was made with ACES 1.1 and I haven’t been able to do much work with ACES 1.2 in Natron as of yet and I do not know if there are any (major) changes to the way it works. So when I get the time, I will experiment with ACES 1.2 and write a doc on the new version.

@rodlie is making some time to work on Natron, so maybe you can ask him whether it is possible.

Should be noted that as of now any docs overhauls will come later (post launch of new site) and any work on the content would be separate from what we’d be doing with the docs (just theming).

1 Like

@El_Artista, @devernay: Thank you both, I appreciate your replies!

I will consider the solution with switching, although it is hard to plan what to debug. I am mostly beginner, so I need to see the outputs of many nodes :slight_smile:

You are right, placing the OCIOColorSpace before the Writer works. The color conversion inside the Writer doesn’t seem to be working correctly - it outputs different colors. I am using ACES 1.2, so maybe there is some incompatibility (?). But I run into some quirks, so testing it is difficult.

I was even able to isolate one weird behavior and I can share a project file if anyone is interested. For a simple graph I keep switching between two values, but it acts as if there were three values. So those don’t even match with what I am seeing in the checkbox.

(I hope 600 kB gif will be ok)


It is not limited to changing a checkbox value, it “randomly” switched to black output on other occasions as well, but this is an easy way to demonstrate it.

It doesn’t do this for a freshly created project, but this is a project where I deleted other roughly 20 nodes and it happens after starting Natron again and load it.

Update: I suspected ShaderToy or Roto nodes, but after a few tests with a new project this behavior starts to appear after adding a few Read and Merge nodes. It can be “fixed” by disabling the GPU rendering in the preferences. (I am on Windows 10, with Nvidia 1070, Studio Drivers.)

Update 2: BTW I also tested setting OpenGL Contexts to 5, as stated in the troubleshooting, but it also works incorrectly. Slightly better, but still too fragile to use. So no GPU for now.

Copy that.

1 Like