FL PRXPixel Text To Image

This is the node that actually generates with Photoroom's PRX Pixel, and the first thing to understand about it is what you won't see on the graph: there's no VAE, no empty-latent, no KSampler, no CLIP loader. Nothing. You feed it a text prompt, it hands back a finished IMAGE. For anyone who's spent an afternoon debugging a "black image because the VAE didn't load" ComfyUI session, that's the whole appeal in one sentence.

PRX Pixel is a 7B pixel-space diffusion model. Where every SD-line model since 1.5 denoises inside a compressed latent and then runs a VAE decode, this one diffuses on actual RGB pixels and skips the round-trip entirely. The pixel-space debate is a big deal in 2026 - HiDream-O1, Chroma Radiance, L2P and this model all went that way, motivated by the fact that latent encode/decode is lossy and the loss compounds across editing passes. This node just happens to make the architecture dead simple to run: what the model generates is what you get, no decoder in between. The tradeoff is speed - compute scales with pixel count, so PRX Pixel is not your volume-iteration workhorse. It's the model you reach for when you want clean, direct output and don't want to babysit a pipeline.

The inputs that actually matter

• prompt and negative_prompt - the text. Default prompt is "A product photo of a red cube on a white background", which tells you exactly where Photoroom's head is at (they're the background-removal people). The negative prompt is passed only if your installed Diffusers build supports it, which it will if you installed the wheel this pack pins.
• width / height - 256 to 4096, stepping by 64. Default 1024x1024, the model's native resolution. The pixel-space tax means 4096 isn't a feature, it's a dare. Be honest about your VRAM.
• steps and guidance_scale - the model-card baseline is 28 steps at guidance 5.0. It's a FlowMatch model, so don't bring your SDXL habits here; the defaults are sane, keep them until you have a reason.
• seed, batch_size (1–4).
• use_resolution_binning (on by default) - lets the pipeline snap your requested size to an internal supported aspect-ratio bin. Leave it on.
• use_patch_grid + patch_columns/patch_rows - an alternative way to set size. PRX Pixel works on fixed 16x16 patches internally, so patch_columns × 16 gives your width. Off by default, and mostly interesting if you're trying to match a specific internal token count.
• show_preview / preview_every - live denoising previews in the node. Because the model works in pixels, "latents" are already visible RGB frames, so the preview is genuinely watching the image form rather than squinting at noise. preview_every=1 emits one every step, which is nice but adds overhead - bump it to 4–5 for long batches.

The outputs, and what you do with them

The first output, images, is a standard IMAGE tensor - wire it straight into a PreviewImage or SaveImage. The other three are diagnostics for the patch grid: patch_count (internal grid size after binning), effective_patch_tokens (patch count × batch × CFG multiplier, i.e. how many tokens the model actually attended to), and patch_info, a readable string like requested=1024x1024; internal=1024x1024; patch_grid=64x64; patch_count=4096. Useful for figuring out why a generation is slow or hitting memory limits - the token math is the real cost model here.

Installing the pack

The model isn't natively supported in ComfyUI, so this pack is how you run it at all. Grab it from ComfyUI Manager by searching "ComfyUI-FL-PRXPixel", or:

cd ComfyUI/custom_nodes
git clone https://github.com/filliptm/ComfyUI-FL-PRXPixel.git
cd ComfyUI-FL-PRXPixel
python -m pip install -r requirements.txt

Then restart ComfyUI. Two heavy things happen on first run: the pack installs a development wheel of Diffusers (diffusers-0.39.0.dev0) because PRX Pixel's pipeline only exists on a Diffusers dev branch, and the first generation downloads roughly 17.5 GB of weights into your Hugging Face cache. CUDA with bf16 support is strongly recommended - that's the dtype the model was built around.

Where people get burned

• Expecting img2img, inpainting, ControlNet or LoRA. Not implemented, and the pack says so plainly. This is text-to-image only.
• Treating it like a latent model. No VAE loader, no KSampler - if a workflow for this model shows those nodes, it's not a real PRX Pixel workflow.
• Chasing 4096 resolution. It'll run on a big card, and it'll take a while. PRX Pixel's whole reputation is quality-per-pixel, not pixel count. The default 1024 is where it's happiest.