Hello,

We are starting a new project with H20 and this ACES configuration: cg-config-v2.0.0_aces-v1.3_ocio-v2.2.ocio
Downloaded from here: https://github.com/AcademySoftwareFoundation/OpenColorIO-Config-ACES/releases/tag/v1.0.0 [github.com]

Building a simple MaterialX shader in /stage context materiallibrary reveals there are quite a few missing ACES colorspace transforms missing to convert a mtlximage from sRGB to ACES, or Lin Rec709 to ACEScg. All of the existing items in the MaterialX/Colortransform menu convert to Lin Rec709. We would expect nodes to convert to ACEScg as well. (for example: sRGB to ACEScg, and Lin Rec709 to ACEScg)



Could the existing nodes in this menu be inverted?


Also, the mtlximage node has a "File Color Space" field with a dropdown menu of existing colorspaces available in the ACES config we are using. We would expect a selection of one of these colorspaces as the input color space would do a colorspace conversion to ACEScg at render time. (also called "Lazy ACES"). But field has no effect, no matter what we try.


Is this something SideFX is aware of? Your thoughts or workarounds are appreciated.


Thank you.

Mike

mkschmitty
Building a simple MaterialX shader in /stage context materiallibrary reveals there are quite a few missing ACES colorspace transforms missing to convert a mtlximage from sRGB to ACES, or Lin Rec709 to ACEScg. All of the existing items in the MaterialX/Colortransform menu convert to Lin Rec709. We would expect nodes to convert to ACEScg as well. (for example: sRGB to ACEScg, and Lin Rec709 to ACEScg)

If you are rendering with karma, the karma ocio transform node provides a more comprehensive solution. The limited set of nodes provided by the MaterialX consortium cannot possibly cover every possible combination an OCIO config could require--since each transform is hard coded.

mkschmitty
Also, the mtlximage node has a "File Color Space" field with a dropdown menu of existing colorspaces available in the ACES config we are using. We would expect a selection of one of these colorspaces as the input color space would do a colorspace conversion to ACEScg at render time. (also called "Lazy ACES"). But field has no effect, no matter what we try.

This parameter has no effect as the USD implementation of MaterialX does not support it. Only selecting the Signature (vector vs Color) changes the color space from no conversion with the vector signature and automatic conversion to scene linear with the color signature--automatic being defined by the config's rules and other settings.

For best results, pre-convert images to the required scene linear, or use a naming convention in combination with a config file rules to apply the appropriate color space conversion. Alternatively, use the 'vector' signature to force no conversion and use the karma ocio transform node.

Thank you so much for the reply. Now this is making sense.

I didn't realize the mtlximage node automatically converts the colorspace of the input image to scene-linear -- in this case "ACEScg" since this is the OCIO "Render Working Space" in Houdini as determined by the ACES config file. And, if Signature is set to Color, and that the "File Color Space" field has no effect on the colorspace transformation. Good to know.

And it appears the colorspace transformation is triggered by the file type? This is the behavior I observe:

- .hdr or .exr is assumed to be Linear Rec.709 and therefore a color transformation from Linear Rec 709 -> ACEScg occurs.

- *A gotcha - if the .exr or .hdr is encoded in ACEScg colorspace, it's important to set Signature to Vector 3 so no color transformation occurs.

- .jpg or .png is assumed to be sRGB - Texture, so is color transformed to scene-linear (ACEScg).

Is there any internal code we could tweak to set a rule such that if "ACEScg" is in the filename, it sets "Signature" to Vector 3 automatically? This would reduce user error.

Thank you for your feedback. We appreciate the clarification.

mkschmitty
And it appears the colorspace transformation is triggered by the file type? This is the behavior I observe:

- .hdr or .exr is assumed to be Linear Rec.709 and therefore a color transformation from Linear Rec 709 -> ACEScg occurs.

- *A gotcha - if the .exr or .hdr is encoded in ACEScg colorspace, it's important to set Signature to Vector 3 so no color transformation occurs.

- .jpg or .png is assumed to be sRGB - Texture, so is color transformed to scene-linear (ACEScg).

Is there any internal code we could tweak to set a rule such that if "ACEScg" is in the filename, it sets "Signature" to Vector 3 automatically? This would reduce user error.

