TTP Smart Tile Semantic Rank

When your tile set has a small face tile overlapping a much bigger context tile, something has to decide which one wins on top - and "whichever was drawn last" is a bad answer once you've got a dozen tiles of wildly different sizes and importance. Semantic Rank is the node that makes that call based on what a tile actually is, not its position in a list.

What it's doing

It reads whatever labels, captions, or prompts are already sitting on your tile set - usually written earlier by QwenVL Prompt Set Builder or set manually - and classifies each tile into one of a handful of buckets: background, subject, face, eyes, hands, text, detail, or normal. Then it writes a bunch of metadata back onto the tile set: a semantic score, a scale weight, a recommended compositing layer, priority, occlusion priority, and composite mode. Downstream, Assemble and Stack Order read that metadata to decide draw order and blending - instead of you manually deciding "the eye tile needs to sit above the face tile which needs to sit above the background" for every single image.

This is the same instinct behind detail-preserving compositing elsewhere in the ecosystem - the rule that only-masked, native-resolution regions should blend cleanly over their surroundings rather than punch a visible hole in them. Semantic Rank is what lets Smart Tile apply that rule automatically, based on content, across an arbitrary number of tiles.

The settings that actually change behavior

rank_policy picks the whole scoring profile: portrait (the default - biased toward face/eyes/hands, the common case), balanced, product, or text. Get this wrong for your subject and the ranking will actively work against you - running a product shot through the portrait policy means it keeps hunting for face and eye labels that were never going to show up.

apply_composite_rank (on by default) is the switch that actually pushes the rankings into compositing behavior: with it on, face/eyes/text/detail tiles get promoted above background/context tiles and marked for soft-overlay blending rather than a hard cut. The four bias floats tune how aggressively that promotion happens: face_bias (1.5), detail_bias (1.2), and text_bias (1.4) push those categories up the stack; background_weight (0.25) dampens how much pull background tiles get in the other direction. small_tile_bias (0.35) exists because size and importance aren't the same thing - without it, a tiny eye tile can lose a compositing fight to a much larger tile purely because it's smaller, which is the opposite of what you want.

Leave the bias floats alone until you've actually seen a specific tile win or lose wrong in your output - they're fine-tuning knobs, not something to preemptively tweak.

Where it sits in the workflow

The README's own recommended chain runs Semantic Rank twice: once early, right after prompting, so priorities are set going into the sampler loop, and once again after Loop Collect as a final refresh before Assemble - useful if anything changed during processing, or if you added Stack Order afterward to manually override specific tiles.

Installing it

ComfyUI Manager: search "Comfyui_TTP_Toolset". Manual:

cd ComfyUI/custom_nodes
git clone https://github.com/TTPlanetPig/Comfyui_TTP_Toolset

then restart. It's pure metadata scoring on the tile set - no model weights, no extra dependencies, bundled with the rest of the pack.

Where people get tripped up

The pack's own troubleshooting notes call this out directly: if a face or eyes tile is getting hidden under a larger tile in your final image, run it through Semantic Rank, make sure apply_composite_rank is on, and pair it with small_tile_on_top=true and auto_composite_policy=safe_auto over on Assemble - the ranking alone doesn't help if Assemble isn't set up to honor it. If the ranking looks off for tiles that clearly aren't faces or products or text, double-check rank_policy actually matches your subject matter before touching any of the bias values.