ComfyUI Node Runs on cloud

Image Load

Load an image from any path or URL, not just ComfyUI's input folder

By WASasquatch·Created 3 years ago·Updated a day ago· 1,839
Image Load
    • image
    • mask
    • filename_text
    • profile
    image
    RGBAfalse
    filename_text_extensiontrue
    colour_spacesRGB
    icc_mode

    ComfyUI's native Load Image node is scoped to the input/ folder by design - good for a UI-driven workflow where you upload a file, awkward the moment you're scripting things or your images live somewhere else entirely. Image Load drops that restriction. The README states it plainly: "Load a image from any path on the system, or a url starting with http." Absolute filesystem path, or a straight HTTP(S) URL - either one works.

    Why that matters

    Anywhere you're building a workflow that pulls from a fixed location outside ComfyUI's own folder structure - a shared model/reference-image drive, a dataset directory, an image hosted somewhere online you want pulled in fresh each run - Image Load gets you there without first copying the file into input/. It's the node people reach for when they're scripting or automating rather than clicking through the UI, precisely because it removes the "has to already be in the right folder" requirement.

    How it works

    Give it a path or a URL, and it fetches the image and outputs it as a standard IMAGE - same downstream type as the native loader, so everything after it in your graph doesn't need to know or care that the source was different. For a URL, that means an HTTP request happens at load time, not a cached local copy - each run re-fetches unless you're doing your own caching upstream of it.

    What it takes and gives back

    A path or URL as text input, and an IMAGE output - plug it in anywhere you'd plug in the native Load Image node's output. That's the whole interface: it's a drop-in replacement for the standard loader with a broader idea of where "the image" is allowed to live.

    How to install it

    ComfyUI Manager: search "WAS Node Suite," install, restart. Manual:

    cd ComfyUI/custom_nodes
    git clone https://github.com/WASasquatch/was-node-suite-comfyui
    

    then, from inside that folder, install requirements - path/to/ComfyUI/python_embeded/python.exe -s -m pip install -r requirements.txt on portable, pip install -r requirements.txt on system Python. Restart ComfyUI; it's under WAS Suite.

    Common issues & troubleshooting

    If it can't find a local file, double-check you're giving it a full path the ComfyUI process actually has permission to read - this bypasses the input-folder sandbox, but that also means you're now responsible for making sure the path is correct and accessible from wherever ComfyUI is running, not something ComfyUI resolves for you the way input/ files are.

    For URLs, the most common snag is a link that doesn't actually point straight at an image file - a webpage URL instead of a direct image link, or a host that blocks automated requests without a browser-like header, will fail even though the same URL opens fine in a browser. Confirm the URL resolves directly to image bytes before assuming the node is broken.

    Beyond that, this is a straightforward IO node with no heavy dependency of its own, so it's unlikely to break in isolation. The pack-wide risk still applies: WAS Node Suite has had no active development since December 2023, and the recurring complaint since then is the whole suite failing to import after a ComfyUI update - a shared-dependency version clash, not this node specifically. If it happens, reinstall requirements with your embedded Python interpreter, not a system one.

    CategoryWAS Suite/IO

    Inputs (5)

    NameTypeDefaultDescription
    imageCOMBOWhich picture to read. A file in ComfyUI's input folder is listed by name; anything else carries the folder it sits in, as `render.png [output]` or `scratch.png [temp]`. A folder added under paths.allow_read appears under its own name. The button below uploads one into input and selects it.
    RGBABOOLEANfalse`off` discards any transparency and hands on a plain colour image, which is what samplers and most nodes expect; `on` keeps the transparency channel in the image itself. The mask output is produced either way.
    filename_text_extensionoptBOOLEANtrueWhether the filename_text output keeps the extension. On = 'cat.png', off = 'cat'. Handy when the name is being reused as a caption or as a save prefix.
    colour_spaceoptCOMBOsRGBWhich colour space the picture comes out in. "the file's own" leaves a tagged file exactly as it was written, for post work that stays there. 'sRGB' is what a sampler, a filter and a LUT expect. The rest, such as 'Adobe RGB (1998)' and 'Display P3', are for a photograph that goes back out in its own space.
    icc_modeoptCOMBOWhat to do with the space above. 'convert' changes the numbers so the colour stays put, which is what a photograph wants. 'assign' leaves the numbers alone and says they were in that space all along, which is how an untagged file that is really Display P3 is put right. Ignored for "the file's own".

    Outputs (4)

    NameTypeDescription
    imageIMAGEThe loaded image, as a batch of one.
    maskMASKThe image's transparency as a mask, with the transparent parts white and the opaque parts black. An image with no transparency gives an empty 64x64 mask.
    filename_textSTRINGThe file's own name, without the folders leading to it, for reuse as a caption or a save prefix.
    profileWAS_COLOUR_PROFILEThe colour profile the file was tagged with, such as Adobe RGB (1998). Wire it into Image Save to write the result back in that space rather than in sRGB. Empty for a file carrying no profile, which is most of them.