MaskCropWithBBox(FaceParsing)

Exactly what it says: give it a bounding box and a mask, and it hands back the mask cropped down to that box. No feathering, no resizing, no fancy options - it's a scissors, not a whole toolkit. But it's the scissors this pack needs constantly, because the whole point of face parsing is working on a small region of a much bigger image, and every node downstream that's supposed to operate "just on the face" needs its inputs actually cropped to the face first.

Why this exists in the pipeline

Here's the shape of a typical comfyui_face_parsing workflow: a YOLOv8 face detector finds the face in your full image and gives you a bbox. You crop the image to that box (tighter crop = the segmentation model does a noticeably better job, which is exactly why the README bothers running a face detector first instead of parsing the whole frame). The parsing model segments that cropped face into a mask - skin, eyes, nose, mouth, whatever classes you asked for. Now you've got a mask that's sized to the crop, not the original image.

Everywhere after that, you're juggling two coordinate spaces: full-image and face-crop. MaskCropWithBBox is how you keep something already in full-image space (say, a mask you drew, or one produced by a different node against the original picture) cut down to match the crop you're actually working in. It's the mask-side twin of ImageResizeWithBBox - same bbox, same idea, different data type.

The two inputs, one output

• bbox - the region to crop to. Almost always this is going to come straight out of a face detector node or MaskToBBox in this same pack, rather than something you type in by hand.
• mask - the mask you're cropping. Has to be in the same coordinate space as whatever produced the bbox, or the crop lands on the wrong part of the image - a mismatch here is the single most common way this node produces garbage.

Output is a single MASK, cropped to the bbox's dimensions. That output typically feeds straight into a mask operation node (MaskComposite, MaskBorderDissolve) that's meant to work on just the face region, or gets reinserted into full-scale coordinates later via MaskInsertWithBBox.

Installing the pack

ComfyUI Manager: search comfyui_face_parsing, install, restart. Manual route:

cd ComfyUI/custom_nodes
git clone https://github.com/Ryuukeisyou/comfyui_face_parsing.git

Restart. The face-parsing model (.json + .safetensors from jonathandinu/face-parsing on HuggingFace) and the YOLOv8 face detector (face_yolov8m.pt from Bingsu/adetailer) download automatically on first use, landing in models/face_parsing/ and models/ultralytics/bbox. Grab them manually from those two repos if HuggingFace access is unreliable for you - the README lists the exact files.

Where people get tripped up

The coordinate-space mismatch above is the whole story with this node. If your cropped mask looks shifted, stretched weirdly, or is mostly black when you know the source mask has content, the almost-certain cause is that the bbox you're feeding in wasn't derived from the same image the mask belongs to. It's an easy trap to fall into once a workflow has multiple crop-and-reinsert cycles going - you end up with two or three different bboxes floating around the graph and it's not always obvious at a glance which one belongs to which stage. When debugging, trace the bbox back to its source node rather than assuming; a Preview Image on the cropped output, next to a preview of the pre-crop mask, makes a real mismatch obvious in seconds.