CMK Image File Loader

The node description says it as plainly as it can: "No pixels are decoded by this node." That sounds like a missing feature. It's the feature.

What it does

You pick or upload an image, it shows you the image so you know which one you picked, and it returns a single STRING output called image_file - ComfyUI's reference to that file, not a tensor.

That's the entire contract. The image widget is a dropdown populated from your ComfyUI/input directory plus the pack's own packaged reference images (the CMK 2.5 release ships a set of them - face references, ControlNet references, detailer and inpaint references, a black frame - so the reference workflows run before you've loaded a single photo of your own). Upload is enabled on the widget, so dragging a file in adds it to the list. The node previews the selection through ComfyUI's standard image UI, which is how you get the thumbnail without a single pixel entering the graph.

Why you'd want a file reference instead of an image

Because two nodes can load the same file. The pack's design notes are explicit about the reason: identity modules should be able to consume the same source through one visible wire. In a CMK flow you might want the same face photo to be a FaceSwap source and an InstantID reference and a preview. Decoding it once into an IMAGE and fanning that out works but forces every consumer to accept the same dtype, resolution and batch shape, and it silently pins you to whatever resize the loader did.

A file reference is a pointer. Each consumer loads what it needs, at the size it needs, from the original. That's wasteful in the specific case and correct in the general one.

It also aligns with how ComfyUI thinks about files. The string here is a ComfyUI file reference - an annotated filepath - and other nodes resolve it against input/. If you've ever hunted for why a node can't find an image that's clearly on disk, the frequent answer is that the file is in output/ or temp/, not input/. This node only ever offers things it can actually resolve.

What you get

image_file - a string. It wires into CMK nodes that expect a reference: the pack's image load-and-resize node takes one, and the pack's own project/save paths use it for naming. If you're feeding a vanilla ComfyUI node, this output is not what it wants; a LoadImage tensor is.

Behaviour worth knowing

The node hashes the selected file in IS_CHANGED, so replacing or editing the image at that path re-triggers the graph. It also validates on queue: a missing or unreadable file produces an Invalid image file error naming the value, which is a much better outcome than a downstream failure.

That caching detail is also a small warning. An output node like this one imposes an execution order on the graph - the caching system works backward from it - so dropping it into a graph changes when things run, not just what they read. Usually harmless. Worth remembering when a workflow gets inexplicably slow after you add a preview.

Install

Manager: search CMK Flow, install the CMKFlow entry, restart. Manually, from your ComfyUI root:

git clone https://github.com/CMKFlow/cmk_nodes.git custom_nodes/cmk_nodes
python3 custom_nodes/cmk_nodes/scripts/install_cmk_requirements.py

A manual clone never runs pip itself, so that helper is part of the install, not an optional extra - it finds the ComfyUI Python environment in use (Desktop installs often have three) and finishes with CMK dependency check: OK.

This node is in the pack's Flow/Input category, so it's part of the guided pipeline and expects the pack's Node 2.0 / Vue-backed frontend to render as intended. If ComfyUI's Nodes 2.0 setting is off, CMK warns at startup and dynamic nodes fall back to the old canvas.

Weights aren't needed here, but the pack needs them elsewhere:

python3 custom_nodes/cmk_nodes/scripts/check_cmk_resources.py --models-root "/path/to/ComfyUI-Shared"

Gotchas

Wrong folder. Videos belong in input/video/; stills belong in input/. Drop a PNG into the wrong place and it isn't in this dropdown.

Expecting pixels. There's no second output, no tensor, no mask. If you need the actual image, this is one node too early - use a load-and-resize node and take its image_file output, which gives you the pixels and the reference.