Image Crop to Tiles by Pixels

ImageCropTiles picks your tile size and sticks to it. Image Crop to Tiles by Pixels picks a pixel budget and lets the tile size be whatever fits under it. Same pack, same outputs, same pipeline descriptor - the only difference is the input that controls tiling, and it's a genuinely better mental model when you're tuning for VRAM.

The insight: what actually limits you in tiled sampling isn't the tile edge, it's how many pixels each tile has - 1024×1024 costs the same as 2048×512, but the first has a fixed-size knob and the second sneaks up on you. So this node takes max_pixels_per_tile in millions: 1.0M is a 1024×1024 tile's worth (1048576 pixels), 1.5M is the default. It then sizes tiles to stay under that budget while respecting the same adaptable-aspect-ratio and pixel-alignment logic as its sibling. Feed it a 2.0 budget on a 3060 and you have a good idea what'll fit; feed the fixed-size node 1536 and you're guessing.

The inputs that matter

• max_pixels_per_tile (default 1.5, 1–8) - the budget in millions of pixels. 1.0 ≈ 1024², 4.0 ≈ 2048². This is the knob you turn for VRAM.
• overlap (default 128) - shared edge pixels between tiles.
• overlap_feather_rate (default 2) - feather width = overlap × rate.
• adaptable_tile_size / adaptable_max_deviation_ratio / adaptable_max_aspect_ratio - the shape guards; leave on unless tiles come out shaped weirdly.
• pixel_alignment (default 8) - match your model's VAE grid (8 SDXL, 16 FLUX.2, 32 Qwen Image).

Outputs are identical to ImageCropTiles: tiled_images, mira_itu_pipeline (the descriptor the merge nodes consume), mira_itu_pipeline_info (readable text), and cropped_full_image (the center-cropped source, for color-correction reference).

How it works

Under the hood it reuses the same tile-grid machinery as ImageCropTiles, including the center-crop-to-alignment preprocessing and the per-axis tile-size search. The only meaningful difference is that the tile-size search target comes from your megapixel budget instead of a fixed edge - the node figures out width×height combos that stay under the budget and fit the aspect-ratio constraint, then cuts the grid. Everything downstream in the Mira ITU loop (VAE encode, tiled KSampler, merge) treats the output the same way.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/mirabarukaso/ComfyUI_MiraSubPack

or search "MiraSubPack" in ComfyUI Manager and restart. No extra dependencies.

Which one should you use?

If you're on a VRAM-constrained card or you work across many different models, the pixel-budget version is the better default - one number encodes your real constraint. If you know you always want 1024 tiles because that's what your model was trained at and you don't want to think about it, the fixed-size node is simpler. Same gotcha as the sibling either way: the image gets center-cropped to the alignment grid (watch the console for the crop amount), overlap must be smaller than the smallest tile, and the tiles come out as one opaque batch you should let the merge node reassemble.