DensePose Estimator

OpenPose tells a model where the elbows are. DensePose tells it what the surface of the body is doing - a per-pixel map of which body region each pixel belongs to, and where on that region. That's why it shows up in clothing workflows and skin-detail work: it encodes the orientation of a shoulder or a knee, not just a joint coordinate.

UC_DensePoseEstimator is the pack's version: an eager R50-FPN backbone with ROI heads, batched, rendering those body-region maps in Viridis or Parula. It is the one node in this little pose family that's genuinely niche - most people reach for OpenPose or DWPose - but if your ControlNet was trained on DensePose, nothing else will do.

How it works

An RPN proposes person boxes across a few detection scales, those proposals get NMS'd and capped, and the surviving boxes go through cascade ROI heads that output a coarse region label, a fine region label, and U/V coordinates within the region. The renderer takes the coarse label as foreground, the fine label as colour index, and paints each person into the frame with the chosen colormap. the background is purple for Viridis and black for Parula - pick whichever the downstream model was trained against, because getting that wrong is not a small difference.

The README is explicit that this uses torchvision's existing ROI-align and NMS ops rather than Detectron2, which is why it installs as one safetensors file instead of dragging a research stack behind it. It also says, honestly, that the port is verified for conversion integrity while numerical parity and speed are unverified - so compare against a reference output before you commit.

Inputs and what they cost you

image is the batch. Frames are detected independently - there is no tracking and no smoothing between frames, so don't expect temporal consistency out of this node.

cmap is viridis or parula, and that's the setting you'll fiddle with first. resolution at 0 keeps your dimensions; a positive value sets the shortest edge for both detection and output. Higher values genuinely reveal smaller people here, at real cost in time and memory - unlike the RTMPose-based nodes, whose model input size is fixed, this one's detection runs at the resolution you give it.

batch_size defaults to 2, the lowest of any pose node in the pack, and that's a hint about how heavy this is. Raise it if you have headroom; lower it the moment VRAM says no. That does not add tracking.

Then the detection controls: score_threshold (0.05 - deliberately low by default, DensePose would rather catch a partial person than miss one), detection_nms_threshold (0.5) for final person duplicates, and max_detections (100) which caps people per frame by score, so a very low cap will silently drop the back row of a crowd.

The three rpn_* knobs are labelled advanced, and they are. rpn_pre_nms_topk (1000) is candidates per scale before dedupe, rpn_post_nms_topk (1000) is how many go to the person classifier, rpn_nms_threshold (0.7) is duplicate removal within a scale - separate from final person dedupe. Lower the topk values to save time and memory on busy frames; leave them alone otherwise.

Output

One thing: image, one coloured body-region map per input frame, in input order, background-only when nobody is detected. No keypoints, no mask, unlike the human pose nodes in the same pack. Wire it straight into the ControlNet that wants it. And if your DensePose model was trained on a specific palette, matching cmap is the cheap fix people forget.

Install

Manager → search "ComfyUI-UtilsCollection", or:

cd ComfyUI/custom_nodes
git clone https://github.com/silveroxides/ComfyUI-UtilsCollection
# restart ComfyUI

The node needs densepose_r50_fpn.safetensors, downloaded on first execution into ComfyUI/models/controlnet/preprocessors (upstream path preprocessors/densepose/ in silveroxides/ComfyUI-UtilsCollection-Models). Nothing is bundled with the repo. If you're on an air-gapped box, place the file manually; the loader uses an existing local copy and only downloads when the file is absent.

Troubleshooting

The pack imports kornia at load and doesn't list it in requirements.txt, so a missing kornia takes the whole collection - every node, every category - down with an import error rather than just this one. That's the first thing to check when nodes appear to have vanished after an install. torchvision does the ROI and NMS work; if your torchvision and torch versions have drifted apart, this is the node most likely to throw on execution, while the YOLOX/RTMPose nodes keep working.

And the memory one: this runs the backbone at your chosen resolution with up to max_detections boxes per frame at batch_size 2. On a 8–12GB card doing 1080p video, that combination is where you'll hit the wall, and the fix is resolution and batch_size, not the RPN knobs.