OpenClip EXR Sequence Reader

Blender doesn't write OpenClips. Neither does Nuke by default. They write a folder full of shot_0100.exr files with no manifest anywhere, which makes the rest of this pack look inapplicable - until you notice there's a second reader built exactly for that, and it hands back the same things.

What it does

OpenClip EXR Sequence Reader reads a plain name.####.exr sequence off disk and returns it as an IMAGE batch, in the same output positions as OpenClip Reader. Same IMAGE first, same MASK second, same aov_handle and metadata in the same slots. That's deliberate: the two readers can sit behind a switch node in one workflow, so a job can arrive as a Flame clip one day and a Blender render the next without rewiring anything downstream.

It also handles Blender's single-part "OpenEXR MultiLayer" layout, which is the one that trips people up. Blender writes one part whose channels are named <view layer>.<pass>.<channel> - ViewLayer.Combined.R, CamelMatte.Combined.A - with no plain R/G/B at all. Leave the layer widget blank and you read plain R/G/B/A channels, which don't exist in that file. Set it to the beauty prefix, e.g. ViewLayer.Combined, and you get the right picture. Every other layer shows up in available_aovs under its prefix (ViewLayer.Normal) and gets decoded one at a time by OpenClip AOV Reader.

The inputs and outputs

sequence_path needs exactly one frame token, #### or %04d - shot.####.exr or shot.%04d.exr. Two tokens, or none, and it raises with the path it choked on. Relative paths resolve against ComfyUI's input directory, same as an image loader.

start_frame and end_frame default to -1, which means "first and last frame actually found on disk" - the node scans the directory rather than trusting a number. frame_cap is the one people miss: it's a count, applied on top of whatever start resolved, so start=-1, end=-1, frame_cap=90 reads the first 90 frames whether the sequence starts at 0, 1 or 1001. Flame loves starting at 1001, and that's exactly why the cap exists as a separate field instead of asking you to do arithmetic per clip.

fps is a widget (default 24, which is a default, not your default) and colour_space is a free-text string. Both are widgets because Blender writes no frame rate into the EXR header, and a blank colour_space falls back to whatever tag the header does carry.

Thirteen outputs, most of which you'll wire or ignore. The ones that earn their keep: IMAGE and MASK into the graph, aov_handle into AOV Reader, available_aovs into a Preview Text so you can see what parts exist, frame_count / width / height for anything doing maths, and clip_path (the sequence's folder) plus clip_name (the filename stem, frame token stripped). Those last two matter most: wire them into OpenClip Writer and it writes folder/stem.clip, so you've just minted an OpenClip from a Blender render - the whole point of the pack. colour_space, fps and metadata pipe through to the writer too.

Install

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

Or find "OpenClip" in ComfyUI Manager. Manager pulls lxml, openimageio and opencolorio for you; manual installs need the pip line or the pack won't import at all. The EXR path is real openimageio - this isn't a PIL trick that happens to open files. Restart, then look under the OpenClip category.

Where people get burned

Nothing matches the pattern. You get no frames on disk match <pattern>, which is what it says - usually a wrong folder, a padding mismatch (#### vs files padded to six digits), or a path that resolved against the input directory when you meant an absolute one.

The frame token rule. Exactly one # run or one %0Nd. Blender will happily hand you something this node won't take verbatim, so type the pattern out rather than pasting a full path.

A silent black or garbage beauty on a multilayer EXR. Blank layer reads R/G/B/A; Blender's multilayer file has no such channels. Set layer to the prefix in available_aovs.

fps default 24 with a 25 or 30 fps sequence. Nothing errors. The writer will declare 24 in the clip metadata, Flame imports it, and the clip plays at the wrong speed. Set it once per sequence and check it in a round trip.

Whole-shot loads. The batch is a full EXR decode held in memory; the hard ceiling is 100,000 frames, checked before anything loads, but in practice your ceiling is VRAM. Use frame_cap for a look-dev pass instead of pulling the whole shot.

One last thing about support: this corner of the format world is barely discussed on the ComfyUI subreddits, and "openclip" search results are almost all the text encoder. Read the error literally - it usually names the exact thing that's wrong, and there's no thread out there to do it for you.