In this article we will investigate what happens when you see a 'OCIO color space not available' warning when rendering with Redshift in Houdini. We will first (part 1) briefly walk through a correct color space setup based on the default Redshift settings. After that (part 2) we will force our render to show OCIO color space issues, and (part 3) explain why it happens and how to fix it.

Part 1 - Setting it up correctly based on redshift default settings
Part 2 - OCIO Warnings, errors and mismatches
Part 3 - How to fix ocio related issues

Part 1 - Setting your render up correctly based on Redshift's default settings

1.1 - Assigning the correct color space in Houdini

When rendering with Redshift in Houdini. The first thing you might want to double-check is your Houdini default color space. Redshift defaults to ACEScg. 

In order to learn what color space Houdini is currently using you can open the OCIO Settings panel in Houdini. You can find that in Edit --> OCIO Settings.

As you can see in the screenshot below, in Houdini the default is often set to a Rendering Working Space of 'Linear Rec.709 (sRGB)' and a view transform of 'Un-tone-mapped'

In the OCIO settings panel you can also verify at the bottom that this is using Houdini's built-in default .ocio config file. In Houdini 20.5, the default OpenColorIO (OCIO) configuration file is located within the Houdini installation directory. Specifically, you can find the .ocio file at:

C:\Program Files\Side Effects Software\Houdini 20.5.x\packages\ocio\

Here, 20.5.x represents the specific version number of Houdini 20.5 you have installed. Within this directory, you'll find the OCIO configuration file, typically named something like houdini-config-v2.1.0_aces-v1.3_ocio-v2.3.ocio.

In order to work with Redshift's default render settings (which default to ACEScg), you need to match the settings here as well. In that case you can set the Render Working Space to 'ACEScg' and the View Transform to 'ACES 1.0 - SDR Video' as shown in the example below.

1.2 - Verifying what .ocio config file is used in your current Houdini build.

Let's say that you have a custom .ocio file set. For example, you might want to force Houdini to use Redshifts own built-in .ocio file, or another custom .ocio profile file that you are currently using in production.

Let's say for example that you have the following environment variable set in Houdini:
OCIO = "C:\ProgramData\redshift\Data\OCIO\config.ocio" it will point to Redshift's built in .ocio.

If you open Houdini now, you will be able to verify that your Houdini is now using that .ocio config file instead. This will now also default to ACEScg with view transform set to un-tone-mapped.

1.3 - The correct render  settings inside the Redshift ROP node.

Inside the Redshift ROP you will also have a place where you can set/change the color settings if needed.

If you set the Redshift ROP rendernode node to advanced, you will see extra tabs. In there you will find a TAB called 'Globals'. Inside that Globals tab you will see a Rendering Color Space section. This defaults to ACEScg in Redshift. (Note: this panel will also tell you what .ocio config file your scene is currently using)
 

1.4 - Color space settings in shaders.

The textures that you use also have their own color space setting.

generally you want to use the following rules.

1. Color Textures (Albedo/Diffuse, Specular, Emissive)
Set the Color Space to: sRGB - Texture

These textures are typically authored in sRGB because they are meant to display correctly on monitors.
Redshift will automatically convert them from sRGB to ACEScg for rendering.

2. Utility Textures (Roughness, Metallic, Normal, Displacement, etc.)
Set the Color Space to: Raw/Linear
These textures are data maps, not color maps. They should not have any gamma correction applied (which sRGB would do). Using Raw/Linear ensures these textures are passed through unchanged.

3. HDR/EXR Environment Maps
Set the Color Space to: ACEScg (or whatever color space the map is authored in)
HDR and EXR environment maps are typically already in a linear color space. If the map is authored in ACEScg, ensure you select ACEScg in the dropdown to avoid double transformations.

1.5 - Color settings in the Houdini camera

Besides the ROP and the textures that you use, in Houdini you need to make sure that your camera also has the correct settings.

Of these dropdown lists appears empty, try reopening your scene file. If that fails consider adding these parameters by clicking the redshift camera settings. You will be able to find a button inside the Redshift pane called "CamParms".

With all settings as discussed above we should see a correct render showing the correct colors, both in the Redshift Renderview as well as on disk.

