PSD Background Detect

"Which layers in this PSD are the background?" sounds easy until you open a file where the background is a gradient, a texture, a soft shadow, and a color layer stacked together. This node makes its best guess by scoring every layer from the splitter's manifest, then hands you a recommended index range plus a plain-English explanation of why it chose what it chose. You're not meant to trust it blindly - you're meant to check its reasoning and take the range.

How the scoring works

It reads _manifest.json from a PSDLayerSplitter folder and walks the layers bottom-up, greedily including contiguous layers whose score clears score_threshold. The score rewards the things actual backgrounds tend to have:

• Name regex - a strong hit on patterns like bg, background, backdrop, sky, wall, floor. The default name_pattern covers English plus common localizations (Spanish fondo, German hintergrund, French arrière-plan/fond, Chinese 背景, Korean 배경), so it's friendlier to non-English files than most.
• Full-canvas coverage - a layer that covers the whole canvas is more background-y than a sticker.
• Opacity + normal blend mode - solid, normal-mode layers behave like backgrounds.
• Bottom-bias - backgrounds usually sit low in the stack.
• Penalties - text and adjustment layers count against the range.

Two safety valves keep it from guessing wildly: min_confidence (default 0.5) - below this, the node returns -1, -1 rather than a confident-but-wrong range - and max_range_size (default 6), a cap on how many contiguous layers it'll swallow.

The outputs

bg_start and bg_end are the range to wire into the compositor's replacement_index / replacement_end_index, and confidence is a 0..1 number you can use to decide whether to trust the answer. The sleeper hit is rationale: a per-layer scoring breakdown, meant to be piped into a Show Text / easy showAnything node so you can see which layers were picked and why before you burn a render. The README treats this as a required habit, not a nicety - a detector that explains itself is a detector you can sanity-check.

The workflow it's built for

Split → detect → check → composite:

1. Run the splitter, point this at its folder.
2. Read rationale, confirm the range makes sense.
3. Wire bg_start/bg_end into the compositor's replace_range mode with replacement_image attached.

And the detector is a convenience, not a dependency: if it misfires, you leave the compositor in replace_range and just type the indices yourself.

Installing it

Part of TrentNodes; one install:

cd ComfyUI/custom_nodes
git clone https://github.com/TrentHunter82/TrentNodes.git
cd TrentNodes
pip install -r requirements.txt

ComfyUI Manager ("Trent Nodes") works too, with the standing caveat about the author's day-one repo rename leaving a duplicate registry entry that occasionally makes Manager flag the pack as "unsafe" - clone manually if so. This node is pure manifest math; no models, no downloads.

The honest take

It's a genuinely thoughtful heuristic, not magic. A PSD where the "background" is a single well-named layer will score near-certain; a chaotic flat-layer soup will sometimes return -1, -1, which is the correct answer. When that happens, the underlay mode on the compositor is your fallback - and the rationale output tells you exactly why the detector gave up.