Rendering

A Hex Value’s Journey

Book III: Post

Version 1.0, Updated May 2026 using Octane 2026.2 and Cinema 4D 2026.3
~3,350 words, average read time: 15 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 third book covers post production, using C4D’s Picture Viewer as a rudimentary post app to explain the process.

If you haven’t read Book I: C4D, or Book II: Octane, it’s highly recommended to get a bunch of context for this one. 

PDF

This guide is available in PDF form here

Part I

Post Color Management

Fix it in Post

In books I and II, we saw what it took to keep our hero cube sporting the same single color (#6495ED) along several paths through Cinema 4D and Octane.

In some cases, that’s the whole story, but more often (especially in professional workflows), what comes out of Octane is meant to go into a dedicated post production app like Nuke, Fusion, After Effects, or something similar for further editing and refinement.

In this book, we’re going to guide our cube through C4D’s Picture Viewer to train up, build defenses, and acquire knowledge so when it comes time to jump into one of these other apps, we have the best chance possible of preserving the iconic Cornflower Blue color that we’ve grown to love over the last however many thousand words in this epic.

Ideal post color management workflow

First, let’s explore what an idealized color management workflow looks like so we have a target to aim for. This is not how it always works, but it’s how we want it to work.

1. We make our 3D scene in our DCC (C4D in this case) and get Octane to render it.
    
2. Octane renders spectral data, and then temporarily converts it to (non-linear) sRGB values on the fly to preview in the Live Viewer so we can see what we’re doing. Tone mapping is applied just to the preview (not the final exported data) as part of this process to give a better idea of what we can expect later on.
    
3. Looks amazing, time to export to post.
    
4. Octane converts the spectral data to RGB values encoded in a standard working color space like ACEScg or Linear sRGB. Again, tone mapping is not applied here - that will happen in the post app.
    
5. Octane packages the converted RGB source files up and sends them to the post app (usually via EXR or TIFF files).
    
6. The post app is told which working color space Octane used when exporting the files (ACEScg, Linear sRGB, etc). It now has the right basis to work from so that everything down the rest of the pipeline is correct.
    
7. The post app then combines, composites, color grades, and applies delicious posty voodoo to make everything look polished, magically fix everyone’s problems, and save the day. 
    
8. While it’s doing this, it temporarily converts the values on the fly to whatever our final target display color space is (sRGB, Rec.709, DCI-P3, etc.) so we can see what we’re doing. Our monitor is set to whatever our target color space is, and is calibrated properly - no surprises.
    
9. Post is done, time to ship it.
    
10. The post app does its final conversion from the source working space values we were using for editing into the final display space values we’re going to use for distribution, applying whatever tone mapping scheme we were using throughout the process so they match the preview.

The final files are exported in the desired format, and we send them to the client on time and within budget. Everyone’s happy with the results, we immediately get paid, the work’s done, and we don’t need another round or two of “tiny” tweaks minutes before the deadline to make it pop more (idealized, remember?).

The Picture Viewer as a Post App

Cinema 4D’s Picture Viewer can be thought of as a very basic post processing app. It takes high bit depth source data, alters it, and then produces low bit depth files that we can distribute, just like one of the big boys or girls (Nuke, Fusion, After Effects, etc.) 

Granted, it’s nowhere near as powerful, but it can give us an idea of how this all works without having to split this out into 10 guides (everyone following along has it already and doesn’t need to leave C4D), and also can be another tool in the box when it comes to quickly previewing or shooting out client proofs without needing to fire up another app.

It also has a whole host of issues with bizarre workflow decisions, janky UI and seemingly random usage of color management terminology. This makes it a good training ground to get us used to the weird and wild world of post apps, all with their advantages and, well, not super ideal UI decisions we’re going to have to cope with.

Behind the Scenes

When we hit the Render to Picture Viewer button, Octane starts rendering and sends a stream of updated render states to C4D after every x number of samples are finished. 

C4D stores the first state of a frame in a cache somewhere on disk, and overwrites it with a new version every time Octane sends one. This keeps happening until Octane hits the max samples and finishes rendering. Once a frame is completed, it moves on to the next one (if there is one).

Every time C4D receives one of these new states, it processes it. This involves doing any compositing/color work we have set up, and then applying a transfer function and tone mapping to preview our final output. 

Important: Sometimes C4D can’t keep up with the processing, and we may encounter situations where we’re seeing the image appear either too washed out, too dark, or just plain wrong, but then suddenly it’s fine when C4D catches up. It’s important that we wait for this to happen before making any judgments about whether it’s working properly or not.

Independently of this whole caching/viewing process, the Render to Picture Viewer command can also trigger a save process when the render is complete and processed, which we saw in the previous book in this series. Again, we don’t need to save files when we Render to Picture Viewer - we can turn off saving from both Octane and C4D and just send a stream of data to the cache and it’ll show in the PV just fine. 

The Picture Viewer also gives us the ability to manually save the processed files in a variety of formats, just like a real post app.

Part II

Enter the Picture Viewer

Decisions, Decisions

There are a few things we need to have at the ready before we go any further:

1. Which working color space are we going to use? ACEScg is default in C4D now, and that’s a perfectly fine option. Linear sRGB and ACES2065-1 will also give us near identical results once the values have been converted back to a display color space. It’s not a quality issue, it’s a choice that we just need to settle on and remember so we can tell our post app (or others on our team) which one we’re using so we/they can set other settings accordingly.
    
2. What kind of tone mapping situation are we thinking our final files will use? We don’t need to decide this now, but it really helps with pre-visualization. Let’s say we decided on ACES RRT+ODT (or just “ACES tone mapping”). The files we send to post won’t have this baked in, but as we’re adjusting lights and materials, we’ll want to preview what it probably will look like after processing, so it helps to have this temporary view running to limit the number of surprises later.
    
3. Less important most of the time, but still something to be aware of is the display color space we’re targeting. As of this writing, we’ll only be able to accurately preview our scene in sRGB (or Rec.709 if we have our monitors calibrated to that). If our target is Rec.2020, DCI-P3, or something else, we’ll just have to know that what we’re seeing in the Live Viewer won’t be the final. We’ll be sending over enough data to accommodate those wider gamut spaces with our EXRs, but we’ll only see what that really looks like when we get into our final post app.

Let’s Go!

This probably isn’t going to be the way we work on any normal project, but it’s a good illustration of how the whole process works.

Step 1. Align the working color spaces

Why? We’re doing this so C4D knows what color space we exported from Octane. If they align, the render will stand a chance of looking right. If not, it’s going to be difficult (or impossible) to fix later, and our hero cube will be sad.

C4D

We’ll start with C4D and match Octane to it. If we hit Ctrl-D or Cmd-D to get into the Project Settings and head to the Color Management tab, we’ll see what C4D is using as its working color space. For reasons still unclear, Maxon decided to call this a Render Space. We decided before to use ACEScg for this project, so let’s make sure this is set to ACEScg.

Octane

If we hit Ctrl-B or Cmd-B, it pops open C4D’s Render Settings window. In the OctaneRender section (assuming we have our Renderer set to OctaneRenderer), in the Picture Viewer tab (which was called “Main” up until mid 2026), we’ll see the Color Space dropdown. This is what Octane will use when it’s sending data to C4D. Since we had ACEScg set in C4D, that’s what we want to pick here as well.

Why this matters

Important: These two really need to match. We will have the option to re-align them later, but it’s more annoying and we have better control over the situation if we just do this now.

Step 2. Align the View Transform

Why? We’re doing this so what we see in Octane’s Live Viewer is the same as what we see in the Picture Viewer, that way we’ll know our colors are correct throughout the process.

The term View Transform covers two things:

1. The conversion from a working color space to a display color space so we can actually see what we’re doing (no monitor can display a working color space).
    
2. Tone mapping, which is essentially picking a method by which values are remapped or compressed during the display space conversion.

Octane

Here, we’re going to start with Octane and match C4D to it. Octane assumes sRGB for the display color space and no tone mapping by default. If we want ACES tone mapping, there’s a checkbox for it. If we want anything else, we need to dig into the Output AOVs or custom OCIO profiles (like for AgX). 

In our case, we want to preserve our blue, so we want to go with the defaults.

C4D

The View Transform settings in C4D are in the Project Settings (Ctrl-D / Cmd-D), in the Color Management tab.

C4D also assumes sRGB for the display color space, but it does it in a separate dropdown with one option: sRGB. Presumably this changes if we use a custom OCIO profile, but we’re not, so we don’t worry about it.

The tone mapping settings are in the View Transform (Project) and View Transform (Thumbnails) dropdowns in the Project Settings.

• ACES 1.0 SDR-video is the same as Octane’s “ACES tone mapping” checkbox
• We’re not going to worry about Log or Raw here.
• Un-tone-mapped is straight sRGB, which is the same as Octane’s defaults (without ACES tone mapping checked)

We want un-tone-mapped to preserve our blue.

Important: This is easier to fix later than a working space mismatch, but we don’t want to start going down a path of editing something only to realize we’re not looking at the same thing and have to redo it.

Step 3. Render to Picture Viewer

If we fire up the Octane Live Viewer, then we’re met with a #6495ED cube again, as expected. 

Now let’s try rendering to the Picture Viewer by hitting the little clapboard icon thing in the upper right of the C4D interface. 

At first blush, it may seem that this worked, and on some monitors it may well, but with a wide gamut screen like the one in the MacBook Pro the author is using, it’s once again a little off. A color picker shows that it’s really #5497F4, and that’s going to cause our cube to go into a tizzy.

Why. Oh why.

Step 4. Use Monitor Color Space

Right, because we learned in Book I of this epic crazy journey that C4D gives us the option to take our monitor’s color space into account. Octane automatically does this which is why it looks right in the Live Viewer, but C4D has it turned off by default for… y’know… reasons.

Let’s fix this.

All of the Picture Viewer’s color space settings are in the View Transform dropdown in the upper right corner of its UI.

We can see that it pulled in the correct tone mapping (none) in the astonishingly poorly named “Color Spaces” section of the dropdown. (Maxon, if you’re reading this, please align all your terminology - this is confusing enough as it is).

We can also see that Configurations is set to Embedded. We’re going to untangle this mess in a later guide, but for now we just need to know that it means that it’s using the settings we set in steps 1 and 2 of this section.

Finally, we can see that Monitor Color Space is off. Even if we somehow remembered that we could set this in the viewport settings (we probably didn’t), that setting doesn’t carry through to the Picture Viewer - we need to check it every time we use the Picture Viewer.

If our monitor is only capable of sRGB and isn’t wide gamut, then this doesn’t matter. If it is (and that’s most modern displays now), then this needs to be enabled so the colors appear correctly.

Our cube can dance a jig now - it made it all the way through to the end.

We Made It!

All of the same decisions and concerns we had during this process appear in “real” post production apps as well. Terminology will be wacky and inconsistent, where settings are buried won’t make sense, and the UI will be the result of years of jury rigging and bizarre design decisions.

The important part is that we know which settings to investigate so our colors don’t go sideways. 

Journey Recap

We started with a vision: See Cornflower Blue (#6495ED) all the way through from our initial choosing of it to render to output to post without it shifting. Shouldn’t be a thing, but here we are, three books later…

• In Book I, we learned how to get the color picker to enter our value correctly, and how to get it to show up properly across the various touchpoints in C4D.
   
• In Book II, we transitioned to Octane and saw the color through a few transitions, but still ended up with our blue in the end. We also investigated various ways of saving our files out via both C4D and Octane directly.
   
• In Book III (this one), we then looked at what a very basic post production pipeline looks like and why it’s important to align various settings from one app to another.

Now let’s look at the whole journey in fast forward:

We start off in C4D by using a color picker to choose our sRGB hex value (#6495ED) in a standard material: 

• It gets converted to C4D’s working space (ACEScg by default) which changes its numerical values, but the color itself is still the same.
• It gets processed using C4D’s View Transform (Project) settings so we can see it in the viewport (and eventually for the render). Assuming this is set to un-tone-mapped, it stays intact, otherwise it shifts.
• If we have a wide gamut monitor, we need to tell the viewports to use our monitor’s color space in order for it to appear correctly while we’re working.
• We could render this to the Picture Viewer at this point, but it wouldn’t be an Octane guide if we didn’t use Octane now, would it.

Then we move to Octane where we use one of its native materials:

• Once again we input our sRGB hex value (#6495ED) into a color picker
• The color is once again stored by C4D and converted to its working color space (ACEScg, probably), and kept intact.
• When it comes time to render, C4D passes the ACEScg (or Linear sRGB or whatever) value to Octane which converts it again to spectral data, which still keeps the color intact.
• While rendering, Octane converts it again to sRGB without tone mapping (by default). It shows this to us in the Live Viewer, where it samples correctly as #6495ED. If we turn on ACES in the settings, or want to use AgX, Smooth, or some other tone mapping via OCIO or Output AOVs, the color shifts.

At this point we have a few options to save files out via Octane or C4D’s pipelines.

• We can export directly out to PNG or JPEG for client proofs or web/presentation use. If we keep the display color space at sRGB and don’t apply ACES or some other tone mapping type, our color will be preserved and sample correctly.
• We can export to EXR or sometimes TIFF to send to post. In this case we’ll be using a working color space still (ACEScg, Linear sRGB, maybe ACES2065-1) with no tone mapping. As long as the post app is aware of which space we used, it can process the render further and our color can remain intact.

We can also use the Picture Viewer as a rudimentary post app

• Rather than packaging up the data as an EXR sequence, Octane sends it directly to C4D in a cache. 
• Octane needs to convert it to a working color space (ACEScg, Linear sRGB, possibly ACES2065-1) prior to sending it.
• C4D needs to know which color space to expect, since it can’t autodetect it, so we have to tell it in the Project Settings (Color Management > Render Space).
• C4D also needs to know not to apply tone mapping (un-tone-mapped in the View Transform settings).
• C4D also needs to have “Monitor Color Space” checked if we have a wide gamut (not straight sRGB) monitor.
• If all of these things line up, our #6495ED color is preserved and we can see it in the Picture Viewer window.

Phew.

Series Wrap Up

All the trials and tribulations we conquered led to our hero cube’s beloved Cornflower Blue identity being kept intact all the way from start to finish. Now it’s time to head back to the village with the character growth that only an epic adventure can bestow, and the knowledge that the power was within the whole time…

…or something.

If you made it this far, congratulations. Color spaces as a concept really is a big hairy mess, but hopefully you have a better understanding of how to navigate it now. You should have some ideas of where to start looking if your colors don’t match.