Summary from Prepare Info

Smart Photo Prepare makes a lot of decisions you didn't type in: which crop, which aspect, which resolution tier, how much padding. When the output is not what you pictured, you need to know why - and this reader is where that explanation lives. It takes the preparation bundle, you pick one of four fields, and it hands you a STRING.

field options:

• debug (default) - the plan's debug line, the one-stop summary of what happened.
• resolution - the chosen output profile, as a human-readable label.
• selection_reason - why this crop/resolution won over the alternatives.
• JSON - the whole diagnostics object, pretty-printed.

Output is text. Wire it into a text note, a console/log node, or anything that displays strings.

What the two useful fields tell you

selection_reason is the one to reach for first. Preparation picks from candidate crops and tiers in a fixed order - a crop that retains the whole subject and its safety margins wins outright, even if padding would have changed fewer pixels; only when no safe crop exists does it compare limited intrusion within crop_tolerance_px against padded alternatives, by total pixels changed. So when a result is tighter or looser than you wanted, selection_reason names the rule that fired, and you can go straight to the dial that feeds it: headroom_ratio, side_margin_ratio, bottom_priority, crop_tolerance_px, or the resolution policy in Input & Crop Config.

debug gives you the plan in one line: target, policy, source dimensions, the crop rectangle, the crop loss percentage, the output resolution, resize method, removed/added/changed pixel counts, framing cost, and any margin intrusion per edge. If you only read one thing when you're confused, read this - "added_px" in the thousands with a protected mask connected is your answer, and it isn't a bug.

resolution is the friendly name of the tier and family that was selected. It's the shortest way to confirm the Active Editor Target you thought was live actually was.

JSON dumps the structured diagnostics: the plan, selection reason, changed-pixel counts, padding, margin intrusion, and warnings. If you're filing an issue or comparing two runs precisely, that's the payload - and it's also where the source_to_output() / output_to_source() coordinate transforms come from, which is what you want if you need to map a point in prepared_image back to the original photograph. Don't try to reconstruct that mapping from the scale factors; padding moves the origin.

Wiring

Smart Photo Prepare.prepare_info → Summary from Prepare Info.prepare_info
                                        field = JSON
                                        text → ShowText / a note / log node

Worth wiring permanently into your working workflow as a debug or selection_reason reader into a text display, honestly. It costs nothing - the info bundle already exists - and it turns "the crop is weird" from a guessing game into a reading. Pick JSON only while you're actually debugging; it's verbose and it'll bury the note node.

Install

Part of the pack, nothing extra to fetch. ComfyUI Manager → PortraitUtils, install, then restart the ComfyUI server - refreshing the browser does not reload Python nodes, and this is the step people skip before deciding a node "didn't install."

cd ComfyUI/custom_nodes
git clone https://github.com/heyburns/PortraitUtils
/path/to/ComfyUI/venv/bin/python -m pip install -r PortraitUtils/requirements.txt

Use ComfyUI's Python or python_embeded on Windows portable. Pack dependencies: numpy, Pillow, opencv-python-headless, tifffile - one OpenCV variant only. The node appears under PortraitUtils/Photo Edit V2/Readers.

Two failure modes worth knowing, both real. Feeding it a different bundle type - a source-info or edit-config object - raises a type error telling you to connect Smart Photo Prepare's info output, so if you get that message, your wiring is wrong, not the node. And if the reader renders a stale-looking string after you changed a setting, check whether preparation re-ran at all: an unchanged upstream graph gets cached, so the info bundle is from the previous execution. Change something upstream or force a fresh run before you trust the text.