Getting started with OCIO in RV

RV has a couple of nodes that can be used instead of or complimentary to the RV’s color pipeline.

You can get some info about OCIO in RV here: OpenColorIO Integration

If you check out the OCIO package info in the Package manager RV -> Preferences -> Packages -> OpenColorIO Basic Color Management , there’s a bit of a description about how OCIO can be auto-setup via a script. You can create file in your support path under the Python directory to have your own script auto-determine color pipeline.

Attached is a minimal example that might serve well as a bootstrap for setting up your config. The ocio_config_from_media is called when needed and helps you dynamically set up your config. You can even create the OCIO config programmatically if you so wanted to, or just set it to an appropriate config location, set the environment variable and be done. (2.2 KB)

Drop the file as in your PYTHONPATH (such as in your Python path in your RV_SUPPORT_PATH) and this will prove as a configuration script and entrypoint for your OCIO setup.

If you look under Open Color IO Integration docs, there’s a ocio_context component. The OCIO context variables can work off of environment variables, but environment variables for context variables in OCIO are not required.

The way this works is, by default, OCIO context variables will incorporate any environment variable as a fallback. But in the setting up a node, you can also define additional context variables. This allows each node to have its own context apart from your environment, therefore no special environment variables are actually needed.

So while the example script defines the context based on the environment variable and uses a default value like this:

 "context"    : {"SHOT" : os.environ.get("SHOT","def123")}

the context could just as easily be defined by some other lookup, such as one defined by a function that looks it up from Shotgun. For example, this:

 "context"    : {"SHOT" : findShotgunShotByMedia(media)}


I know that this is a LOT of information, but let’s go through an example pipeline setup.

If you’d like to follow along, you can download the basic ACES OCIO config from the official Github page: GitHub - imageworks/OpenColorIO-Configs: Color Configurations for OpenColorIO

I don’t know what your color pipeline looks like but let’s say you have 3 different transforms: [Linear -> ACEScc] -> [File Transform] -> [Rec709 -> Linear] before it ends up being converted to whatever Display you have. Do you have control over how the OCIO config is structured? If you do, you can avoid a lot of RV-related hassle by defining what you need in the config itself. We recommend storing look-related transforms on the look node, but I think you should be able to do a similar group transform on Colorspace nodes as well.

Given that, you would have something like this:

  - !<Look>
    name: role_color_my_look
    process_space: scene_linear
    transform: !<GroupTransform>
        - !<ColorSpaceTransform> {src: ACES - ACES2065-1, dst: ACES - ACEScc}
        - !<FileTransform> {src: "${SHOT}.spi3d", interpolation: linear}
        - !<ColorSpaceTransform> {src: ACES - ACEScc, dst: ACES - ACES2065-1}

And then in all you’d need to do would be to define roles for RVLookPipelineGroup:

    elif (nodeType == "RVLookPipelineGroup"):
        # If our config has a Look named shot_specific_look and uses the
        # environment/context variable "$SHOT" to locate any required
        # files on disk, then this is what that would likely look like
        result = [
            {"nodeType"   : "OCIOLook",
             "context"    : {"SHOT": "MY_010-010"},
             "properties" : {
                 "ocio.function"     : "look",
                 "ocio.inColorSpace" : OCIO.Constants.ROLE_SCENE_LINEAR,
                 "ocio_look.look"    : "role_color_my_look"}}]

Please note that "${SHOT}.spi3d" and "context" : {"SHOT": "MY_010-010"}, is how you’d go about defining shot-specific file transforms.

Some more reference:
OCIO contexts: Contexts — OpenColorIO RB-1.1 documentation
OCIO config syntax and GroupTransform reference: Config syntax — OpenColorIO RB-1.1 documentation

Now if you don’t have access to modifying the OCIO config and you inherit it from a client for example, it’s a bit more complicated. You’ll need to code a lot more in the We don’t have a node for colorspace, but each RV OCIO node is equivalent, so you can mix and match them as you like, but you’ll need to define the OCIO*.function attribute as per Help. This means that for an example pipeline of [Linear → ACEScc] → [File Transform] → [Rec709 → Linear], you can have:

OCIOLook node that does [Linear → ACEScc] and has a OCIOLook.function = color
OCIOFile node that does [File Transform] (your LUT) that has OCIOFile.function = look
OCIONode node that does [Rec709 → Linear] that has OCIOFile.function = color
OCIODisplay node that does your [Linear → Display] transform and has OCIODisplay.function = display


Hey, with the help of your guide, I am happy to report that we successfully created a subclass of the basic OCIO package, which loads our custom configs, sets spaces, etc.

