✨ MuAPI Image Enhance

"Image Enhance" is doing a lot of work in that name. Look at the model dropdown and you'll find a Topaz upscaler sitting next to a background remover, a face swapper, an object eraser, a colouriser, a Ghibli-style filter and something called ai-product-shot. These are not enhancements of each other; they're fourteen unrelated jobs that happen to share an input shape, which is one image and a promptless request.

That's not a flaw. It's the honest shape of an API aggregator: the useful question isn't "what does this node do" but "which of these is worth paying for when a local node does it free."

Which ones are worth it

seedvr2-image-upscale is the interesting one. SeedVR2 is the local upscaler the community has treated as the top rung for about a year - the KB's upscaling.md records the reaction to it as "when an upscaler is so good it feels illegal" - and here's the same model, hosted, with no 3GB download and no VRAM ceiling. If you have the hardware, running it locally is free forever and you should. If you don't, or you need exactly one 4× pass on a client photo, this is the cleanest thing in the node. topaz-image-upscale is the commercial closed alternative, ai-image-upscale the cheapest of the three.

ai-background-remover is the "no thanks" case. Local is solved here - rembg and BiRefNet in a custom node do this offline and free, and the KB's background-removal.md covers the whole ladder. Paying per image to remove a background is a waste of your balance unless you're doing one-offs on a machine that can't run anything.

ai-object-eraser and ai-image-extension (outpainting) are genuinely handy, because inpainting and outpainting well requires a model you probably don't have loaded.

ai-ghibli-style, ai-color-photo, ai-skin-enhancer are transforms, not enhancements. Fine, cheap, occasionally exactly what you want.

The one input that bites everyone

Required: model and image. Optional: api_key, custom_endpoint, extra_params_json, and swap_image.

That last socket is the trap. What the second image means depends on which model you picked - the node picks a JSON key by substring-matching the endpoint name:

• swap_url on anything with face-swap - the face you're pasting in.
• mask_image_url on object-eraser - so a socket named swap_image is where your mask goes.
• watermark_image_url on watermark endpoints.
• face_image_url otherwise.

So the same wire carries three different kinds of image depending on a dropdown two nodes up. Read the endpoint name before connecting it - and only connect it when the endpoint actually wants a second image.

extra_params_json is merged into the request body and is where per-endpoint options live; the answer for anything the dropdown doesn't expose.

Outputs

image is a real IMAGE tensor, which is the whole appeal: the enhanced result re-enters your local graph for masking, compositing or a second pass. image_url is the CDN link, and request_id the handle if you want to extend something downstream.

Same soft-failure caveat as the rest of the pack: a failed download logs [MuAPI] image download failed and hands back a black 64×64 tensor instead of raising.

Install

Manager → Install via Git URL → https://github.com/SamurAIGPT/muapi-comfyui → restart. Or:

cd ComfyUI/custom_nodes
git clone https://github.com/SamurAIGPT/muapi-comfyui
pip install -r muapi-comfyui/requirements.txt

Requirements are requests, Pillow, numpy, torch, opencv-python - no model files, since there are no models here to have.

The call I'd make

For a batch job, spend the disk on local SeedVR2 and local rembg and never think about this node. For a one-off - a single portrait for a client, a photo you want upscaled on a laptop with integrated graphics - the cloud pass is cheaper than your time, and the fact that it lands back in your graph as a normal IMAGE means it composes with everything local you already built. Just read the endpoint name twice before you wire the second image.