Cover HDMasks

Heads up before anything else: this node's declared output type is INT, not MASK. That's not a typo I'm passing along - it's what the schema says, and it's the single most important thing to know before you wire this into anything, because it means you can't chain the result straight into another mask input the way the name "Cover" would have you assume.

What it looks like it's for. The inputs are destination (a MASK), source (a MASK), and an x/y position pair - that's the shape of a paste operation: stamp the smaller source mask onto the larger destination canvas at a given offset. That's a genuinely useful thing to want in this pack's context - if HD-GetMaskArea hands you back a small, cropped mask for a face region, you need something to put it back at the right coordinates inside a full-image-sized mask before you composite a processed crop back into the original photo. It's the same "paste the result back where it came from" job that Impact Pack's Detailer and the Inpaint Crop/Stitch pattern both handle, just without the polish.

But the output doesn't match that story. If it were purely a paste, you'd expect the merged MASK to come back out so you could keep using it. Instead the declared output is a single INT. A few honest possibilities: the node mutates the destination mask in place as a side effect (a known, if unglamorous, pattern in custom Python nodes that pass tensors by reference) and the INT it actually returns is something incidental - a pixel count, a success code, a leftover debug value from development. I can't tell you which from the schema alone, and there's no tooltip or README section for this node to settle it. What I can tell you with certainty is the contract: wire this up expecting a MASK out, and ComfyUI's own type checking will stop you at the socket.

What this means practically. If your workflow needs the pasted-together mask to keep flowing downstream, don't assume Cover HDMasks gives it to you on its output wire - test it first. Connect destination, source, and a couple of x/y values, run it, and check two things: what number actually comes out of the INT socket, and whether destination itself changed as a result of the run (some node inspectors and debug nodes will show you a tensor's contents before and after). That fifteen-minute check will tell you more about how this node actually behaves than any amount of guessing from its name.

The inputs you'll set. x and y are straightforward - the position (in pixels, going by their 0-16384 range) where source gets placed onto destination. There's nothing else to configure.

Installing it. Standard hd_node install: search "hd-nodes-comfyui" or "HD Nodes" in ComfyUI Manager, or cd ComfyUI/custom_nodes && git clone https://github.com/xiaoxiaodesha/hd_node and restart. This node touches no face-detection code, but the pack won't reliably show up in your node search at all without insightface installed in the same Python environment - the README's dependency note covers the whole pack, not just the node that needs it, and a failed import at load time is the most common reason people lose access to every HD node at once. See the HD-FaceIndex article in this series for the details on getting that dependency installed cleanly.

Troubleshooting. Beyond the output-type mismatch above, there's no community discussion or documented failure mode to draw on for this node - it's an obscure personal-use utility with essentially no footprint outside this one repository, so I'd rather flag the gap than invent a troubleshooting list for it. If something about it surprises you in practice, that surprise is the useful signal; this is exactly the kind of rough edge you get from a small pack built to serve one person's pipeline rather than shipped as a general-purpose tool.