ComfyUI Wiretap Nodes

Flame Tools and Tech
1

Here’s a demo of a little something I’ve been working on (and bleeding for with regards to the writer). A full Wiretap implementation as a series of ComfyUI custom nodes. It allows for browsing local or remote framestores, ingesting full length or portions of inputs and a size limiter, full metadata mining, a flame centric OCIO implementation for color management, 32bit end to end and finally a writer that allows you to round trip back to a shared library. Currently a private repo but I can make it available if folks are interested…

2

@cnoellert
My favorite apex predator!
Keep dropping these epoch changing tools brother!
As the kids say, “Fire!”
Outstanding work.
Let’s move it all along.
Oh and yes send me an invite to the repo please!!!
Monster.
Teach everyone to fish.
:heart::heart::heart::fire::fire::fire:

3

Sent. Let me know what you think.

4

Hot damn, that’s amazing! Chapeau sir.

Out of curiosity, is it the wiretap api that’s the bottleneck? Feels like it reads/writes slower than I’d have imagined…

5

I’m loving the energy around workflows and tools with all types of serious development by the community well beyond just matchboxes and quality of life scripts.

I’ve been following the trends in coding across the tech world and we’re living through an epochal change. The best analogy I can compare that to is when we went from machine code to higher level programming languages. It’s on that order of magnitude.

By industry accounts it over-proportionally benefits senior devs/artists and the greenhorns. The mid-career folks are at risk of being left behind.

6

Cheers @kyleobley. Performance-wise, I think it’s largely Comfy loading and the plates being 6k exrs in this particular example—Comfy isn’t exactly the most performant system when it comes to these kind of things. That being said, my next order of business is going to be seeing what can be done about optimizations now that it actually works.

I’m also really into the idea of making some Flame style nodes we all wish we’re in there :shushing_face:

7

@cnoellert :exploding_head: Wow, This is amazing! Would love to test it out.

8

Amazing work, congratulations! :clap: I’d love to test it too, if possible.

9

@cnoellert From what I recall, you’re an unmanaged guy. I assume you’re not using the writing directly to Flame part yourself, are you?

Regardless, very cool that you figured it out. That’s a dark hole I never wanted to enter, haha.

Curious to hear about the custom nodes you’re cooking up. The flame ocio ones are already a huge step forward.

10

The writer without a wt path selected or inherited defaults to writing out exrs to the file system path entered in the node, so it fills both needs. I’ve got some work done on a series of shot naming nodes that I’m hoping to throw together into the same package at some point. The idea is a fairly modular approach to the writing stage that fills both managed and unmanaged workflows.

Regarding some of the batch nodes I’ve been thinking about getting together, it’s largely resize and crop, comp node, some form of a multilayer comp/simplified action etc… definitely be curious what other folks are missing.

All of this is a part of a larger project I’m working on in my spare time so I definitely have a bit of an uphill battle on my hands :joy:

11

This is great @cnoellert beyond great. Well done!
Make repo avail when you ready, we could fork and interate, if you like changes, you could merge changes as PR into your own main repo?

I have one on my own pipe for Nuke, and an WIP one for Flame using old PyBox, your way is just miles better.

12

@tpo @john-geehreng @wiltonmts @kyleobley and anyone else who wants acess just DM me your git user or an email and I’ll fire it off to you. Cheers folks

13

Ah cool! Love that you can have it both ways.

14

f’ing brilliant!! As soon as I have some time, I’d love to dig into it.

15

Flipped the repo public. It seems to be working fairly well on Linux and Mac so feel free to give it a go.

16

Should add that I’m simplifying the workflow a little, so it will be updated shortly.

17

This is super cool @cnoellert, I’ve finally gotten around to playing with it. Annoyingly I’m stugling to get the ocio bit to work.

I’ve installed opencolorio as you mentioned on git and I’ve checked that it’s working, etc but it’s still throwing errors when I try to use the node in comfy about PyOpenColorIO not available.

This environment is python 3.12 so perhaps that’s the issue. So far all my troubleshooting hasn’t been successful. This is on MacOS btw.

/Users/kyle/miniconda3/envs/comfyui/bin/pip show OpenColorIO

Name: opencolorio
Version: 2.5.1
Location: /Users/kyle/miniconda3/envs/comfyui/lib/python3.12/site-packages

/Users/kyle/miniconda3/envs/comfyui/bin/python -c “import PyOpenColorIO, inspect; print(inspect.getfile(PyOpenColorIO))”

