Author Topic: ACES Workflow from SD  (Read 2300 times)

Hi there,

With the Winter release I'm very excited to explore the ACEScg workflow, but I am a little confused about it still, which I hope to clear up with some discussion here. I have a few questions. I'm working towards producing some personal projects in VRay for 3DS Max, so perhaps with that in mind I'm looking to use Substance the correct way towards a ACEScg output from the VRay Frame Buffer. I'm happy to discuss ACEScg for other outputs, as my license for VRay is expiring soon, so I'm considering alternatives that might be a little less painful, so if you're into using ACEScg for any other output, please share your thoughts and process!

1.) When configuring the Color Management settings for ACEScg in SD, what does this ultimate mean for existing substance sbsars? For instance, if I download something from Substance Source, load it into my SD graph setup for ACEScg, what will the output for that substance be? Are all substances Linear sRGB, or just sRGB?

2.) When configuring the Color Management settings for ACEScg in SD, do you also need to convert existing sbsar assets with the "Linear sRGB -> ACES" node for correct ACEScg output, or is that already handled by the settings configuration?

3.) Does having an ACEScg conversion color space in SD with ACEScg output mean I don't have to convert my textures in max using the VRayOCIO tool configured for ACEScg?

I'm aware that I need to change the rendering color space in VRay using the maxscript listener, however (in case anyone is wondering, type this in max script listener to change rendering color space to ACEScg: "vray.options_rgbcolorspace=2") [change the "...2" to "...1" to revert back to srgb.] I'm wondering if there is some way of profiling a render or texture to determine with certainty that it has been configured for ACEScg properly, as right now it seems extremely convoluted with a high margin for error with there being potential for overlapping "corrections" in each tool.

Any discussion on ACES for other platforms is also welcome.


1. For the existing sbs/sbsar, they are likely to output srgb basecolor map, so you have to convert this output (and only this one + other color channel like emissive) using the sRGB to ACEScg node. There is no automatic conversion because OCIO can't be called in the middle of the graph (hence the conversion nodes).

2. Same as 1. Use the sRGB to ACEScg node. Be careful node to mistake "sRGB" and "linear sRGB" (which is what we use to call "linear"). Prior to color management, basecolor was certainly "sRGB" not "linear sRGB". For instance the environment hdr maps are "linear sRGB".

3. I've not tested vRay and OCIO yet. In theory you should just have to choose the aces 1.0.3 config (or your custom config) and you should get the right view transform in the framebuffer (ACEScg to sRGB). That's it.
When loading your bitmaps you'll just have to tell the basecolor is ACEScg (how I don't know as I haven't tested). The others map should be interpreted as utility - raw or utility - linear srgb (I don't remember the exact name). That's what I did for the blogpost illustration in 3dsmax+redshift and maya+arnold.

On a side note: make sure you basecolor node network is set to use 16bit (not float) bit depth.
Product Manager - Allegorithmic

Hi Nicolas,

Thanks for your response, that clears a lot of things up for sure! I have a couple of follow up question to further demystify, and I will post some images soon with testing, to help anyone else out who is trying to figure this out, specifically for VRay.

So is the configuration in the project settings from Legacy to ACES purely there so that you can preview what ACES looks like inside of SD? With that configuration I suppose you still need to do the basecolor transform using the "sRGB to ACEScg" node?

Right now, VRay is not able to output a render with OCIO profile encoded into the image, you can only preview ACES from the VRay frame buffer. So the workflow is to create a linear 32 bit render, and do the final colour grading in AE, Nuke, or Davinci, using a Linear > ACEScg workflow (it's very annoying but it works).

It's nice to learn more, but my goodness I feel that colour science is a tough nut to crack for my artist brain.

The setting in the preferences allows you to switch between the legacy mode (no color management or rather the traditional sRGB/linear sRGB authoring we've had since a long time) and OCIO color management.

OCIO is the color manager, ACES is the config and ACEScg is the color space you are likely to use.

When you choosing  OCIO several things will change in the UI:
- bitmap resources will have an input color space parameter (to tell OCIO what conversion should be done toward the working color space)
- view transform drop-down will appear in the 2d /3d views to convert the images from the working color space to the display (sRGB on pc, P3 on mac book for instance)
- a color space parameter for the 3d view/environment map will be available to also tell what is the color space of the hdr map (the stock hdr are linear sRGB, if the environment is greenish it means this setting is incorrect)
- color picker will change according to the working color space specified by the config (ACEScg in the case of the aces 1.0.3 config)

If you create a new substance from scratch using the aces 1.0.3 config, then you'll actually create a ACEScg basecolor (because you'll choose the color in this color space). If you drag&drop a bitmap, if the input color space is defined correctly, it'll be converted (or not) to ACEScg by OCIO. But if you use an existing sbsar, you'll have to convert the basecolor manually using the conversion node.

The important thing to understand: only color data should be color managed (basecolor, emissive, clearcoat color..etc). Other maps like the height, normal, roughness are not color managed because they are pure data and should not be processed through any conversion before being sampled by the shader. That's why you should disable the view transform in the 2D view when visualizing this kind of map)otherwise they'll look washed out).

