DaC Algorithm 988 v2
DaC v2 adds a TileCount mode — pick how many tiles, not just how much to scale
- image
- image
- dac_data
- info
The first DaC Algorithm node answers "how big can I go?" The v2 answers a different question: "I want exactly this many tiles." If you've ever built a tile pipeline and discovered the algorithm decided on 27 tiles when your batch loop or your workflow was built for 4, you know why that distinction is worth a node of its own.
DaC Algorithm 988 v2 is the same Divide and Conquer planning node as the original - it computes a tile grid, overlap, and an upscale target, then pre-upscales your image to the exact dimensions the grid needs - but it adds a second operating mode that flips the problem around.
Two modes, one node
The algorithm dropdown picks the mode:
Image Scale Factor- identical behavior to the original: give itmin_scale_factorand it solves for the grid. Use this when the output size is the requirement.TileCount- give itnum_tiles(default 4, up to 1024) and it auto-calculates the grid and the overlap so the tiles match your input's aspect ratio. Use this when the number of tiles is the hard constraint - because your VRAM budget, your batch size, or your patience says "four passes, not twenty."
That second mode is the reason to reach for the v2 over the original. Planning by tile count makes the pipeline's cost predictable before you commit: each tile is one diffusion pass, so num_tiles is literally how many expensive steps you're about to run.
Inputs worth knowing
tile_width/tile_height(default 1024) - tile size, your VRAM dial.algorithm- the mode switch above.min_scale_factor(default 3, range up to 64 - four times the original's ceiling, in case you're planning something ambitious) - the scale target for Image Scale Factor mode.min_overlap(default 3%) - minimum overlap between tiles; the same seam-vs-cost tradeoff as the original.tile_order-linearorspiral; sets the order tiles come out for your processing loop.scaling_method- interpolation for the pre-upscale (lanczos default).num_tiles- only relevant in TileCount mode.
Outputs
Identical contract to the original, which matters because it means the two nodes are drop-in swappable in an existing pipeline: image (the upscaled-to-grid image), dac_data (the geometry dict that Divide Image Select and Combine Tiles read), and info (a text summary - it's an output node, so it shows on the graph).
When to reach for it
If you process tiles on a fixed grid (say, a 2×2 batch on a 4x upscaler), TileCount mode is the difference between a predictable workflow and one that silently re-plans. The trade: in TileCount mode the algorithm has less freedom, so the effective upscale factor can drift from what you naively expect - read the info string the first time to see what it actually settled on.
Install
Part of ComfyUI-988: Manager (search "ComfyUI-988") or:
cd ComfyUI/custom_nodes
git clone https://github.com/kajan988/ComfyUI-988
cd ComfyUI-988
pip install -r requirements.txt
Then restart. No model downloads; the pack's requirements are just lmstudio, requests, Pillow and numpy.
Inputs (9)
| Name | Type | Default | Description |
|---|---|---|---|
| image | IMAGE | — | |
| tile_width | INT | 102464–8192 | — |
| tile_height | INT | 102464–8192 | — |
| algorithm | COMBO | Image Scale Factor | 2 options: Image Scale Factor, TileCount |
| min_scale_factor | FLOAT | 3.001–64 | — |
| min_overlap | COMBO | 3% | 13 options: 0%, 1%, 2%, 3%, 5%, 8%, +7 |
| tile_order | COMBO | spiral | 2 options: linear, spiral |
| scaling_method | COMBO | lanczos | 5 options: nearest-exact, bilinear, area, bicubic, lanczos |
| num_tiles | INT | 41–1024 | — |
Outputs (3)
| Name | Type | Description |
|---|---|---|
| image | IMAGE | Upscaled image at optimal tiling dimensions |
| dac_data | DAC_DATA | Serialized tile data for downstream nodes |
| info | STRING | Summary of all calculated parameters |