DepthAnything_V3

This is the workhorse. DepthAnything_V3 takes an image and a loaded DA3 model and gives you a depth map - plus, if you want it, a whole pile of 3D data most people ignore. If you came here to make a depth map for ControlNet, this is the node, and you can safely tune out two-thirds of its outputs.

Depth Anything V2 Large has been the community's default depth preprocessor since 2024 and nothing really dislodged it. V3 is the follow-up from the same ByteDance team, and for plain monocular depth it matches v2's detail while being a bit sharper and more robust. The bigger deal is what it added underneath: v3 predicts camera pose and ray geometry alongside depth, which is why this node has outputs like ray_origin, intrinsics, and extrinsics hanging off it. For a ControlNet workflow you'll use exactly one output. For 3D reconstruction you'll use most of them.

How it works

You feed it images and a da3_model, it runs the transformer, and it returns depth normalized however you asked. The key knob is normalization_mode, and getting it right is the difference between a clean workflow and a confusing one:

• V2-Style (the default) gives you a depth map shaped for ControlNet - the classic white-is-near, black-is-far preprocessor look, with proper sky handling if your model produces sky masks. This is what you want feeding a depth ControlNet, Qwen edit, or Wan VACE.
• Raw gives you unnormalized metric-ish depth. You want this only when you're building point clouds or meshes downstream. The point cloud nodes actually validate their input and throw an error if they detect normalized depth, so if you're going 3D, switch this to Raw or you'll hit a wall.

The inputs worth setting:

• normalization_mode - covered above. V2-Style for ControlNet, Raw for 3D.
• invert_depth (boolean, default off) - flip this if your depth comes out backwards. This is a genuine footgun people hit on first run: some setups want white as the near surface and get it inverted. If your depth map looks inside-out, this toggle is the fix, no reload needed.
• resize_method and keep_model_size - leave at defaults unless you're fighting resolution mismatches.
• camera_params (optional) - only relevant if you're conditioning on a known camera via DA3_CreateCameraParams. Ignore it for normal depth work.

The outputs

Eleven of them, which looks intimidating but sorts cleanly. For ControlNet / img-guidance work, you only need depth (IMAGE) - wire it straight into your depth ControlNet or a depth-aware model and you're done. resized_rgb_image is handy if you need the input at the same size the model actually ran at.

For 3D reconstruction, the relevant set is depth (as raw depth), confidence (a per-pixel trust map), and sky_mask (a MASK that excludes sky pixels so they don't get flung to infinity in your point cloud). Those three go into DA3_ToPointCloud or DA3_ToMesh. The ray_origin, ray_direction, intrinsics/extrinsics (both the JSON string and the typed versions) are the camera geometry - you need them for multi-view fusion, and you can safely leave them unconnected otherwise. gaussian_ply_path points at a 3D Gaussian export, which only produces real output on fine-tuned Giant/Nested weights (it's a placeholder on the base models).

Picking a model for this node

The KB's long-standing depth lesson applies here: metric accuracy is not what you want for ControlNet - sharp relative edges are. So for conditioning, don't reach for the Metric variant thinking it's "more accurate"; it isn't, for this. Use Large for general work. If you need sky masks (and for clean depth you usually do), load Mono-Large or Metric-Large in the loader, because the plain series returns zeros for sky.

Common issues

Depth looks inverted? Toggle invert_depth - that's the single most common first-run surprise. Getting an error from a downstream point cloud node? You left normalization_mode on V2-Style; point cloud nodes reject normalized depth by design, so switch to Raw. Sky pixels smearing into the distance in 3D output? Your model isn't producing a sky mask - swap to a Mono/Metric/Nested variant in the loader. And if the depth map is quantized to 8-bit when you export it for use in Blender or a compositor, that's the save node clamping, not this node - look for an EXR-capable save node to keep the full precision.