Rendering Series
Version 1.0, Updated Mar 2026 using Octane 2026.2 and Cinema 4D 2026.4
~4,700 words, average read time: 20 min
About this guide
This is part of a multi-guide series that follows a single color through a color management journey. It’s written as more of a story than a factual how-to guide to hopefully make it more interesting, palatable, and memorable.
This first book covers Cinema 4D 2026.4
A PDF download of this guide can be found here
Intro
Color management is complicated. It’s not actually difficult in and of itself, and the core concepts can be learned in a way that makes sense, but there’s a huge minefield of misinformation, bad/mismatched terminology, emotional turmoil, bickering, backbiting, poor implementation, and all kinds of other noise that takes an already complex situation and makes it nearly insurmountable.
In this series, we’re going to follow a plucky hero cube clad in his signature color: #6495ED, as it navigates this web of horrors and makes its way to the very end with the same colored clothing on.
There will be laughs, there will be tears, there will be more tears, but who knows, we may just learn something along the way, and find that the power was inside it the whole time or something.
This first book contains a bonus chapter at the end that’s a glossary of terms used in color management so you don’t have to read this guide, this guide, or even this guide to be able to follow along.
Part I
The C4D Story
World Building
Our story starts in a brand new scene in a fresh install of Cinema 4D 2026.1.4.
In book II, we’ll journey to the realm of Octane, but in this book, the story takes place entirely within vanilla C4D. To understand what’s going on in our DCC, we want to switch our render engine to Standard (Ctl-B for Render Settings > Renderer dropdown in the upper left > Standard).
In this beginning part of the story, we don’t want any fancy environments, lights, or anything else to conflate things. Just a basic world using a basic render engine.
Enter the Hero
At the core, our hero is a humble 200 x 200 x 200 cm default cube. If we click the cube object in the right hand panel, it’ll just appear in the middle of the world. It’s naked at the moment, so it’s going to need something to wear. Let’s double-click in the Material Manager which creates a Standard material (as long as the Standard Render engine was chosen in the last step) and apply it to the cube. There, much better, now it won’t get cold.
Adding Some Character to our Hero
A light gray cube is boring. We need some drama! Some intrigue! To go from a standard cube to our hero cube, we need a signature trait. One that gets rigged objects to rotate their neck joints and say “who is THAT cube?”.
For this, we need Cornflower Blue.
Cornflower Blue is one of the named html colors in the sRGB IEC 61966-2-1 color space (and the both a favorite of the boss in Fight Club and Vermeer). It’s defined as R:100, G:149, B:237 in the RGB color model, or #6495ED in hexadecimal, which is just easier to wrangle and refer to as we go down this journey.
Note: sRGB is one of those things that’s… a mess from a terminology standpoint. The proper way of writing it out in the flavor we’re most often going to encounter it is “sRGB IEC 61966-2-1”, but we’re almost always going to just see it referred to as “sRGB” in our apps, so we’re going to just assume the IEC standard here. More on this in the glossary in the next part.
The plot of this story is though the hero travels far and wide, it needs to keep that signature color throughout this journey. After all, we can’t just have any blue.
If we click the material, we’ll see the color channel pop up. It has a color UI there that lets us choose a color (currently light gray). If we click the color chip next to the word “color”, C4D’s Color Chooser (picker) will pop up.
This shows us another chip that has our color on it, an eyedropper, and a color space dropdown which we’ll look at in a sec. Below it are two models: 8-bit RGB and HSV. There’s also a button for saved swatches, and one that expands out the picker to show us other models - this is where the hex model will be.
Let’s hit the little uppy-downy arrows to expand the model view, and then choose the # icon to get a hex input.
The First Conversion
Time to imbue our cube with the legendary sRGB #6495ED Cornflower Blue value! We do that by typing it into the box. Cue heavenly “wahhh” sound effect. Great, that looks right in the color chip.
By default, we had sRGB chosen as our color space, which is good, because Cornflower Blue #6495ED is an sRGB color. C4D had other plans for it though, and immediately converted it to the ACEScg working color space and stored it internally as ACEScg #384BC5.
Fear not, though! ACEScg, being a working color space, will preserve our value just fine without shifting it, as we’ll soon see.
The color space dropdown we see there is actually the input color space dropdown. This allows us to input a color using any color space we want, not just the one Cinema 4D is working in.
If we change the color space dropdown in the picker from sRGB to ACEScg, we’ll see the hex value change. It’s visually the same color, but it has a new designation now. If we knew the ACES cg value of Cornflower Blue going in to this (#384BC5) instead of the sRGB one (#6495ED), we could have just changed the input color space to ACEScg, put in that value, and ended up with the same color.
We didn’t though, because hex is a weird color model for a working color space. Let’s change that back to sRGB, since most of the color values we know are in sRGB.
So this begs the question: Why did it convert it to ACEScg in the first place?
The Render Space
Because it had to.
Cinema 4D - and its currently selected render engine - needs to be operating in a working color space. This is where all the super precise render calculations happen, so it needs to be a large and linear-encoded to work well with physically-accurate values. A proper working environment so we can be a functional part of polite render society!
sRGB, where we first encountered Cornflower Blue, is not a working color space. It’s a display color space, which is all about relaxing, having a good time and showing off, not harshing our colors’ buzzes with work, maaan.
There’s a place in the process for both, but if we want to make any meaningful changes in our digital lives, we’ll need to put on our big color pants and head to work to put pixels on the table.
If we go into the Scene settings (Ctl-D or Cmd-D on the Mac), and go to the Color Management tab, we’ll see most of C4D’s color settings. We’ll be visiting this area a lot, so it’s worth burning the Ctl-D / Cmd-D shortcut into muscle memory.
By default, as of version 2026, Cinema 4D uses ACEScg as its default working color space. Prior to 2026, it used Linear sRGB (which is still just as good, but Redshift had already moved to ACES so C4D had to follow suit). This change caused some havoc with Octane in earlier builds of the plugin, but has since been resolved since the 1.8.4 build.
Being a working color space, ACEScg can handle every value in a display color space, and nearly infinitely more to boot.
When we convert an sRGB value to a linear-encoded working color space, the name changes, but the actual _color_ itself does not. When we convert it back, it can remain intact if it’s set up that way (which we’ll look at soon).
So our Cornflower Blue survived its first conversion. It got a new nickname out of the deal (ACEScg #384BC5 which we’re going to immediately forget and not need again), but it’s still the same beautiful color. Sweet.
Terminology note: Maxon probably had their reasons, but they call it a “Render Space” instead of the industry-standard term “Working Color Space”. In this guide we’re going to try to always use “Render Space” when talking about C4D’s working color space, but if we slip up, just know we’re talking about the same thing.
The First Stumbling Block
We haven’t even introduced Octane into the mix yet, and we’re about to hit our first roadblock.
In the C4D perspective viewport, we see three different blues, none of which are Cornflower Blue. That’s to be expected though, the default shading in the viewport (Gouraud) does a quick simulation of what the light and shadow would look like in the scene to help us visualize it better. This is what we’re usually after in 3D - variation in values means things look 3D to us.
If we want to see what the base color looks like, we can kill the shading so we can just see just the flat color value. We do this by setting the Display in the viewport to Constant Shading. So now our cube is a flat color that just picks up what’s in the Color channel. Problem is, It’s #3F81CC, not #6495ED.
That’s weird.
Is it the default reflection in the material? No, removing that doesn’t change anything. Nor does putting #6495ED in the Luminance channel instead of the Color Channel. It’s still shifting by about the same amount.
So what’s going on? ACES “Tone Mapping”, that’s what!
If we head back over to the Project Management settings (Ctl-D / Cmd-D on Mac), and go into the Color Management tab, we’ll see that both View Transforms (Project & Thumbnails) are set to ACES 1.0 SDR-video.
What’s happening here is that our sRGB #6495ED was converted to ACEScg, which is fine and didn’t disrupt anything, but now that C4D needs to actually display the value somewhere, it has to be converted back to sRGB since that’s what our monitors are expecting.
This conversion is also called a transform, and it takes all the values from one color space, processes them, and then fits them into another color space. So in this case, it’s taking the ACEScg (working space) values and transforming them so they can be displayed on our sRGB monitors.
By default, C4D is set to use an ACES transform to do this, which applies “tone mapping”, which… right… shifts all the colors.
C4D has two dropdowns for transforms here: View Transform (Project) refers to the colors seen in the viewport and other areas of the UI, and View Transform (Thumbnails), which refers to the material thumbnails. They should generally be set to the same thing unless there’s some compelling reason not to.
Important:This isn’t actually changing any of our color values themselves, it’s just displaying them according to the processing scheme selected. Being an ACES shop, Maxon decided that an ACES transform was a good default for this, and it should better match the final render if ACES tone mapping is being used.
Our hero doesn’t agree with this though. It wants its legendary Cornflower Blue suit to remain so. Let’s take a look at our options here:
View Transform (Project)
There’s ACES 1.0 SDR-video. That’s what it was set to by default, and it was using ACES tone mapping (different concept from ACEScg). Like all tone mapping, the method found in this ACES view transform shifts colors - it’s why our color went from #6495ED Cornflower Blue to #3F81CC Not Cornflower Blue (and made our hero cube cranky).
There’s RAW, which apparently is supposed to show the Render Space (ACEScg). This is pretty ridiculous with ACEScg because no monitor in existence can possibly show all that, so a lot of clipping will occur and it’ll just look like a dark mess. In our case, the blue will just go really moody (#334CCD).
There’s Log, which is a baseline used in film grading that’s not meant to be viewed as-is and probably won’t be super useful. If we set this now, our blue will turn into a dusky blue-gray (#6C7489).
Finally, there’s un-tone-mapped which is just the straight transfer function that matches the Display Space dropdown right below the transforms. We haven’t discussed this because it’s always sRGB unless we have some fancy OCIO setup. Anyway, this is what we’d choose if we’re not using any tone mapping in our project. If we set it to un-tone-mapped right now, our Cornflower Blue color in the viewport should sample correctly as sRGB #6495ED.
Should.
Wait… no, for some of us, it’s still off on the author’s MacBook Pro! It’s #5496F3, not #6495ED! WTAF?
Oh right, the monitor…
The last piece of the puzzle is our display, which is also using a color space (yay.).
There actually is a chance that Cornflower Blue will be appearing correctly if our monitor is set to (or only capable of) sRGB, but many modern ones - especially laptop screens - are natively a somewhat larger color space like Display P3. If that’s the case (it definitely will be for us Mac users, and probably will be for most Windows users in 2026), then we need to tell C4D to take our monitor’s color settings into account if we want everything all matchy-matchy.
This option is in a totally different place. It’s hidden in the Viewport settings (not the Scene Settings), but instead of Shift-V which shows us settings for the current viewport, we want Alt-V (Option-V on the Mac) to give us the settings for ALL viewports.
At the very bottom of the View tab is an option for Use Monitor Color Space, which is off by default (why, Maxon, why.) When we turn this on, C4D will run the colors through one last conversion, and our beloved Cornflower Blue color will FINALLY appear as #6495ED in the C4D viewports.
[Add fireworks and cheering in post]
Sampling from outside of C4D
Another thing we may want to do is use the eyedropper tool in the color picker to sample Cornflower Blue (or some other lesser, inferior color) from a different app, or from something in the OS’s UI.
Important: If absolute precision is needed, most of the time eyedroppering a color from an external app is a Very Bad Idea®. The only way to get an exact color into the color picker 100% of the time without fail is by manually entering the RGB / HSV / Hex /etc values for that color space.
When Close Enough Isn’t
That said, there’s a very high likelihood of the eyedropper workflow being successful if the entire workflow end-to-end is using exactly the same color space and color profile config files (if OCIO is being used). Generally speaking, the only space that pretty much every app/OS implements pretty much the same way is sRGB.
After all, the “s” in sRGB does stand for “Standard”…
So if C4D’s Render Space is set to sRGB (Legacy), the monitor/OS’s color space is set to sRGB, and the external app’s color space is set to sRGB through and through (both global and document-specific settings), and C4D’s settings are right, then any sampled color value should come across correctly during the eyedropper process.
Likewise, if C4D, the OS, and the external apps are all configured properly using the same OCIO config file, colors should sample correctly too. Will they? Only the great OCIO oracle knows.
If ANY of the color space settings in the chain are different, it introduces conversion of some sort and the possibility of color values shifting anywhere from a little (a 4 to a 5, or an E to an F), to a lot (obviously different to the naked eye).
When Close Enough Is
If absolute precision is not required (if we’re dressing our cube in a cheap knockoff of Cornflower Blue), then how we’ve set things up so far in C4D + making sure our target external app is displaying the values properly (looking at you, Photoshop on the Mac with “Use Graphics Processor turned on”) is good enough to get “a blue that’s pretty close to this.”
Where We’re At
At this point, Cornflower Blue should look correct everywhere we see it in the Cinema 4D environment, regardless of whether the Render Space is set to ACEScg (default), scene-linear rec.709-sRGB, or Legacy.
Book I of this story has come to a happy end - stay tuned for book II where our cube ventures into the land of Octane!
Part II
Terms of Endearment
Here are some terms that are thrown around in this series as if we all just know exactly what they mean.
This is what they mean.
Color Space
A color space is a set of specifications for how software should handle color. Every color space needs three things:
- A gamut, which is a set of colors the color space can reproduce. Not how many colors, but which colors. (We’ll brush on this in this series, but not get too deep).
- A white point which is a particular color in the gamut that represents “white”. (We’re not going to talk about this in this guide).
- A transfer function which contains information about how to convert between how the color space itself stores values and physically linear values. This is used for transferring the data between different color spaces, and also to display properly on a target device. (We’re going to talk the most about this)
There are two main categories of color spaces:
Typically, pro apps do precise calculations using a working color space like ACEScg or Linear sRGB, the hallmarks of which are a linear transfer function and ability to access a near-infinite amount of color values. This is great for accuracy and precision, but since apps that use working color spaces also typically work with high bit depth data while doing so, they produce big, unwieldy files that contain more data than our devices can display, so they’re used as “source” files rather than final distribution files.
Displays utilize display color spaces like (not linear) sRGB and Display/DCI-P3 which have a smaller gamut, non-linear transfer function, and are just precise enough so images look good to our eyes, but not much more than that. These files are lower bit depth, so they’re small and easy to store and stream to the devices meant to display them, but most of the original data is discarded, so editing these files in post can be challenging and limited.
Color Model
Independent of color spaces, there’s also a concept of color models, which are the different ways colors can be represented in any space. Usually these are broken down into a few components (3, most of the time).
Important: Color models are only different descriptions of the same color in any given color space. Bouncing between models will not change the visual representation of the color, it’ll just show a different breakdown of the same color.
RGB: How much Red, how much Green, and how much Blue are combined to make a particular color. The scale goes from 0 (none of that component) to “the most” (maxing out that component). In the sRGB color space, for example, this is usually seen as 8-bit sliders (0-255). In other spaces the scale for each component might be 0-1, 0-65,535, or something else.
Our Cornflower Blue’s RGB values in 8-bit sRGB are R:100, G:149, and B:237.
Hexadecimal: Shorthand for RGB values. Hex uses a base-16 (hexadecimal scale) that goes from 0-9 and then A, B, C, D, E, F for a total of 16 possible values. Red is represented by a pair of values (00 is red=0, FF is red=255). This shortens the whole thing so we’re talking about an 8-bit sRGB color, we only have to remember six characters rather than three buckets with up to 3 digits in each.
Cornflower blue in this model is #6495ED
Other models: HSV assigns a scale to the hue, saturation, and value properties of a color instead of how much red, green, and blue is in it. Pantone names each color. Kelvin is about the temperature and tint, and so on.
Linear
There’s a whole other 10,000 word guide on this one term. In this guide, we’re talking about it in the context of how color values are encoded.
Without getting too deep into it, working color spaces like ACEScg and Linear sRGB store data in a linear fashion, which allows us to save everything that was rendered and gives us the most flexibility when it comes to converting to other spaces or addressing more data in our post apps. It also means larger, more unwieldy files that our displays can’t even display (even the best displays money can buy) in this original form.
Display color spaces like sRGB and Display/DCI P3 (on more modern screens) store data in a non-linear fashion, which discards most of the data originally generated. This encoding system only keeps data that our brains find valuable (and that our screens can properly display), and trashes everything else. This is great for viewing images, but not great if we need to go back and edit images, and pull data from the “don’t care” bucket and convert it into the “do care” bucket. The discarded data’s gone, so we’d have to go back to the original linear-encoded values in a working color space to get it back if we needed to do any serious alterations to our image.
All the RGBs
“RGB” - all by itself - means Red, Green, and Blue.
It’s a type of color model (not a color space) that defines any given color in any color space it’s used in by how much of these three components are used. As we saw above, it can use a 0-255 scale, a 0-1 scale, a #000000 to #FFFFFF scale, or something else.
sRGB written out by itself like that is technically ambiguous, but when we see it in C4D and Octane, it’s referring to the sRGB IEC 61966-2-1 display color space that’s defined by a particular IEC specification. It has a relatively small gamut, a D65 white point (again, not going into this here), and utilizes a non-linear transfer function, which means it can only address a limited number of colors contained inside its gamut. This limitation also means that it’s a practical way to display and transfer data, and is the current standard for universal compatibility across monitors, phones, etc.
Linear sRGB written out like that with the all-important “linear” in front of the sRGB is a working color space. It uses the same gamut and white point as sRGB (as well as rec.709), but uses a linear transfer function instead of a non-linear one. It can access a far wider range of colors and luminance values within and beyond what sRGB IEC 61966-2-1 can practically encode, and it’s still a perfectly valid working space for 3D/VFX.
Tone Mapping
This is a particularly problematic term in the world of color spaces, but it’s pretty much the standard way of referring to this procedure, so we’re going to run with it here.
Basically when we have a large working color space and want to crunch that down to a small display color space, we need to decide which values stay and which go.
If we just use the built-in transfer function that comes with the display color space, it takes every value from the working space that can’t be referenced in the display space and just pitches them right in the trash. If we were really careful to limit all the colors we used in the working space to just those that would also appear in the display space, there’s no issue. When we start adding lights and other things to the scene though, the new colors created with the resulting calculations can quickly go out of the display space’s gamut, and if that happens, they get clipped (usually looks like blown highlights).
“Tone mapping” seeks to address this problem by taking all the working space values and crunching them in according to an algorithm until they all fit in the display space’s gamut. We still lose most of them, but the ones that we’re left with are all within the display space’s gamut. No more blown highlights, and banding and other artifacts are better controlled, but this means shifting all the colors to fit, so the colors we chose do not get perfectly preserved (usually they’re darkened and sometimes desaturated a bit).
Depending on the tone mapping algo and how far out we pushed the colors by blasting them with million lumen lights and whatever other atrocities we inflicted on them, they’ll shift more or less.
ACES tone mapping (a VERY DIFFERENT THING from the ACEScg color space, and technically not even called “ACES tone mapping” – it’s a combination of the ACES RRT + ODT – but that’s how it’s referred to) is one method of converting colors to a display space. It not only fits the colors into the new color space, but also stylizes the image by boosting the contrast and more aggressively shifting colors. Some people like this look, others hate it. Fortunately it’s only one of several methods of doing this.
AgX tone mapping does something similar, but it’s far less aggressive and keeps the original artistic intent better, but the resulting image can end up looking a bit dull washed out without further post processing (which is a good idea anyway).
Octane’s new “smooth” tone mapping is a procedural way of doing this that gives us more control over the conversion. Currently this can only be done via AOVs.
Transform
A transform in this context is the process of taking all the values from one color space and transforming them into a robot! (more than meets the eye!) another color space. This is a catch-all term that covers tone mapping, the transfer function, and other processing done during the conversion.
The ACES ODT (Output Device Transform) is a common one. When used, it takes the values from a large working color space (often ACEScg), does what we’ve come to understand as “ACES tone mapping” (applies the s-curve for contrast, shifts colors around), then uses a transfer function to strip out values and conform the data to a smaller display color space (often sRGB, but it could be rec.709, Display P3, etc.)
OCIO
OCIO (Open Color IO) is an open source color management system created by Sony Pictures Imageworks. It works with standardized (or custom) configuration files that have certain rules and specifications for handling color values. The theory goes that if two apps have correctly implemented it, and all the project files are referencing the same OCIO config file, the colors will all match. Sunshine and roses abound.
Cinema 4D uses OCIO for color management for internal calculations except when the Render Space is set to Legacy (sRGB Linear Workflow). This is the difference between the Legacy and scene-linear Rec.709-sRGB options. Both use the Linear sRGB/BT.709 working color space, but Legacy does not use OCIO, scene-linear rec.709-sRGB does.
Octane does not use OCIO for any internal calculations because it doesn’t need to. It calculates and renders spectral values, and there’s no standard color space for that. That doesn’t matter though because it can convert spectral values to any color space, and it fully supports OCIO if the export needs to abide by a specific OCIO profile.
Wrap Up
If you’ve made it this far, you should now know how to get C4D set up and prepped to work with Octane (and probably Redshift and other engines).
In the next book, we’ll look at how Octane fits into this.