OpenClip AOV Reader

A real Flame render doesn't arrive as one image. It arrives as beauty, depth, normals, a puzzle matte, and a Cryptomatte that is by far the fattest thing in the file and that you will probably never wire up. This node exists so you can ask for exactly one of those passes by name and pay for exactly one.

What it actually does

OpenClip AOV Reader doesn't open files itself. It takes an aov_handle from either OpenClip Reader or OpenClip EXR Sequence Reader, plus the name of a part, and decodes that one part across the handle's frame range.

The handle is a lazy locator - a small dict of the frame pattern plus resolved start and end frames. Loading the beauty through the reader costs nothing extra just because AOVs exist in the same file. That laziness is the entire design: a Cryptomatte is the expensive part, and the lookup path only ever touches the name you asked for. Two supported conventions, handled generically: true multi-part EXR where the AOV lives in its own subimage keyed by a part name (what Flame and most DCCs write), and Blender's single-part multilayer output, where channels named ViewLayer.Normal.X/Y/Z count as a part called ViewLayer.Normal and the prefix gets stripped on the way out.

The inputs and outputs that matter

There are only two inputs, and neither is a raw image:

• aov_handle - comes from a reader's aov_handle output. It is not an IMAGE and nothing but this node will accept it.
• part_name - typed by hand. Copy it from the reader's available_aovs text output (queue the reader alone, or wire that output to a Preview Text). ComfyUI can't populate one node's widget from another node's output, so this is copy-and-retype, case and all.

The outputs are image (IMAGE) and matte (MASK), and their rules are worth knowing before you debug a black preview:

• A single-channel part populates matte only. image is None - there's nothing multi-channel to hand over. Depth and most mattes land here.
• Two or more channels populate both. matte is the channel literally named R if there is one, else channel 0.
• A name that isn't found in any frame gives you None on both. No error, no zero-filled placeholder.

That last rule cuts both ways, and it's the reason this pack feels like a pipeline tool rather than a toy: it won't lie to you about absence, but it also won't shout. A depth pass on the image output is genuinely useful - depth-ControlNet and depth-to-image models take a regular IMAGE, and the replicated R,G,B of a depth part is exactly that.

One node per AOV. Three passes you care about means three instances fed off the same handle.

Install

Search "OpenClip" in ComfyUI Manager, or run comfy node install comfy-openclip, or do it by hand:

cd ComfyUI/custom_nodes
git clone https://github.com/allklier/ComfyUI_OpenClip.git
pip install -r requirements.txt

Restart, and the nodes appear under the OpenClip category. The dependencies are lxml, openimageio and opencolorio, and Manager installs all three from requirements.txt - including opencolorio, which you don't need for the AOV nodes but will get anyway. There are no model downloads at all, which is a nice change of pace around here.

Where people get burned

A typo in part_name is completely silent. Both outputs go None and the graph runs happily on nothing. If your depth-driven workflow looks dead, check the spelling against available_aovs before you check anything else. A blank part_name is the one case that errors properly.

Cryptomatte is not decoded. Its channels are just plain R,G,B, indistinguishable from a real AOV by name alone, and the pack doesn't support it. Don't plan a matte-free comp around this node.

An empty available_aovs isn't a bug - your clip is a beauty-only pass. The handle still works, there's just nothing in it to fetch.

Stale pixels are usually the cache working as intended. The node fingerprints the first frame's modification time and size, so re-rendering the EXR and requeuing gets you new frames; touching nothing gets you the cached result. That's the standard ComfyUI caching contract, and this pack deliberately participates in it rather than dirtying the graph every run.

One more thing worth saying plainly: googling "openclip" gets you the CLIP text encoder family - the SD 2.0 OpenCLIP swap that invalidated a whole embedding library - not Autodesk's clip format. Community discussion of this corner is close to nonexistent, because compositors argue in VFX channels and not on r/comfyui. That's not you failing to find the tutorial. For these nodes the README and the in-node available_aovs / available_versions displays are the documentation.