PixArt Resolution Conditioning
PixArt Resolution Conditioning
- cond
- cond
This one's easy to skip by accident because nothing obviously breaks if you do - your generation still runs, you still get an image. What you might not notice is that PixArt was trained to receive its target resolution as part of the conditioning signal itself, not just as a latent shape, and this node is how you actually give it that. Think of it as PixArt's version of what SDXL does with its width/height/crop conditioning: extra information riding alongside the text embedding that tells the model what it's supposed to be producing.
It's a thin node - one input in, same conditioning object out, with resolution folded in - but it sits at an easy-to-miss spot in the graph.
Inputs. Three, all required. cond is the conditioning coming out of your text encoder - T5 Text Encode or PixArt T5 Text Encode, whichever you're using. width and height are plain integers, default 1024 each, range 0–8192. In practice you don't type these by hand: you wire them straight from PixArtResolutionSelect's outputs, so the number that reaches this node is guaranteed to match the actual resolution you're generating at rather than something you eyeballed.
Output. cond - the same conditioning, now carrying resolution info, ready to go into your KSampler's positive or negative slot exactly like conditioning normally would.
Where it goes in the graph. Right after text encoding, right before the sampler. The chain looks like: T5 loader → text encode → PixArtResolutionCond → KSampler, with the width/height inputs sourced from PixArtResolutionSelect rather than typed in twice. You'll want one of these on both your positive and negative conditioning branches, matching the same resolution on each.
Installing the pack. Via ComfyUI Manager, search "Extra Models for ComfyUI," or:
cd ComfyUI/custom_nodes
git clone https://github.com/city96/ComfyUI_ExtraModels
then pip install -r requirements.txt and restart.
Why it's worth the extra node. PixArt Sigma in particular built its reputation on unusually strong prompt adherence for its size - people ran head-to-head comparisons against SD3 and came away impressed specifically because the model followed instructions faithfully rather than just producing generically pretty images. That kind of fidelity depends on the model getting the full signal it expects, and resolution conditioning is part of that signal. Leaving this node out won't wreck your output the way a wrong VAE or an off-bucket resolution will, but it's a small, free correctness fix, and there's no real reason not to wire it in once you've got PixArtResolutionSelect in the graph anyway - the width/height values are already sitting right there.
One thing to double-check. Make sure the width/height feeding this node are the same values feeding your EmptyLatentImage. It's easy to have PixArtResolutionSelect driving the latent shape but forget to also route its outputs here, in which case this node quietly falls back to its 1024×1024 defaults regardless of what resolution you're actually sampling at - not catastrophic, but not what you wanted either.
Inputs (3)
| Name | Type | Default | Description |
|---|---|---|---|
| cond | CONDITIONING | — | |
| width | INT | 10240–8192 | — |
| height | INT | 10240–8192 | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| cond | CONDITIONING | — |