Shorty Series
Version 1.0, Updated Month Year using Octane 2026.1 and Cinema 4D 2026.1
~1,100 words, average read time: 10 min
About this guide
This is a “shorty” guide (about 1,000 words) that hyper-focuses on one single setup within Octane. In this case we’re looking at the color management changes in C4D 2026 and how to cope with them as Octane users.
Right. What’s all this, then?
In version 2026, Cinema 4D started using ACEScg instead of Linear sRGB as its working color space. This was done to better interface with Redshift – its built-in render engine – but it’s not good for us Octane users.
TL;DR Solution
Important: We need to make sure C4D’s “Render Space” is always set to Legacy (sRGB linear workflow), even if our final target is ACEScg or sRGB with ACES tone mapping checked, or OCIO or anything else.
If we don’t catch it in time and need to convert an existing scene, we want to make sure “convert colors” is unchecked when doing this. Converting the colors will not fix the problem - if we were using specific brand colors in our scene, as soon as we entered them using the ACEScg workflow, they shifted. We need to re-input them after changing back to Legacy (sRGB linear workflow).
What Does The Issue Look Like?
Basically, the colors we’re choosing in the picker aren’t matching what’s showing up in the Live Viewer (or even within different parts of the UI). This could be really subtle or really obvious depending on the color, and the tricky part here is that we may not notice it until we get pretty far into the project.
This shifting happens regardless of which color picker mode we choose. Some modes may line up better than others sometimes, but it’s going to be a struggle no matter what if C4D is using ACEScg.
Important: A dead giveaway that we’re in trouble is if we see a Color Space dropdown box next to the color tile in the picker (highlighted in blue in the illustration above). C4D’s legacy picker - what we want to be using - does not have that dropdown (shown in the illustration below).
Strategies
Now that we know it’s a problem, we can make some changes to our C4D interface so we don’t forget to set this in the future.
We can make our own custom default in the color management settings after we change it to Legacy (sRGB linear Workflow) and call it something like “Linear sRGB (Octane)”. Every new scene should default to this going forward.
We also can (and should) bake it into our C4D startup file if we have one. More on that can be found in the Custom Defaults guide here.
What’s Really Going On?
In a nutshell, Octane was designed to talk to DCCs like C4D using Linear sRGB/BT.709 values, not ACEScg values, which are different (not better, different.)
Diving a little deeper is tricky without really understanding color spaces (which you can read more about here when you have time). Let’s try to sum it up though:
In the world of computer graphics, color spaces determine how color data is stored and referenced. There are two main types:
- Working color spaces are designed to describe values in the massive, linear-encoded data sets that render engines produce and post apps use for precise calculations. Linear sRGB/BT.709 and ACEScg are the two most popular ones in 3D. Both can store the same quantity and quality of data and give us pretty much the same results. “Pretty much” here only because they define color values in a different way, so it’s hard to directly compare the two. This difference is where our problem lies.
- Display color spaces are designed to describe values in the smaller data sets that we show on our monitors or store in the JPEGs and such that we pass around. sRGB – not Linear sRGB – is the most popular and widely-used display color space. Display spaces aren’t really the issue here, so we’re not going to focus on them.
2D and 3D DCCs (Digital Content Creation apps) need to specify a working color space so that color picking, image processing, and how colors look in the UI are kept consistent and predictable from app to app (and project to project).
Render engines also need to specify a working color space so they have a model for how to interpret the picked colors and images we feed into them, and then how to store and export the rendered values once they’ve been created.
Important: In order for colors to remain consistent between the render engine and the DCC, both pieces of software need to be speaking the same language by using the same working color space.
Cool.
Redshift is what’s known as a tristimulus RGB render engine, which means it does its calculations using RGB values, and therefore relies on standard working color spaces. It can use Linear sRGB or ACEScg, or something else via OCIO. The folks on the Redshift team decided to move from Linear sRGB to ACEScg as their default working space a while back, so C4D had to follow suit so that it didn’t have color matching issues with its own default engine.
Octane is what’s known as a spectral render engine, which means it does its calculations using light spectra values instead of RGB values. It does not need or use a standard working color space. These light spectra values are calculated using physically-accurate math, and cover the entire visible spectrum, so they can easily be converted to (and exported as EXR files using) Linear sRGB, ACEScg, ACES2065-1, and any other supported working color space via OCIO.
DCCs don’t tend to recognize spectral values (C4D certainly doesn’t), but they all support and implement Linear sRGB in more or less the same way, so Octane converts all the values to Linear sRGB before interfacing with any DCC, and expects everything coming in from it to be in terms of Linear sRGB (or at least sRGB that Octane then linearizes).
Important: The Octane <-> C4D Linear sRGB workflow has worked perfectly well for years with no loss of quality, and will continue to work perfectly well into the future unless C4D drops support for Linear sRGB (@Maxon - please don’t do this).
As of this writing, Octane <-> C4D communication via ACEScg has not been implemented. C4D’s newest color picker in 2026.1 does do some sort of conversion between ACEScg and sRGB, but it’s new and shouldn’t be trusted (and really, what’s the point - it’s simpler to just use Linear sRGB without extra conversion steps).
Any blown highlights, fireflies, and other visual issues are not because of one working color space or another - they are a result of converting the linear values from either Linear sRGB or ACEScg into non-linear ones for a display color space like sRGB, but that’s a whole other issue.