Color-management in Substance Painter with OCIO

Scalar

Scalar data has no means to be displayed directly, the data store numbers that can be used to drive other types of data. We are only interested in the original value of these numbers and as such this kind of data must never be altered by color-transformations.

To get to more concrete examples scalar data include but is not limited to: roughness, normals, masks, displacement, vectors, …

Color

Everything that is not scalar. Values stored are intended to be displayed directly. These values are always encoded in some colorspace and require to be decoded properly.

This include but is not limited to : diffuse/albedo/base-color, subsurface color, specular color, refraction color, every image displayed on the web, …

In Substance

In Substance you will find this separation depending on the channel you are working on. The full list of color-managed channels is available here.

As Substance is aware if the channel needs to be color-managed, some operations will be adjusted/skipped. An application of this is the view transform that will be disabled when viewing a scalar channel.

This notion will be also applied by yourself when needed to specify the colorspace encoding of a resource (images, alphas, materials, …). If you import a roughness texture, as it is scalar data you will have to specify the “colorspace” as “raw”, so no special decoding is applied.

Input

Data that need to be processed, can be anything but in our case it is pixel data, like an image texture, a brushstroke, a procedural noise, …

If it is scalar, we don’t need to decode it. We must specify that we don’t want color-transformations by specifying for example the colorspace=”raw”.

If it is color this means that the data has been mandatorily encoded in a given colorspace. You can hope that this encoding is specified somewhere, like in the name, in the metadata, … But as color-management is a big mess still in 2021 most of the time we will assume that it’s in sRGB colorspace with a transfer-function depending on the file format used.

In sp the Input section can be found on the image slot of each layer. See Input Setup in Sp ..

Workspace

Everything you create, modify go through it. We define how it is configured so we can always know “where to go” when transforming an Input. In sp this is the “Working color space”. In OCIO term it corresponds the scene_linear role (also the reference one).

Even though sp doesn’t support OCIO role, it read the scene_linear one to use it as the Working Colorspace.

Display

Once the data has been processed through the Workspace you might want to preview it. To do so, everybody will be using some kind of hardware display, usually a computer monitor. This might sound dumb but it is a critical step. So here we need to convert the Workspace data to Display data, and there is a lot to do here.

We can see the Workspace as an “open-domain”, where data can be stored in some fancy colorspaces, reach some very high values, … (it can also be closed with data being already closer to the Display domain). We can then see the Display as a “closed-domain”, it except a kind of particularly encoded signal and has limits clearly defined. Knowing the source (Workspace) we can define the transformations required to convert it to the target (Display). This involved at his core, colorspace primaries conversion (if Workspace colorspace is different from the Display ones), transfer-function encoding/re-encoding (to convert a linear Workspace to a Display requiring the sRGB transfer-function), and at a more advanced stage, a dynamic-range conversion (still if required). This last step is usually called “tonemapping” where we try to make the open-domain that is the Workspace fit into the Display closed-domain.

Damn that’s a complicated one, but anyway, what you have to keep in mind is we are encoding data for a delimited domain defined by the display you are using.

In sp the Display section is handled by the view-transform dropdown, that you can find at the top-right of your viewport. See Display Setup in Sp .

Output

But isn’t the Display the Output ? Yes, it can be, if you are at the end of the chain. But here in sp, the end of the chain is our exported texture files. The Display only allow us to have a preview of how they could look.

So here, we will encode the Workspace data, has it is required for the next pipeline step. Encoding will depend on what you need in the next step and what container (image format) you chose.

In sp the Output section happens during the textures export process. See Output Setup in Sp .

Example

To illustrate the theory here is a diagram representing a section of a potential VFX-pipeline. I hope this will not confuse you more than this topic already is.

• I voluntary chose different colorspace across departments and sections to accentuate potential transformations.
• It has been chose to work with ACES for the color-management.
• Let’s assume all the users working on this pipeline have access to the same display which is a DCI-P3 calibrated monitor.

~

You made it yay ! Color-science is a complex topic, so don’t worry if you don’t get everything the first time. You will find additional resources to continue your exploration at the end of this article.

Now, let’s put into practice the theory …

Custom config

The first option is to use the Custom option and manually look for the path to the config.ocio file on your disk.

See the bottom section Substance parameters for OCIO configs to continue the setup.

Environment variable

The above might be enough for individual artists but being in a pipeline environment requires other ways to set OCIO automatically.

On Windows you have 2 ways to set environment variables :

Global Settings

You create a new variable named OCIO with the path to the config. This variable will be used by ALL software that can read it. (unless overridden).

This is not a recommended solution as you pollute your environment variable + if you decide to switch the config for another one all your previous project will be broken.

set "OCIO=C:\aces_1.1\config.ocio"

start "" "C:\Program Files\Allegorithmic\Adobe Substance 3D Painter\Adobe
Substance 3D Painter.exe"

Substance parameters for OCIO configs

It corresponds to all the sections below the color-management mode. It allows to configure how inputs react with the OCIO config, i.e which colorspace is being assigned by default.

