ACES workflow clarification for render settings (color space, etc)

[ssjenforcer191191191]

I watched a tutorial from Gumroad that says to leave 'Bake view transform into output' unchecked for 32 bit renders and use the exr driver, then render to picture viewer and it should be fine.

Is this correct?
I also found that I needed to set the render settings 'save' to display driver only so it wouldn't save two sets of the same exr renders.  Is there a way to ensure the correct alpha settings when doing this, or does arnold still use the alpha settings specified in the C4D render settings menu?

And when I make an HDRi image as the light source in Arnold Sky, it defaults (auto) to raw image files when making the tx cache file.  But the tutorial I watched also says to set it instead to linear sRGB (scene-linear rec709-sRGB), so is that what I should do?  It doesn't have the word ACES anywhere in it.

If that is the case, what about if I am using a panorama image to get a background projected onto a cylinder object (or HDRi image projected onto a sphere) so that I can have camera movement with correct paralax?

Should I keep the image texture in the node editor set to auto so it makes it ACES-sRGB like the rest of my colour bitmaps?

(for this technique, I followed advice and turned off colour and specular weights and only have the bitmap node connected to the emission colour)

I just want to be sure I am doing ACES correct before I render and try After Effects ACES for the first time.

Thanks.

[peter_horvath · Accepted solution]

You can find some guidelines in the docs: https://help.autodesk.com/view/ARNOL/ENU/?guid=arnold_for_cinema_4d_ci_Rendering_ci_ACES_Workflow_ht...

> I watched a tutorial from Gumroad that says to leave 'Bake view transform into output' unchecked for 32 bit renders and use the exr driver, then render to picture viewer and it should be fine.

> Is this correct?

Yes, normally when you render to 32-bit EXR, then you need linear data and don't want to bake the view transform.

Also note, that since now Cinema 4D also has OCIO support, if you set the color management to OpenColorIO in the project settings in Cinema 4D 2024, you don't have to care about the 'bake view transform' option.

> I also found that I needed to set the render settings 'save' to display driver only so it wouldn't save two sets of the same exr renders.  Is there a way to ensure the correct alpha settings when doing this, or does arnold still use the alpha settings specified in the C4D render settings menu?

Using an Arnold driver and the 'Save' in the render settings are two different methods. Arnold drivers are executed by Arnold at the end of the render, while the C4D Save is done by Cinema 4D on the frame buffer returned by Arnold.

The Arnold driver does not have alpha settings, it writes out an EXR with premultiplied alpha as by standard.

> And when I make an HDRi image as the light source in Arnold Sky, it defaults (auto) to raw image files when making the tx cache file.  But the tutorial I watched also says to set it instead to linear sRGB (scene-linear rec709-sRGB), so is that what I should do?  It doesn't have the word ACES anywhere in it.

> If that is the case, what about if I am using a panorama image to get a background projected onto a cylinder object (or HDRi image projected onto a sphere) so that I can have camera movement with correct paralax?

> Should I keep the image texture in the node editor set to auto so it makes it ACES-sRGB like the rest of my colour bitmaps?

Well, you have to set the color space based on the color space of your input image. 'auto' uses a simple heuristic: it sets the color space to sRGB if it's an 8-bit image and to linear (ACEScg in this case) if it's a 32-bit image. Most HDRIs are made in sRGB/Rec.709 primaries rather than ACEScg primaries, that's why you need 'linear sRGB' color space. If you know your HDRI is in ACEScg, you can set auto, linear or raw.

Hope this helps clarifying a few things.

[ssjenforcer191191191]

As I understand it from the tutorial I watched, the newest Arnold versions come with default ACES OCIO loaded from the get-go (as seen in my image below).

But you're saying (from your link) that I still need to go to render settings or project color management and change it to OpenColorIO?

Would the default ACES that comes preloaded with Arnold not work just as well?

[peter_horvath]

But you're saying (from your link) that I still need to go to render settings or project color management and change it to OpenColorIO?

Would the default ACES that comes preloaded with Arnold not work just as well?

---

The default OCIO in the render settings works just fine. Setting the Cinema 4D color management to OCIO is not mandatory, just recommended as it makes your life easier. By default Cinema 4D uses an sRGB display space and a linear space with Rec.709-sRGB primaries (scene-linear Rec.709-sRGB), so not ACES. That means the colors on the UI are in sRGB space and when you render, Cinema 4D applies this sRGB space to the image, so Arnold has to bake its view transform to get the correct result. If you switch to OCIO in Cinema 4D, then it uses the same space as Arnold. You have more controls over colors, you can set them in linear, sRGB or view space. And Cinema 4D does the view transform natively, so no baking is needed.

[ssjenforcer191191191]

So if I leave it the way I have it, it will still render in aces to way it looks in the ipr?

My auto color bitmaps already get set to sRGB_ACEScg.

So is there any difference in leaving it default vs making the change in that aces help link?

And when you mention baking, is that what is means when I load my scene and it takes like 20 seconds and it says at the bottom of the window it is baking viewport/exchange images?

My c4d sometimes crashes during that on scene loading.

[peter_horvath]

> So if I leave it the way I have it, it will still render in aces to way it looks in the ipr?

Yes, it renders in ACES with default settings just fine.

> So is there any difference in leaving it default vs making the change in that aces help link?

No difference in the output, it's just a difference in the workflow as I explained.

> And when you mention baking, is that what is means when I load my scene and it takes like 20 seconds and it says at the bottom of the window it is baking viewport/exchange images?

No, I have no idea what that is. Baking of the view transform I'm talking about is just a post step of the rendering, nothing to do with loading the scene.