Part 2 - OCIO Warnings, errors and mismatches

2.1 - Adding a custom .ocio config file

Let's now attempt to force a very common OCIO error. We will do this by first assigning an OCIO config file that will be a mismatch compared to how we saved our previous scene. 

I will first assign an older OCIO profile to Houdini by adding this as an environment variable.

If we now open Houdini we will be able to verify that this .ocio is indeed being used in my scene file.
You can also see that with this specific .ocio profile the default Rendering Working Space is now ACES - ACEScg and the view transform is sRGB D60 sim.

If we now render our scene we will soon be able to notice that the colors might look wrong. At the same time, you will now be able to see a warning at the bottom of the Redshift Renderview.

2.1 - Understanding the mismatch and the ocio warning

If you click that bar at the bottom, it will allow you to open the Redshift Feedback Display. In there you can go to menu and click File -> Open Log

In the log you will be able to see several yellow warnings related to OCIO.  

Let's take a look at one of those before investigating what actually caused this warning.

Basically the warning is telling us that when rendering. redshift could not find the desired OCIO settings. In this example, neither in the display settings nor in the view settings. Therefore it reverted to whatever the default was in the current .ocio file. That's why the render does not crash, and why this is merely a warning and not an error. However, the result of this is that we are currently not seeing the correct colors in our render. Whatever the default color space is in the current .ocio file is not what we used when we created the scene and saved the file.

Specifically for the display, redshift was expecting and looking for 'sRGB - Display' inside the .ocio config file. But that name does not exist at all in the current (custom) .ocio config file that we are now using.

If we now look at the redshift ROP, the camera as well as the texture node. You will be able to verify that these are now all set to something we did not use when we created the scene in the first place.

We already saw that the default Rendering Working Space is now ACES - ACEScg and the view transform is sRGB D60 sim. The texture shader in this scene is now pointing to an auto-assigned color space.

 The camera is now showing these incorrect display settings:

And the Redshift ROP is now showing these settings. It's now set to "ACES - ACEScg" instead of "ACEScg".

All these settings are not matching what we had when we first created and saved the scene file.
What exactly is failing here? Why exactly are we getting these warnings and this color mismatch?

When you open a .ocio config file it will contain many named definitions of color spaces. In our case for example, in the original scene file, the Redshift ROP was specifically pointing to a color space named ACEScg. This name does not exist in the newly set .ocio config file. Therefore it now defaults to whatever its defaults were, in this example that is 'ACES - ACEScg'. This name sounds alike, but they are not the same. The names need to match 100%.  

Let's now dive a bit deeper, and actually open both .ocio config files to verify this.

Here you can see what names exist in both files. On the left you can see the custom config file that we are now using in this example, an old aces_1.0.2 config file. On the right you can see what we have inside the default built-in Redshift config file.

This is what caused our colors to fail and the warnings to appear. Basically in this case when rendering, the renderer is looking for a color space name that simply does not exist in the current .ocio config file that is being used. The exact name ACEScg does not exist as a name in the currently used config file.

2.2 POST FX, LUTS etc are not applied.

By default POST FX adjustments such as LUTs are not applied. The checkbox that you can find inside the Output --> Post Effects tab in the Redshift ROP shows that some checkboxes are unchecked by default.

Several of these checkboxes enable the render to take into account the use of Color Management, LUTs (Look-Up Tables), and other color adjustment controls. Generally this is something done in POST. However if you change any of these settings inside of the redshift POST settings, then checking these checkboxes will also show them in your render. 

If you use a custom LUT for example, and if you notice that you don't see your LUT applied when rendering to MPlay in Houdini, then make sure to check the MPlay Color/LUT/Controls checkbox.

The Photometric Exposure is checked by default. These checkboxes take into account the changes that you make to the Photographic exposure either in Post FX or in your Camera. These settings are fully linked to each other. Changing the one, will automatically also change the other.

Part 3 - How to fix ocio related issues

3.1 - OCIO warnings

Based on the examples above we can clearly learn that in order to prevent ocio errors you simply need to make sure that the current ocio config file contains the same color profile names compared to what was used when the scene was first created and saved with.

