☁️BizyAir Metric3D Depth Map

Most depth ControlNet preprocessors (MiDaS, LeReS, the various Depth Anything variants) give you relative depth, this pixel is closer than that one, with no notion of actual distance. Metric3D is the odd one out on that front: it's built to estimate real metric depth, genuine distances in a consistent scale, not just relative ordering. That's a meaningfully different tool, and it comes with a meaningfully different set of inputs to prove it, this is the only depth preprocessor in the BizyAir pack that asks you for camera focal length.

Why metric depth needs fx/fy and the others don't

fx and fy are the horizontal and vertical focal length in pixels, the camera intrinsics a metric depth model needs to correctly scale its output. Without knowing something about the camera that took the photo, there's no way to say "this object is 2 meters away" rather than just "this object is closer than that one." Both default to 1000, a reasonable stand-in when you don't know the actual capture parameters, and honestly for ControlNet purposes getting these exactly right matters less than you'd think, since the ControlNet is reading spatial structure, not literal distances.

That's the caveat worth internalizing before reaching for Metric3D over a simpler option: the community's general finding on depth preprocessing is that relative depth models tend to produce sharper edges and work better for ControlNet conditioning specifically, while metric-accurate models can trade some of that edge sharpness for real-world scale correctness. If your only goal is a clean depth ControlNet pass, a relative model like the pack's own MiDaS or LeReS preprocessors is often the simpler, more reliable choice. Metric3D earns its place when you actually need the metric property, feeding a downstream 3D/measurement pipeline, or when a scene's true depth relationships (not just apparent ones) matter more than edge crispness.

The rest of the controls

backbone picks the model size: vit-small is fastest, vit-large and vit-giant2 trade speed for accuracy, giant2 being the ceiling if quality matters more than turnaround time. resolution is the standard preprocessing-size tradeoff (default 512), push it up if the final generation is large and needs the depth map to hold detail at that scale.

Output is a single IMAGE, the depth map, ready to feed into a depth ControlNet loader same as any other depth preprocessor's output.

Installing it

ComfyUI Manager: search "BizyAir", install, restart. Or clone it directly:

cd ComfyUI/custom_nodes && git clone https://github.com/siliconflow/BizyAir.git

Since this runs on SiliconFlow's cloud rather than locally, you need a BizyAir API key set up before it does anything, via the "click to login" prompt the README points to on first use. Signup goes through phone-number verification, and it's worth knowing in advance that users outside China have reported friction there.

Common issues

If the depth map for ControlNet purposes looks softer or less crisp than you're used to from Depth Anything or MiDaS, that's the expected tradeoff of a metric model, not a bug, try vit-large or vit-giant2 before assuming something's broken, or switch to a relative-depth preprocessor if crisp edges matter more than metric accuracy for your use case. As with every node in this pack, if a run stalls or fails with no obvious cause in the workflow itself, check the API key first.

Separately: BizyAir occasionally ends up installed without you asking for it, when ComfyUI Manager misresolves an unrelated missing-node error on an older shared workflow. That's a real quirk of the Manager's node inference, not malicious software, and it's safe to remove if you didn't intend to install it.