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.

Add the flag --exrmode 0 to the end of the husk command in the USD Render ROP's Render Command

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:

After diving inside the Karma HDA, add the flag --exrmode 0 to the end of the husk command in the rop_usdrender's Render Command

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). 

Fusion's Loader can only load one Part at a time. This image demonstrates that the Parts and Channels are different things.
Fusion’s Cryptomatte fuse cannot read this file with data stored in different parts.

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.

Web admin for the Christian Gamers Guild and co-host of the Geek @ Arms podcast. Bryan primarily runs character-driven narrativist RPGs such as Primetime Adventures and Tales From the Loop.


  1. “Fusion’s Cryptomatte fuse cannot read this file with data stored in different parts.”
    So, in case the cryptomatte data is split into several parts, the Fuse will not read it at all or read it just partially for each part?
    I wonder if this is indeed a Loader’s part of a problem. Wouldn’t it be possible to allow Cryptomatte fuse accept multiple inputs, then split the Cryptomatte data with SplitEXR Ultra script to multiple Loaders and feed these parts to the Cryptomatte fuse so it could read the entire data? Or maybe this is a matter of creating a dedicated Cryptomatte merge tool that will verify and pipe the entire data to the fuse…

    1. Hypothetically, I suppose you could split-and-merge. It doesn’t seem like a terribly elegant solution, though. My thinking is that the best solution is probably to make the Cryptomatte fuse itself into a Loader. That way it could just pull all the channels it needs on its own. I don’t know if Kristof and Cedric have had the time to examine possible solutions or not. But maybe the in-development ReadEXRUltra fuse could have some utility there.

  2. i was sorry to hear that you had left Fusion for other shores, but i am sure you had some very good reasons. your understanding of Fusion seemed to be one of the deepest of anyone who wrote about it. have you posted a technical explanation somewhere of why you moved away from Fusion?
    once again, thanks for posting your book online. it was a shame it never reached publication, but at least we can still read it online.

    1. Fusion is still my compositor of choice; I’m not abandoning it entirely. I just don’t have as much reason to use it now that I’m no longer in production.

    1. Would be nice if they contributed that back to the free and open source Cryptomatte project. There’s no obligation to do so, of course, but I have opinions…

Leave a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.