NovelAI 分块规划
Plan your NovelAI tile upscale before you spend a single Anlas
- source_image
- upscaled_image
- tile_plan
- planned_calls
- summary
Big images and cloud generation don't mix. NovelAI generates at limited sizes, so the pack's answer to "I want a huge, detailed image" is to slice the job into tiles and pay for each one. NAITilePlanner is the first stage of that machine, and its best feature is that it tells you exactly how many API calls you're about to make before you commit to any of them. On a pay-per-call pack, that number is the difference between a plan and a surprise bill.
What it is
It takes the two images that anchor a tile upscale - the original source_image and a locally upscaled upscaled_image (you've already run ESRGAN or similar on the original, because NovelAI's tile pass adds detail, not pixels) - and produces a tile_plan describing how to cut the big image into overlapping pieces.
The geometry inputs:
tile_width/tile_height- tile size in pixels. Default 0 means "use the source image's dimensions." That's the intended workflow: if your original is 1024 wide, tiles come out 1024 wide, which is right in NovelAI's sweet spot.overlap_x/overlap_y(default 128) - how much tiles overlap. Overlap is what keeps seams invisible; if two adjacent tiles don't agree on the same pixels, the merge shows it.blend_width(default 64) - how wide the cosine-fade band between tiles is. Keep it at or below the overlap.
Outputs:
tile_plan- the plan object, wired forward into the refine node.planned_calls(INT) - the count of tiles, i.e. the number of NovelAI API calls the refine pass will make. Read this before running anything.summary(STRING) - human-readable version of the same.
The one check that saves you money
The planner validates that your source_image and upscaled_image have matching aspect ratios within 2%. If they don't, it refuses to plan rather than producing a misaligned mosaic - that's the pack refusing to burn Anlas on garbage. Get the aspect ratios aligned (crop or letterbox the upscale) and it'll happily proceed.
A 3×3 grid is 9 calls. A 5×4 grid is 20. At 1–4 Anlas per generation this is not a free scaling law, which is exactly why planned_calls sits right there on the node. Plan first, multiply the count by your per-image cost, then decide if you want a smaller overlap (fewer, bigger tiles) instead.
Where it sits
The classic three-stage pipeline is planner → refine → merge:
source + upscaled → NAITilePlanner → NAIV45TileRefine → NAITileMerge → image
The pack also ships NAITiledRefineAllInOne, which runs all three (plus seam fix) in a single node. The planner matters when you want to see the plan, check the call count, and steer the geometry before committing. It's the observability node of the trio.
Install and setup
Part of ComfyUI-NovelAI-GENYTOOLS. Manager search, or:
cd ComfyUI/custom_nodes
git clone https://github.com/XTOGENY/ComfyUI-NovelAI-GENYTOOLS.git
pip install -r ComfyUI-NovelAI-GENYTOOLS/requirements.txt
Restart, set your NovelAI Persistent API Token under NovelAI 2.0: Persistent API Token. Planning itself is free - it's pure math, no API call.
Gotchas
tile_width/tile_heightof 0 is auto, not "tiny." New users set it to 0 expecting a default and then wonder why tiles are the size of their source. That's the feature.- The aspect-ratio check failing is the most common first-run error. Fix the images, not the settings.
blend_widthbigger thanoverlapgets clamped internally - you can't blend wider than the overlap you set.- This node spends nothing. The refine node downstream is where the Anlas go, so treat
planned_callsas your quote.
Inputs (7)
| Name | Type | Default | Description |
|---|---|---|---|
| source_image | IMAGE | — | |
| upscaled_image | IMAGE | — | |
| tile_width | INT | 00–4096 | — |
| tile_height | INT | 00–4096 | — |
| overlap_x | INT | 1280–1024 | — |
| overlap_y | INT | 1280–1024 | — |
| blend_width | INT | 640–512 | — |
Outputs (3)
| Name | Type | Description |
|---|---|---|
| tile_plan | NAI_TILE_PLAN | — |
| planned_calls | INT | — |
| summary | STRING | — |