When in doubt, open the Redshift log file or the Redshift feedback display, and carefully read the warning message. It will tell you what it is expecting and what it could not find (a) as well as what settings have been changed/adjusted to a default (b) based on the current .ocio config file that is currently being used. 

3.2a - Verify texture naming conventions for automation

Inside the Render ROP advanced users sometimes enable the 'Use OCIO File Rules' checkbox. This is sometimes used in cases where automation is an important part of production. This feature is unchecked by default.

What It Does: This option enables Houdini to use the file rules defined in the OCIO configuration file. OCIO file rules are a way to automatically detect and assign color spaces to files (e.g., textures) based on their names, extensions, or other metadata.

When checked, Houdini will refer to the file rules section in the OCIO config to determine which color space to assign to imported textures or other input files. For example:

- A file named texture_diffuse_sRGB.png might automatically be assigned the sRGB color space.
- A file named texture_roughness.exr could be assigned a linear color space like Linear.

It automates the process of assigning correct color spaces to textures and inputs, reducing the chances of human error. It ensures consistency in workflows, especially for large projects with many assets.

What Happens If Unchecked:

You will need to manually assign color spaces to textures and files. Houdini won’t attempt to interpret file names or extensions. This is the default.

When using this feature for automation purposes make sure to verify texture naming conventions 

Using consistent naming conventions for textures (e.g., _sRGB, _Linear) can help automate assigning color spaces in Redshift when "Use OCIO File Rules" is enabled.
Mismatched names or poorly named textures could result in incorrect auto-assignments.

If your project or company adheres to a very strict naming convention for textures (e.g., diffuse_sRGB, roughness_Linear), this option can in some cases simplify the workflow by automating color space assignment.

3.2b Transform input colors to OCIO Rendering Space

In a similar way, Transform Input Colors to OCIO Rendering Space is not checked by default. This is by design. This way Houdini will assume that input colors are already in the rendering color space and won’t apply transformations. This can lead to incorrect results if the textures aren’t properly prepared.

What It Does: This option ensures that all input files (textures, colors, etc.) are transformed from their assigned color spaces into the OCIO Rendering Space (e.g., ACEScg).

When checked, Houdini applies the necessary transformations to align all inputs with the rendering color space. For example:

A texture in sRGB will be transformed into ACEScg.
Linear textures (e.g., displacement maps) won’t be transformed, as they are already in a linear space.

By default we don't want Redshift nor Houdini to make such changes by default. These features are often used in cases where automation plays an important role. 

3.3 - Post Effects and LUTs:

Why do we have Color/LUT/Controls disabled by default?
Be aware that when applying PostFX or LUTs directly in renders (e.g., enabling Color/LUT/Controls) this will bake those effects into the output image, potentially causing issues in post-production. Most studios prefer to have this disabled and to perform such tweaks in POST.

Similarly it's advisable to disable PostFX (e.g., Bloom/Glare, LUTs) for HDR outputs, as these should remain raw for compositing. Applying PostFX to HDR files might make them incompatible for downstream workflows.

3.4 - Global ocio profile & scope

You can also set a global .ocio environment variable by adding that environment variable to the machine itself. If an  OCIO environment variable is set in that way (global to the entire machine ), it will override Houdini's default OCIO file. That way, you might inadvertently load an incompatible OCIO config.

Alternatively your custom .ocio profile is not loading, consider adding it via Houdini packages (.json files) instead of adding it via the Houdini .env file.

3.5 - Viewport and-or Mplay  Mismatches:

If zou are experiencing viewport and-or Mplay mismatches (compared to what you see inside the Redshift Renderview), keep in mind that mismatches between Houdini’s viewport and Mplay's own color management and Redshift’s ROP settings can lead to discrepancies in what you see during previews versus the final render.

We recommend using the Redshift Renderview when working on the scene, and to render to disk afterwards.

For example, MPlay has its own OCIO settings. It defaults to sRGB - Display, and to un-tone-mapped.

However, when rendering with Redshift, it's best to set it to sRGB - Display for the display, and to change un-tone-mapped to ACES 1.0 - SDR Video.