RM Load Image (tracked)

Stock ComfyUI's Load Image is amnesiac. It hands you pixels and drops all memory of where they came from. That's fine for a single generation, but the moment you're iterating - take last week's output, feed it through a new pass, compare - you're manually remembering which file begat which. This node is the fix: it loads an image and, alongside the pixels, tells you the image's place in the pack's lineage system so the chain can keep growing across runs.

It's one half of a two-node story. Its sibling RMSaveLineage (and RMSaveImageWithMetadata) writes a small set of rm_* metadata chunks into every PNG it saves. Wire this node's saved_path output into a save node's parent_path input, and the next image you save records this one as its parent - even if that original was generated weeks ago. You get a real genealogy instead of a folder full of orphan files.

What you set

Just one input:

• path - either a reference relative to the tracked images folder, like 47/47_20260807_020924.png, or an absolute path. That's it. No dropdown of recent files, no browse button; you paste a path.

Three outputs, and they're the interesting part:

• image (IMAGE) - the loaded pixels, RGB, normalized to 0–1 like every other image tensor.
• mask (MASK) - built from the PNG's alpha channel if it has one (1 minus alpha, so opaque pixels are 1). No alpha channel? You get a harmless empty 64×64 mask instead of a crash.
• saved_path (STRING) - the image's <folder>/<filename> lineage reference, ready to feed a save node's parent_path. This is the reason the node exists.

The honest caveat

The lineage reference only resolves for images inside one folder: C:\Users\rober\Playground\Images, hardcoded in the source. That's the author's own machine layout - this pack is a personal automation suite that got published, and it shows. Load an image from outside that folder and the node works fine, but saved_path comes back empty and the pack says so on the console: it degrades to "no ancestors" rather than a broken link in the lineage panel, which is the right call. If you're not on a machine with that exact Playground structure, this node's superpower just won't engage - you get a solid Load Image, minus the memory.

How it works

The mechanics are thoughtful for a utility node. It reads the file with PIL and applies EXIF transposition, so phone/editor-rotated images come in the right way up. IS_CHANGED is keyed to the file's modification time, not the path string - so if the file on disk changes, the node reruns, instead of ComfyUI caching the old result forever because "the input didn't change." That's the classic forever-cache trap from the plumbing layer, sidestepped. And the path resolver handles both the relative-to-Playground form and absolute paths, stripping quotes if you paste a Windows "copy as path" string.

Installing it

Standard pack install:

cd ComfyUI/custom_nodes
git clone https://github.com/Moser9815/ComfyUI-RMAutomation

Restart ComfyUI. Or use ComfyUI Manager and search RMAutomation. No model files, and the loader needs nothing beyond PIL - the heavy dependencies in the pack's requirements (opencv-python, ultralytics) belong to other nodes.

Should you use it?

If you've built the Playground-folder workflow this pack assumes - save runs with lineage, iterate on old outputs - then yes, this is the missing link, and it's the only node that closes the loop across separate runs. If you just want to load an image and don't care about provenance, the stock Load Image is simpler and does the same pixel job. But honestly, the "where did this come from" habit is worth building. The metadata is already in your files either way; this node is how you read it back.