OpenClip AOV Writer

This node has no side effects. It puts nothing on disk, shows nothing in a preview, and finishes instantly. If that reads like it's broken, that's the job: it's a chain builder that names one AOV and hands the list onward.

What it's for

Sending an element back to a compositor means sending passes, not just a beauty plate - depth for the defocus they'll rebuild, a matte for the grade, normals for whatever relight they bolt on. OpenClip Writer writes those alongside the beauty, but it needs them described first: each one named, and each one bound to the image or matte that carries it. That's what this node does, one AOV per instance.

How it works

Each instance holds one entry - a name, plus either an image or a matte - and outputs the accumulated AOV_WRITE_CHAIN. Chain several via the aov_chain input and the list grows in wiring order, so the last one in the line is the one you connect to the Writer. Name collisions raise here, pointing at the node that introduced the duplicate, and the Writer validates the whole chain again before it writes anything, in case the chain came from somewhere else.

The name isn't cosmetic: it becomes the EXR part name in Multichannel layout, or the <name>_AOV_<aov>.####.exr filename segment in Separate Files layout. Whoever picks this up in Nuke or Flame reads that string, so depth beats AOV1.

The matte handling is deliberately asymmetric and worth understanding. A matte is written as a single channel called R, so when it comes back through OpenClip AOV Reader it lands on that node's matte output again - the single-channel rule sends one channel to matte, so the round trip closes without anyone remembering a convention.

The inputs and outputs

• name - required, and it must be unique across the whole chain. Empty raises.
• image - optional IMAGE, written with however many channels it has.
• matte - optional MASK, written as one channel.
• aov_chain - the previous node in the chain, if there is one.

The one output is aov_chain. That's it - this node never touches a file.

Connect exactly one of image/matte, never both and never neither. The author treats that as an artist decision rather than something to guess at, and both cases raise with a message naming the AOV.

Layout is the Writer's call, not this node's

OpenClip Writer has an aov_layout choice and it changes what these names mean on disk. Multichannel appends each AOV as its own named subimage inside the same EXR as the beauty - one file per frame, everything together, which is what a Flame render with imported AOVs actually looks like. Separate Files writes a sibling file per AOV instead. Both are valid; pick whichever your downstream comp prefers rather than whichever looks tidier.

The hard constraint: AOVs require EXR. If the Writer's file_format is set to PNG, the run dies with AOV output requires file_format='EXR'. That's not arbitrary - there's nowhere to put a named float channel in an 8-bit PNG, and PNG output clamps where the EXR path deliberately doesn't.

Install

Manager, searching "OpenClip", or by hand:

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

Manager pulls lxml, openimageio and opencolorio from requirements.txt automatically; the manual route needs that pip line or the pack won't import. Restart ComfyUI afterwards and look under the OpenClip category.

Where people get burned

The chain goes to aov_chain, not to IMAGE. Both live on the same Writer node, they're both downstream inputs, and mixing them up is the single most common way to end up with an AOV-shaped picture saved as your beauty. The finished image goes into IMAGE; only the last AOV Writer output goes into aov_chain.

A shorter AOV batch than your beauty batch fails mid-write. AOV entries are indexed frame by frame against the beauty, so the two need to line up - an AOV that's missing frames indexes off the end. Match the frame counts before you queue, not after.

Round-tripping without the metadata pipe loses the plumbing. If the clip came in from Flame, the Writer's clip_path, clip_name, metadata, fps and colour_space defaults assume a fresh clip. Wire them through from the Reader and add _updated to the clip_name so you're not writing over the plate you read.

There's no troubleshooting thread to link you to, and that's not for lack of looking - OpenClip-the-format barely registers in the ComfyUI subreddits (most "openclip" hits are the text encoder). The node's own error messages are unusually good, so read them literally and they'll usually tell you which of these you hit.