Usually, in other software, this section is configured using the OCIO roles defined in the OCIO configuration. But currently sp support only its own OCIO roles. Which mean you might have to manually setup this section to get a correct result with the auto settings OR make sure the OCIO config you are using have the OCIO roles supported by Sp.

If you look at the above image, this is how it is supposed to look when picking the Substance config. As the Substance config have the supported OCIO roles defined, the parameters are properly configured.

But if you are loading a custom config, make sure these options are properly configured with the intended colorspaces for each format if you want all the auto options to work properly. Most of them (except Export ones) can be changed in context in last resort.

Visit the ACES Workflow section to find how this should be considered if you are using the ACES config.

~

Since 7.4.2 you can also find a new Standard sRGB color space parameter which is a very nice add for having UI elements properly managed. If the name doesn’t looks clear, it correspond to the sRGB - Display encoded colorspace. From the documentation, it is used :

• To convert color set in the hexadecimal field of the color picker.
• To save and load color swatches within the color picker.
• To be listed as a Display in the color picker list.

This update also adds support for specific OCIO role which are the following :

substance_3d_painter_bitmap_import_8bit
substance_3d_painter_bitmap_import_16bit
substance_3d_painter_bitmap_import_floating
substance_3d_painter_bitmap_export_8bit
substance_3d_painter_bitmap_export_16bit
substance_3d_painter_bitmap_export_floating
substance_3d_painter_substance_material

Check the Substance’s OCIO documentation for more details but make sure your OCIO config have these fellas set with the corresponding colorspace if you want it to be properly read in Sp.

Displaying Color and Scalar data

Sp will handle it for you automatically, depending on the channel you are previewing.

The full list of color-managed channels is available here.

For example, selecting the Roughness channel for preview will disable the view-transform :

Custom User Channels

If you are using a custom User channel, you will have to manually specify if the channel is color-managed. (By default they are not) This is achieved by clicking on the gear icon > Color channel.

Shelf Resources

In Sp this manipulation takes place, weirdly, on the images slots of each layer. You will not find any option to specify the colorspace in the shelf.

By default, it is set to auto, which will use the settings specified in the project color-management menu explained above.
(Substance parameters for OCIO configs).

I recommend always modifying this option to the proper colorspace to be sure the resource is properly color-managed.

Another option is to have the source colorspace specified in the file name. That’s in my opinion a bit messy because the colorspace has to be the exact name used in the config. If 2 configs used a different name, your image will only work for one. If I take for example a colorspace name used in the ACES config this could give: bricks_wall_albedo_Utility - Linear - sRGB.exr.

The color-picker

As used as feared by artists. It never react how the artist wants and looks to be made out of dark magic (at least in Mari 🙃 ). Did the sp implementation bring any good news ? Let’s see.

Abbreviations used:

• tcd : top colorspace dropdown
• eds : editable sliders, where you can manually enter your color components.

A good feature is the little info icon, giving explicit info on how the widget works. If we have a look at the info message next to the tcd we can read :

Color mixing space, this is the space in which a color is edited before being converted into the working color space. It usually matches the monitor to be easily viewed.

Which means the values in the eds are in the colorspace specified by the tcd, then they are converted to the working colorspace. (you can check the result of this conversion just under.)

This is a valid workflow, which allow you to get the same color seen in the UI on the final textures.

But keep in mind that you have to be careful on the color you are chosing, the fact that it looks as you want (perceptual) doesn’t mean the scene-refered values (working colorspace) have a physically plausible value. For exemple, in an ACES workflow you might want to make sure that no channel’s value goes up to 1.0, which mean you are reaching the boundary of the ACEScg gamut which is comparable to a laser’s color.

What about the actual picker ?

The picker will pick the value at display, so with the view-transform applied (if not disabled). Consider this as the input, and will convert from the tcd colorspace to the working colorspace. You then get back “nearly” the same value (with some math precisions issue ).

What I recommend though, is to change the view-transform to a “no-operation” colorspace (usually called raw), pick the color, and re-apply the previous view-transform. This will avoid the potential colorspace invertibility and imprecisions issues.

So I must say that the latest update have greatly improved the color-picking experience which behave a bit more as you would except. Cool stuff ! Looking forward to next updates to reach the perfect color-picking experience haha.

Environment

There is no direct option to modify the environment image colorspace.

From 7.4.2 + you can find an option in the Display Settings Menu, to change the environment colorspace being used.

For the other versions you still have the following options:

• Modify the default Linear colorspace in the project settings. The environments maps will use it.
• Include the source colorspace in the name of the HDRI. It has to be the exact same name as defined in the config. Example : myhdri_ACES - ACEScg.exr. (you can find an example in ACES - Environment)

Masks

When you right-click on a mask you have the option to Export mask as File. Don’t worry, mask seems to always be considered as scalar and exported without any treatment.

ACES - Display

Not much new, use the view-transform that correspond to the display you are using. (In my case ACES - sRGB, that behind the scene, uses Output - sRGB)

ACES - Inputs

For every external resource you import, you need to assign the correct input colorspace if the automatic one doesn’t correspond. The usual rules for the ACES workflow apply.

ACES - Colorpicker

