Karma, Cryptomatte and Fusion

If all you need to know is how to render Cryptomatte from Houdini’s Karma renderer so that it can be used in Fusion, here’s the secret sauce:

In your USD Render ROP, add the flag --exrmode 0 to the end of the husk Render Command. In 19.5 and later, there’s a checkbox for Enable Legacy EXR Mode that adds the flag for you, but in earlier versions you have to put it there yourself.

If you’re using the Karma HDA, you’ll need to unlock it and dive inside to find the ROP. Right-click the Karma node and choose Allow Editing of Contents. Then double-click to dive in. The Render Command in this version is long and complex, but you can still just add the flag to the end of it:

Okay, with that out of the way, let’s talk a little bit about why it’s necessary. OpenEXR, for all its goal of simplifying things, is a complex beast. Most of the time, artists can ignore that complexity—our software does a good job of managing it so we can keep our eyes on the pixels. But every once in a while something comes up that reminds us that it’s not just a simple grid of pixels.

EXR has two features that seem similar to one another and can cause some confusion. First, from the outset, it’s been capable of storing as many [tooltips keyword = “channels” content=”A grid of single-value samples. A typical color image is composed of three channels: red, green and blue. Additional data can be stored as auxiliary channels, the most common being alpha, which controls transparency.”] as you might want. You can pack your RGBA, Z depth, velocity vectors, UV texture coordinates, Normal vectors, and even the diffuse, specular and reflection [tooltips keyword =”AOVs” content=”Arbitrary Output Variables. Also known as buffers, render elements, or render passes.”] with their own RGB channels into one file. While that’s great for organization, it makes for bloated files that greatly reduce efficiency—if you’re not going to use the Normals for anything in your comp, it would be better not to pull them across the network.

Many artists therefore elected to split their various AOVs into discrete files. I’m not sure there’s a generally agreed-upon term for this. I call it “split-channel EXRs.” The multiple files are slightly larger than a single multi-channel file due to duplication of headers, but you can load only the channels you need instead of having to transfer everything. In Nuke, it can become annoying to manage versions since you’ll have so many different Read nodes. In Fusion that doesn’t matter as much because you have to have a separate Loader for most AOVs anyway (except for the specific ones Fusion already supports). 

When OpenEXR 2.0 came around, the format gained support for storing sets of channels in different parts which can be loaded independently. You no longer need to transfer the entire EXR—you can grab only the specific part you need. It’s a little like how Windows can open a single file in a compressed folder without needing to load the entire Zip file into memory. 

So a multi-channel EXR is not the same thing as a multi-part EXR. Not everyone understands the difference, though, so sometimes people talk past one another, never realizing that they’re not actually referring to the same thing.

And that brings us around to the Cryptomatte problem. Although Fusion itself can read the multi-part file, the Loader can only place one part on its output at a time, so the Cryptomatte Fuse doesn’t get access to all of the data it needs. It might require a custom Loader in order to read the Cryptomatte correctly, but the volunteer programmers who wrote the tool haven’t found the time to make that happen. 

So for the time being, we’re stuck rendering a separate Cryptomatte file with that Legacy EXR flag on. At least when Houdini 19.5 drops, it’ll be easier to do.