/Users/kyle/miniconda3/envs/comfyui/lib/python3.12/site-packages/PyOpenColorIO/__init__.py

Weirdly this throws and error though and part of me feels like it’s connected…maybe?

/Users/kyle/miniconda3/envs/comfyui/bin/pip show PyOpenColorIO

WARNING: Package(s) not found: PyOpenColorIO

18

Hey Kyle, so it looks like the package is installed correctly and the issue is that macos isn’t finding the ocio dylibs at runtime when comfy launches. The easiest fix is probably to bake it into your conda env’s activation so it’s always set:

conda activate comfyui
mkdir -p $CONDA_PREFIX/etc/conda/activate.d
echo 'export DYLD_LIBRARY_PATH=$CONDA_PREFIX/lib:$DYLD_LIBRARY_PATH' > $CONDA_PREFIX/etc/conda/activate.d/ocio_dyld.sh

You could probably just set it with an env variable but macos can get squirrelly with that shit sometimes.

Then deactivate and reactivate the env, relaunch comfy and it should find it and it should works regardless of your shell and should survived Apple SIP restriction bullshit that can strip environment variables set by un-sanctioned methods.

If it’s still not working after that, let me know. There’s some other diagnosing we can do.

Sorry it’s fighting you. I only had a couple boxes to test on and this never caused me any grief… wiretap api detection took the most time to sort out.

19

I hate Macs sometimes. Right, so I tried your solve and it’s still not working. I then asked ChatGPT and it had me install opencolorio via brew.

brew install opencolorio

But yeah, still no dice. Within the environment python -c "import PyOpenColorIO as ocio; print(ocio.GetVersion())" returns a version 2.5.1 but python -c "import OpenColorIO as ocio; print(ocio.GetVersion())" fails.

I then tried to change the code in ocio_transform.py to try to load PyOpenColorIO as opposed to OpenColorIO but that still didn’t do the trick.

At this point I feel like I’m going around in circles. Out of curiosity, did you get this working on a Mac or only Linux?

EDIT: After having some lunch I decided to poke around a bit more. I wrote the following and ran it within my environment and it returned PyOpenColorIO: 2.5.1 so, at least on my machine, it’s wanting PyOpenColorIO.

try:
    import PyOpenColorIO as ocio
    print (f"PyOpenColorIO: {ocio.__version__}")
except ImportError:
    try:
        import OpenColorIO as ocio
        print (f"OpenColorIO: {ocio.__version__}")
    except ImportError:
        print ("Neither could be loaded.")

…and I had a look at the console output and the secret was buried in the initialization phase…

[Wiretap] WARNING: PyOpenColorIO not available: Python version mismatch: module was compiled for Python 3.11, but the interpreter version is incompatible: 3.12.12 | packaged by Anaconda, Inc. | (main, Oct 21 2025, 20:07:49) [Clang 20.1.8 ].. OCIO Transform node will pass through unchanged. PyOpenColorIO not available: Python version mismatch: module was compiled for Python 3.11, but the interpreter version is incompatible: 3.12.12 | packaged by Anaconda, Inc. | (main, Oct 21 2025, 20:07:49) [Clang 20.1.8 ].. OCIO Transform node will pass through unchanged.

I recreated the environment with 3.11 and now everything is working just fine. I think I saw you mention something about 3.11 but I rolled the dice with 3.12. Swing and a miss, haha. So yeah, 3.11 is needed for ocio to work, at least for now, on MacOS. Oh, and I did change your code to look for PyOpenColorIO as opposed to OpenColorIO.

For others who run across this, I did install opencolorio via brew and added this to my .zshrc file. Unsure if that’s needed or not now that the Python version is correct but I want to drop it here just in case.

export DYLD_FALLBACK_LIBRARY_PATH=/opt/homebrew/lib

20

I need to bold my note in the install about ocio and python version mismatches and maybe move it up to the top :joy: . I just assumed you were on 3.11 and it wasn’t picking it up.

Regardless I’m glad you got it working —let me see what I can do on my side to sanitize this process a little. Maybe I’ll just strip out the ocio stuff into a different set of nodes—I don’t want people going through this degree of crazy just for something that’s nice to have. The nodes all handle this gracefully as it stands and all the wiretap ops still function when there’s a mismatch but it still feels a bit messy.

To answer your question though I did test it on both Linux and Mac—they were both 3.11 though since I try to keep things in lock step as much as possible.