Everything in The color-picker section applies here. You can just except more odd behavior as a wider-gamut and more complex view-transform will not play well with it. The first potential issue that came to my mind is the combinaison of 0-1 clamping + ACES ODT : If you are picking a pure value of RGB(1,1,1) considered encoded as Output - sRGB, you would usually get back a scene-referred value of RGB(16.2,16.2,16.2). But the color-picker is clamped between the 0-1 range so you will end up with just RGB(1,1,1).

Then consider the following example :

I have an ACEScg value of (1,0,0) which is damn too saturated and no object except laser are that saturated.

What if I want to apply a color we gave me as hexadecimal ?

Consider my brand’s green picked from https://coolors.co .

Well … the less brain-damaging solution would be to just eyeball the color.

Luckily, the 7.4.2 update made thing easier for us. The hexadecimal color will assume to be encoded in the sRGB standard colorspace and converted to the working colorspace. So just copy/paste your color in the hexadecimal field and you should have your color converted.

Even with this, you might notice that the color is still not similar to the sRGB one. This is normal and inherent to the ACES ODT which apply a “creative” and “technical” transformation on display.

So keep this in mind: you will never be able to match the look of the sRGB workflow with the ACES workflow. (unless cheating).

I’m not going to dive into further explanations as there is enough ACES central threads on this subject and Chris is also explaining it here.

ACES - Output

Do yourself a favour here and only care about EXR. You don’t need anything else and this is the file format recommended by the Academy for ACES data encoding.

If you choose EXR, you have nothing to care about. Color channel will be exported in ACEScg while scalar channel will bypass any color-transform encoding. Simple as that.

Reminder that you can choose to remove the $colorspace token in your export template map name to avoid unwanted special characters in your file name. (and instead export the textures in a folder named ACEScg)

Display components mismatch

OCIO divide the Display section into 3 components :

• Display : the physical hardware you are using (monitor, TV, phone, …).
• View : a way to encode the data for a specific viewing purpose.
• Look : a creative layer of modification on the data. ex: a grade.

Why do I explain you this ? Because these components are often mismatched or forgotten. Unfortunately, Substance makes no exception here.

If you look at the view-transform screenshot above, you can see that each option has the Default prefix. If we have a look at the config.ocio file from the Substance config, we can see why :

What should be a display or a separate view is actually all merged into a single view component !

Here is how it should look :

displays:
  sRGB:
    - !<View> {name: Display, colorspace: sRGB}
    - !<View> {name: ACES, colorspace: ACES sRGB}
    - !<View> {name: False Color, colorspace: False Color}
    - !<View> {name: Raw, colorspace: Raw}
  Display P3:
    - !<View> {name: Display, colorspace: Display P3}
    - !<View> {name: False Color, colorspace: False Color}
    - !<View> {name: Raw, colorspace: Raw}
  Rec709 :
    - !<View> {name: Display, colorspace: Rec709}
    - !<View> {name: False Color, colorspace: False Color}
    - !<View> {name: Raw, colorspace: Raw}
  Rec2020 :
    - !<View> {name: Display, colorspace: Rec2020}
    - !<View> {name: False Color, colorspace: False Color}
    - !<View> {name: Raw, colorspace: Raw}

Here is the result of the above in Substance Painter :

Using OCIO v2 there are other ways to improve how the config is built. Heads up to Improving the Substance OCIO config to see how.

But even with this fix, it’s not very friendly to have a long list of merged (display + view) while you would only need one Display most of the time. The best solution here would be to have 2 dropdowns : One to choose the Display, and one to choose the corresponding available View. We should even get a third one for looks as we are going to see in the next section :

Partial Look support

In above explanations where I mention OCIO Display is build with 3 components, we now see that I didn’t mention the last one yet: Looks.

Looks is a color-tansformation performed in any colorspace aimed at modifying the data in a creative way. This would allow for example the artist to have a first look at how its renders could looks like after the di pass.

Usually, Looks are defined similar to colorspaces, as a list, but you can also make a Look available in a display’s view:

displays:
    sRGB:
        - !<View> {name: Display, colorspace: sRGB-Display}
        - !<View> {name: Display Grade A, colorspace: sRGB-Display, looks: gradeA}

looks:
- !<Look>
  name: gradeA
  process_space: rclg16
  transform: !<FileTransform> {src: look_A.cc, interpolation: linear}

In the best case, we should have a dropdown menu that would allow us to combine the current view-transform with any Look defined. A good example of this is Blender :

Unfortunately, sp didn’t implement this feature yet. So we can only rely on merging the look in a display view for now.

A good way to test this is using the Filmic OCIO config by Troy Sobotka. The filmic encoding is correctly available in a View but require an extra step to be correctly displayed. By default it is a flat log representation, and require choosing a Look with the desired contrast amount.

To have it working in sp, it is required to merge the Look in a new View.

displays:
    sRGB:
        - !<View> {name: sRGB OETF, colorspace: sRGB OETF}
        ...
        - !<View> {name: Filmic Very High Contrast, colorspace: Filmic Log Encoding, look: +Very High Contrast}
        ...

Which in sp, if we kept all the contrast amount, give us a very long list of cropped name 😬 But at least it’s working.