Hope it makes things clearer.
Last Edit: December 21, 2019, 07:35:05 am
Product Manager - Allegorithmic

Awesome Nicolas, thanks so much for your insight. I feel confident in trying it out.

Can you speak a little about using ACEScg with Redshift? From a quick glance it looks quite a bit less painful to use ACES with Redshift than with VRay. I’ll download the trial when I get home from the holidays and give it a shot.

Thanks again!

As far as I remember you only have to specify the config in the Redshift frame buffer. I don't remember if you have to also specify the bitmap color space (I assume you have but I don't remember how).

I'll check when I have access to my computer after the Christmas holidays.
Product Manager - Allegorithmic

Ok I've done some initial testing, and I'm rather pleased with the results so far. I'm still not 100% sure I've set it up correctly though so I'll share the process a bit.

Ok so first I needed to just grab a few assets I had in my library to set up a quick scene. I just grabbed a few photogrammetry assets I had, which only had diffuse maps as 8k, 8bit jpegs.

Now VRay has a tool called the VRayOCIO, which allows you to make color transformations on your textures. So I have tested using this tool for now, however I'm really uncertain about it, as there is a LONG list of transformation profiles to choose from. I chose to go with "Utility sRGB Texture", as I believe this is correct because my texture is an 8bit JPG (not linear). There are many other "sRGB Texture" configurations, I don't know why they're there but it could be legacy stuff.

So in theory, I could skip using the VRay OCIO tool, and make these texture modifications in SD by using the sRGB > ACEScg node. So I'll give that a shot next.

Last Edit: January 06, 2020, 10:56:44 am

As an additional note on the matter, if I'm following the process correctly, the transformations go like this:

Change VRay colour space to ACES using this command in Max script listener:
"renderers.current.options_rgbColorSpace = 2" for CPU
"renderers.current.V_Ray_settings.options_rgbColorSpace=2" for GPU

In Material Editor:
sRGB texture import with bitmap node > VRAYOCIO - "in" as Utlity sRBG Texture  - "out" as ACEScg, using ACES 1.0.3 OCIO config.

The texture should now be in the ACES colour space unless I'm mistaken, and we should be rendering with ACES as well.

Now here's where I'm a bit confused still. I don't fully understand what's going at this stage, so I fiddled around until I got a satisfactory result, but I'm not sure this configuration is correct. In the VRay frame buffer, there is an OCIO settings section, in which there is an "Input Colour Space" (which at this stage unless I'm mistaken should be ACEScg), a "display device" (the only option for which is ACES), and a "View Transform" which I suppose you need to convert ACES back to sRGB or Rec 709, whatever your monitor is calibrated for, to view the colour accurately on your display, or to bake ACES back down into a sRGB image.

Please let me know if I've tripped up here somewhere or misunderstood the science behind this. I'm going to try the approach by converting the textures to ACES in SD next. I suspect I will still need to use the VRay OCIO tool, as it is the only way the material connects to the ACES 1.0.3 config.ocio


As another follow up question, does it make more sense to approach working with ACES with linear sRBG textures? Should I be using 32 bit EXR diffuse maps?
Last Edit: December 28, 2019, 10:39:06 pm

It looks correct to me.

As another follow up question, does it make more sense to approach working with ACES with linear sRBG textures? Should I be using 32 bit EXR diffuse maps?

No sure I understand the question..?

Since SD now supports color management, the idea would be to create/author your texture directly in ACEScg (or perform the conversion directly in SD rather than with the Vraytool).
If your textures are directly in the ACEScg color space then they need to be stored at least in a 16bit format (prefer 16bit integer to 16bit float in SD).

Can you speak a little about using ACEScg with Redshift?

It's very simple:
- you simply have to load the configuration in the Redshift frame buffer
- since the configuration expects textures (color textures, not data textures) to be in the ACEScg color space, you don't have anything to do, just feed the material with appropriate textures.
Last Edit: January 06, 2020, 11:31:36 am
Product Manager - Allegorithmic