Context Variable within Colorspace working in Nuke but not in Maya or Houdini

[andranikvfx]

Hello OCIO Team. I am in the process of authoring a config based off the ACES 1.2 config and i am running into some issues inside of Maya and Houdini (renderman). Has anyone had any luck with context variables within a colorspace?

!name: Input - CameraSpace family: “Input” equalitygroup: “” bitdepth: 32f description: | camera space based on context isdata: false allocation: uniform from_reference: ! {src: ACES - ACES2065-1, dst: $SHOT_CAMERA_SPACE } This colorspace is being referenced in a role camera_space: Input - CameraSpace which in turn is referenced in looks. This config works as expected inside of nuke but as soon as I introduce the Input - CameraSpace colorspace into the camera_space role the image goes super dark in houdini and maya.

Let me know if you need any other information.

Thanks in advance. Andranik

[michdolan]

Hi @andranikvfx , ColorSpaceTransform does support context variable expansion, so this should work. Is SHOT_CAMERA_SPACE static during your DCC session? You could confirm through their respective Python consoles (using PyOpenColorIO) whether the Context variables are resolving, and caching, as expected. I think you would see an error though if they are not, since it should result in a NULL color space, which will throw an exception before a Processor can be created.

[zachlewis]

I've been working with @andranikvfx to resolve his issue. There really does seem to be a discrepancy between how the config behaves in Nuke-12 versus Nuke-11 / Maya-2020 / Houdini-18.0 on Windows, all other environment variable considerations being equal. In Nuke-12, the config behaves as expected; everywhere else, the ColorSpaceTransform operation behaves like a NoOp instead of throwing.

SHOT_CAMERA_SPACE is static, and is set in each DCC's runtime environment prior to invocation. Andranik also tried setting environment variable defaults in the config itself to static values and opening the config in vanilla DCC environments (i.e., with OCIO and SHOT_CAMERA_SPACE unset) -- each application behaves consistently in both cases.

Perhaps tellingly, setting SHOT_CAMERA_SPACE to a bad colorspace name doesn't affect behavior in Maya (i.e., the ColorSpaceTransform operator remains a NoOp), but does cause Nuke-12 to throw an exception.

I haven't confirmed which versions of OpenColorIO are used by each application. Could the difference in ColorSpaceTransform behavior be explained by differences in OpenColorIO release versions, or is something else going on? IIRC, Foundry forked OCIO for Nuke-12; I wonder if this is something they addressed internally?

[andranikvfx]

After much debugging with the help of @zachlewis here are some updates.

1. Nuke 12.1v4 behaves as expected. ${SHOT_CAMERA_SPACE is set to Input - RED - REDLog3G10 - REDWideGamutRGB before Nuke is launched and the Input - CameraSpace colorspace looks correct.
2. We tested the same behavior in Nuke 11.2v4 and the results matched what I was seeing in Maya and Houdini.

The solution I came up with, which may help others that are in a similar situation was having a different config.ocio file for different camera colorspaces. Each shot has a colorspace tagged in our database which will be pointed to the respective config.ocio file. Before the application is launched the ocio variable will point to the config.ocio that matches the colorspace for the shot. This way we only have a handful of ocio.config files the represent each camera's colorspace instead of having a config per show.

[chrisbrejon]

Hello @zachlewis @andranikvfx it would be super neat if you could reply to the original thread on ACEScentral : https://community.acescentral.com/t/context-variable-within-colorspace-working-in-nuke-but-not-in-maya-or-houdini/3222

So ACES users also have an answer on this topic. Thanks !

[zachlewis]

Could someone from Foundry verify whether or not they made changes to the OCIO that ships with Nuke-12 that might explain these behavior discrepancies? If so, could / should these changes be pushed upstream?

[sharktacos]

I’m seeing the same results in Nuke 12 and Maya 2022 so I’m wondering if this issue has been resolved. Can somebody confirm?

[remia]

There really does seem to be a discrepancy between how the config behaves in Nuke-12 versus Nuke-11 / Maya-2020 / Houdini-18.0 on Windows, all other environment variable considerations being equal.

Are these issues specific to Windows?

[zachlewis]

There really does seem to be a discrepancy between how the config behaves in Nuke-12 versus Nuke-11 / Maya-2020 / Houdini-18.0 on Windows, all other environment variable considerations being equal.

Are these issues specific to Windows?

I believe so, but I'm not certain. It's been a while. @andranikvfx could only test on Windows, and I haven't verified with the same constellations of DCCs, configs, and environments on other platforms; but IIRC, I was not able to reproduce on CentOS-7.6 / Nuke-11.X / Houdini-17.5.