this behavior is defined in the config itself. Look for 'file rules' to change the behavior. If your working space is ACEScg, you should probably also change the assumed color space for exr to ACEScg.

I tried this and it doesn't appear to make a difference.

As per your suggestion, here's the new rule list in our config:

file_rules:
- !<Rule> {name: OpenEXR, extension: "exr", pattern: "*", colorspace: ACEScg}
- !<Rule> {name: Default, colorspace: ACEScg}

When the my scene is reloaded (after restarting Houdini), the EXR texture appears different when I switch between Signature = Color, vs. Signature = Vector 3. I would expect them to be the same. (The texture looks correct when I switch to Signature = Vector 3)

Also, changing the Default rule colorspace to ACES2065-1 or "default" makes not difference.

mkschmitty
I tried this and it doesn't appear to make a difference.

As per your suggestion, here's the new rule list in our config:

file_rules:
- !<Rule> {name: OpenEXR, extension: "exr", pattern: "*", colorspace: ACEScg}
- !<Rule> {name: Default, colorspace: ACEScg}

When the my scene is reloaded (after restarting Houdini), the EXR texture appears different when I switch between Signature = Color, vs. Signature = Vector 3. I would expect them to be the same. (The texture looks correct when I switch to Signature = Vector 3)

Also, changing the Default rule colorspace to ACES2065-1 or "default" makes not difference.

It doesn't do that for me. A exr image loaded with mtlx image set to color or vector3 looks the same either way when using a config tagging exr as ACEScg and a working space of ACEScg. Are you sure you saved the changes to the config and that Houdini is picking it up? It's pretty easy to save the config from the OCIO editor while Houdini is looking somewhere else.

Thank you for checking and confirming it works.

I looked back at the houdini scene I was testing yesterday and made sure it was reading the correct config file. (opened a new shell, opened a new houdini etc.) -- and it still didn't work.

Then tried copying the nodes from the non-working Houdini scene to a fresh Houdini, and it's still doesn't work.

I then built a fresh houdini scene from scratch, using the exact EXR texture and it WORKS! -- switching between "Color" and "Vector 3" gives me the same results.

This led me to wonder why the scene from yesterday wasn't working, it's basically the same Karma rendering setup.

I then noticed... that I was using Karma CPU in the viewport for the scene that works, and Karma XPU for the scene that doesn't work.

Could you confirm this on your end? Using both Karma CPU and Karma XPU, switch between "Color" and "Vector 3" and see what you get.

Thanks!

Here's my houdini scene + EXR image if you feel like giving it a try.

I think I figured it out. I noticed Houdini creates a .rat file from the .exr automatically.

So I added this line to the ACES config file

- !<Rule> {name: rat, extension: "rat", pattern: "*", colorspace: ACEScg}

To tell Karma that .rat files are also ACEScg

Now Karma CPU and XPU give me the same results when switching between "Color" and "Vector 3"

I think without this line, Karma XPU was interpreting the .rat file as Linear Rec 709.

(Though, Karma CPU isn't -- does this mean Karma XPU requires the auto generatied .rat file and Karma CPU doesn't?)

mkschmitty
I think I figured it out. I noticed Houdini creates a .rat file from the .exr automatically.

So I added this line to the ACES config file

- !<Rule> {name: rat, extension: "rat", pattern: "*", colorspace: ACEScg}

To tell Karma that .rat files are also ACEScg

Now Karma CPU and XPU give me the same results when switching between "Color" and "Vector 3"

I think without this line, Karma XPU was interpreting the .rat file as Linear Rec 709.

(Though, Karma CPU isn't -- does this mean Karma XPU requires the auto generatied .rat file and Karma CPU doesn't?)

The XPU file should contain metadata that indicates their colorspace. Most likely the rat file was generated with an old config and is in the wrong color space. I would delete the auto generated rat files when changing the config rather than hard code them to be ACEScg. I'm not sure they will always be working space since rat files can also be 8bit sRGB images (but perhaps if autogenerated ones won't be.)

Good to know. I was worried about hardcoding the colorspace of the autogen .rat files. Thanks again for your help. Progress!