Sampler Tile Test Selector (Optional)

This is the pack's iterate-quickly lever. Every sampler-facing input - tile images, positive prompts, negative prompts, references, seeds - passes through this node, and it can hold them all back except one. Set processing_mode to One tile test, pick a tile number, and only that single aligned job goes to VAE encode and sampling. The other eighty-nine still get their prompts generated and audited; they just don't get rendered.

Why bother? Because upscaling at scale is expensive. The README's performance ordering puts "the one-tile test" second only to lowering the prompt detail level, and it's the honest way to try a setting: change something in the Prompt Director, test one tile, look at it, then commit to the full grid. Ninety tiles of a wrong experiment is a lot of wasted VRAM-time.

How it works

The node deliberately operates on every sampler-facing field together rather than just filtering the image list. That's a real design choice, documented in the source: selecting only the image path would let ComfyUI pair one tile with the wrong prompt, or execute it repeatedly for every remaining conditioning item. By slicing the whole tuple - images, positives, negatives, references, seeds - it guarantees the one tile that samples is a complete, correctly-paired job.

In All tiles (production) mode it's a pass-through: everything flows through unchanged, and the node costs you nothing.

Inputs and outputs

All five inputs are list-mode forceInput sockets: tile_images, positive_prompts, negative_prompts, tile_references, tile_seeds - the same five outputs come back out, also as lists, so the wiring upstream and downstream never changes shape. The two controls:

• processing_mode - All tiles (production) or One tile test.
• tile_number - the human tile number shown on the processing grid and the prompt inspector, 1 to 4096. Used only in test mode.

The tile numbers match the ones in SmartTileJobDirector and the SmartTileInspector, which is the whole debugging loop: see a bad tile in the final image, read its prompt, set this node to test that number, iterate.

Where it sits

It comes after the per-tile prompt generation and before the sampler, which is what makes the test mode free of the expensive parts of the pipeline. All upstream prompt generation and audit records still run, so the log stays honest; only the sampling is thinned out. Downstream, SmartTileFinalizer's fallback_method input exists specifically for this: during a one-tile test it fills the unrendered tiles from the enlarged baseline (bilinear by default) so you can see the whole picture, not just a hole in the grid. Leave that fallback alone - it has no effect on a full run.

Install

Same pack install as every node here:

cd ComfyUI/custom_nodes
git clone https://github.com/HallettVisual/ComfyUI-Smart-Upscaler

or search "ComfyUI-Smart-Upscaler" in ComfyUI Manager, then restart, plus ComfyUI-KJNodes and rgthree-comfy for the shipped workflow. No Python deps; the ~13 GB of models in docs/MODELS.md are the entry cost, and the Z-Image Turbo stack is what you're actually paying for when test mode lets a tile through.

Gotchas

• Test mode looks "half-rendered." That's the feature, not a bug - the finalizer is padding with the baseline. Switch back to All tiles for the real run.
• Wrong tile sampled? tile_number uses the same T-numbering as the inspector and the log; if you're looking at tile 37 in the preview, 37 is what you type.
• It's a downstream control, so cache-friendly. Sampler settings, denoise, steps, model swaps all sit below this node - changing them reuses the cached prompts and enlarged tiles, which is exactly why test mode is so cheap. If a test tile still takes forever, the cost is the model load, not the pipeline.