KSampler (Rolling)

The classic way to make a tileable image is to flip on circular padding so the model's convolutions wrap around the edges - the "Tiling" checkbox that's been around since A1111. It works, but it's a blunt instrument: every tile looks like a crop of the same repeating field. RollingKSampler is the smarter alternative from this pack. It's a drop-in replacement for ComfyUI's KSampler that rolls the latent around before every denoising step and rolls it back after, so the output is tileable at the sampling level rather than the convolution level. Different result, same seamless guarantee - and for self-tiling textures, usually a better one.

What it does

Subclassing the stock KSampler, it wraps the UNet's apply function: before each step it circularly shifts the latent (and any conditioning tensors the same size) by a random offset, runs the denoise, then shifts back. Because the noise field never lines up with the image boundaries, the model can't "cheat" by memorizing a seam - it has to actually generate features that continue across the wrap. That's the mechanism behind the pack's rolled_self tiles, and it's why this sampler pairs naturally with the boundary-inpainting nodes: sample your self-tiles through it and the edges come out far cleaner.

It also has double_output (default true), which takes the result and tiles it 2×2 in the latent - so you immediately see the repeating field in the preview. That's a preview convenience, not the final product: keep it on while iterating, turn it off for the real export.

Inputs and outputs

Identical to stock KSampler - model, seed, steps, cfg, sampler_name, scheduler, positive, negative, latent_image, denoise - plus double_output (BOOLEAN, default true). One output: LATENT.

Installing and the fine print

Standard pack install: git clone https://github.com/samsartor/content_aware_tiles into ComfyUI/custom_nodes (or ComfyUI Manager → "content_aware_tiles") and restart. No model downloads.

The cost to watch is double_output: tiling the latent 2×2 quadruples the area you're decoding, and that's a real VRAM spike on big tiles. If you're OOMing, turn it off and preview a single tile or use SubBatchVAE on the decode. Also note the rolling introduces a random offset per run (seeded off the sampler's seed), so you get run-to-run variation even at the same seed - expected, not a bug. For Wang/Dual sets the boundary nodes already guarantee edge matching, so rolling matters most for the self kind. This is a research pack with effectively no forum presence - the source is short and readable, and the included workflow shows it wired with SubBatchModel and SubBatchVAE for the full memory-friendly path.