We ended up baking a lookup file at “compile time” to avoid Shotgun requests, since RV is expected to be fast, apparently :slight_smile:

We haven’t got around to per-shot context variables yet, since it becomes more difficult to avoid querying Shotgun.

The next hangup we’re having is that the Channel Display options (bound to a r g b) do not work. It appears they are relying on the built-in color pipeline (in, or I might be interpreting it wrong.



Hi Mmoshev,

Check out the Color Channel Selection package that ships with RV, if you enable that, it’ll override the normal RGBA select mode with a mode that works similarly but is OCIO compatible.


Oh cool, thanks this works!


A post was split to a new topic: OCIO Setup Help (Steve)

@Michael.Kessler does the Color Channel Selection package have a color inspector also?
Pressing F5 with Channel Selection on throws an error invalid property name #RVLensWarp.warp.pixelAspectRatio, coming from rvui.render. I see the inspector is a separate module, so perhaps this has to be overridden to work with ocio?


I’d like to share our ocio package, which is built on top of the built-in one.

It selects an ocio config based on the media path, and selects color spaces depending on the media file type. (19.2 KB)

It can be built and installed with rvpkg, but I’ll defer these instructions to the manual for now.

Hopefully someone will find it useful as a base.



Thank you so much for sharing your package with the community!

This is a known issue that we’re aware of and tracking internally. It looks like some of our UI code relies on RV’s built-in pipeline and doesn’t have all the graceful checks for the OCIO pipeline. We’ll be fixing this in the future.

However, if you would like to unblock this for yourself, you can either insert a dummy RVLensWarp node into the pipelinegroup or change the code in $RV_INSTALL_PATH/Mu/ There’s a function called pixelAspectFunc. If you wrap this function to skip setting the LensWarp, it should work.

1 Like

@alexaz yeah thanks, we already did the former after a round with support.
Having to do this is really not a big deal for development, as long as it is known.
Having it here on the forum might help. Perhaps should also be in the docs (not sure what the best place would be).


the Color Channel Selection package is working fine for us. We are able to switch through the channels. But the “Alpha Type” is greyed out, which means we have limited optioins to merge CG layers in RV. Is there a workaround for this or will this be fixed with the future updates alexaz mentioned?!



1 Like

Hey Tobias,

That’s actually a bug on our side! I’ve made an internal ticket to fix it, thank you so much for catching it!

So what happens is that the alpha type is determined during the RVLinearize part of the pipeline, but in the OCIO case the RVLinearize node doesn’t exist and is replaced with OCIO nodes instead.

I don’t know if there’s a workaround… You could try to put the RVLinearize node back in the pipeline group, but you’ll get double color transforms alongside with the OCIO.

We’ll need to fix it on our end, so that OCIO is better handled through our pipe.


1 Like

Thanks for sharing this.
One thing that is missing is a step-by-step guide to pulling data from sg entities. I’ve been struggling to do this for some time without much success. A guide would be muchly appreciated! :slight_smile:


Could you elaborate a bit on “pulling data from sg”? If I understand correctly, you want to use something like the Shotgun api?


I actually finally managed to get this working.
I’ll try to prepare a little walkthrough when I have a chance so I can share it here.
When I mean “pulling data from SG”, I mean using Screening Room for RV to grab lut and cdl paths from shot entities so ocio env vars can be set dynamically on the fly. This doesn’t make direct use of the SG api, as I imagine that’s all wrapped in the RV screeningroom plugin.


Hi @Patrick if you could share how you got this working, it would be great. We would like to achieve the same thing at our studio. We use SG fields on a shot and show level to define CDLs, LUTS and Displays so would like RV to swap these out dynamically on the fly for each shot.


Hi, would it be possible to post what wrapping that function would look like? We’re stuck on 7.6.1 at the moment so would like to unblock this.

1 Like

@alexaz possible to post the snippet reflecting the change made in

Is there a simplier version of such a script? I mean, I have exactly one input role and one output role. No shot / asset dependencies what so ever. Just “in” and “out”?

Trying and failing to get OCIO set up with our context variables.

In my OCIO config I have something like


I’ve set my context in rv to hardcoded paths for now, hoping to work through that before I figure out dynamic stuff per shot.

"context" : {"SHOT_DIR" : "path/to/shot", "SHOT" : "shot_name"},

but it doesn’t seem to pass those contexts to the ocio search path. The error tells me “cannot find ‘$SHOT’ in search path”.

Any help?

Actually come to think of it, how do I even know RV is reading the script? It’s in my RV pythonpath at ~/.rv/Python

RV should pick it up if the environment variable OCIO is set in the system before starting RV.
The OCIO variable needs to point to the config.ocio file.