Protoface P-Image · Upscale Image

A different way to think about upscaling

Local upscaling lore is all about factor and model: 4x-UltraSharp, ESRGAN variants, SUPIR when you want the model to invent pores and eyelashes, tiled diffusion when you need 8K on 6GB. This node ignores most of that. It has no prompt, no denoise strength, no scale factor. It has image and target - target output size in megapixels, 1 to 128, defaulting to 4.

That's a much better mental model than "2x", honestly. 2x on a 512px image is a postage stamp; 2x on a 4K frame is enormous. Megapixels is the thing you actually care about, and it's the thing print and web specs are stated in. A 1024×1024 output is about 1MP; ask for 4 and you get roughly 2048×2048.

The tradeoff is the one every non-generative upscale has: it can make pixels bigger, it can't make detail that wasn't captured. If your source is soft, out-of-focus, or JPEG-mangled, no upscaler - local or hosted - fixes that. That's the SUPIR/SeedVR2 territory the KB's upscaling chapter covers, where the model is generating plausible detail and will happily rewrite a face. This node is the other job: more pixels, cheaply, without redrawing anything.

Where it earns a slot in a paid workflow: you generated a 1MP still through an API node, and you want a 4MP delivery without a local upscale pass, a tile loop, or a 20GB model download. One extra call, done.

Inputs and outputs

image takes one asset - a public URL, data URI, or asset id, or wire it from Load Image / a previous Protoface image output. Single-value socket: a batch gets refused with "expects one asset; split the image/audio batch first."

output_format defaults to png, which is what you want for an upscale; jpeg here is throwing away the thing you just paid to enlarge.

target is the megapixel count, min 1, max 128. The default of 4 is a sane delivery size. Going to 128MP is possible and almost certainly not what you meant - check your math before queueing, because you're paying for it.

generation_id is the paid-job identity (fixed = reuse/resume, incremented = new generation), and request_scope is frontend-assigned with a stable hand-supplied value required in headless workflows. There's no seed on this node, which makes sense - an upscale isn't a sampling process you'd want to re-roll.

image (IMAGE, list), mask (MASK, list), files (PROTOFACE_FILE originals for Protoface Save File), and run id, which is what you hand to Protoface Resume Run if a job needs recovering.

Install

cd ComfyUI/custom_nodes
git clone --branch v0.1.0 --depth 1 https://github.com/protoface-ai/protoface-comfyui.git protoface
python -m pip install -r protoface/requirements.txt

ComfyUI 0.41.0+, Python 3.10+, deps httpx, jsonschema, Pillow, av>=14. Manager: search Protoface, install protoface-nodes, restart, reload the tab. Then Protoface in the lower-right corner → API key. Memory-only, so it's gone after a server restart; headless installs should set PROTOFACE_API_KEY_FILE.

Note the pack supports chaining without re-uploading: wire the image output of another Protoface node into this image socket and use Protoface Reuse Result Asset where you need an asset reference - you're not paying twice for the transfer.

Where people get bitten

Expecting detail. If your 512px source is mush, a 4MP version of it is bigger mush. Run it on something already sharp, or accept that this is a resolution step and not a restoration step.

Ignoring the megapixel framing and reaching for something like 20 "because 4x sounds better" - 20MP is a big file and a bigger bill for no visual gain over 4–6MP on most outputs.

And the durability rules: timeouts leave a recoverable job (same generation_id, requeue or resume), cancels are best-effort with no refund promise, and ~/.cache/protoface-comfyui holds the journal that makes requeueing cheap. Clearing it mid-job is how you end up billed twice for one image.