DL0192 Depth Anything 3 Cross-View Depth Estimation

How does Depth Anything 3 enable cross-view interaction for consistent multi-view monocular depth estimation, and what architectural changes distinguish it from its single-view predecessors?

Answer

Depth Anything 3 keeps the monocular recipe of its predecessors and changes essentially one thing inside the network: the scope of self-attention. Each of the N input views is patchified by the same plain DINOv2 encoder, the per-view token sequences are concatenated into a single sequence, and the stack then alternates between within-view attention, where a query sees only its own view and fine monocular detail survives, and cross-view attention, where every token attends to every token of every view and correspondence, relative pose, and a common scale are learned. No fusion module, cross-attention adapter, or cost volume is introduced. The pretrained attention weights are simply given a wider window, so a single-view input degenerates exactly to the original monocular model, which is why multi-view capability does not cost single-image quality. The second change is the output: instead of the per-image affine-invariant disparity of Depth Anything V1 and V2, DA3 predicts a depth-ray target per view (a depth map plus a ray map), and depth along predicted rays back-projects to one point cloud and one set of camera poses under a single global scale. That one target replaces the multi-head, multi-task output of VGGT-style geometry transformers, and the reported gains over VGGT are roughly 44% on camera pose accuracy and 25% on geometric accuracy, while monocular depth still improves over DA2.

(1) Attention Scope, Not A New Module: cross-view interaction is implemented by concatenating view tokens and letting the existing self-attention layers run over the union, so no modality-specific or view-specific parameters are added.
(2) Interleaved Within-View And Cross-View Layers: within-view layers protect high-frequency monocular detail, cross-view layers enforce geometric agreement, and the two are alternated through the stack.
(3) Input-Adaptive Degeneration: at N = 1 the cross-view layer is numerically identical to the single-view layer, so the model is a strict superset of its monocular predecessor rather than a compromise.
(4) Single Depth-Ray Target: one head predicts depth plus a ray map per view; depth along rays → point cloud, and camera pose is read out of the ray field instead of a dedicated pose head.
(5) One Global Scale For The Whole Set: normalization is fitted once over all views rather than a free scale and shift per image, which is precisely what removes per-frame flicker and non-overlapping point clouds.
(6) Plain Backbone, Teacher-Student Data: a vanilla DINOv2 transformer with a DPT-style dense head is enough; the accuracy comes from the target and from teacher-student pseudo-labelling, not from architectural specialisation.
(7) The Price Is Quadratic: a cross-view layer costs N times a within-view layer, so view count, not image resolution, becomes the dominant memory term.

Architecture diagram: three input views feed one shared DINOv2 patch embedding that concatenates N times 1369 tokens into a single sequence, which passes through a within-view attention block and then a cross-view attention block interleaved over M blocks, then a shared DPT-style dense head that emits a depth map and a ray map per view, which are fused into one point cloud and camera poses in a shared frame under a single global scale

Figure 1: One encoder, two attention scopes, one target. The only cross-view machinery is the wider attention window, and the only output is a depth map plus a ray map per view, from which the point cloud and the camera poses are derived rather than predicted by separate heads.

It helps to look at the attention mask directly. With N views of L tokens each, a within-view layer is a block-diagonal mask: N independent L \times L blocks, exactly what a monocular model computes, repeated in parallel. A cross-view layer fills in the off-diagonal blocks, and those off-diagonal entries are the whole mechanism, because a token on a wall corner in view 3 can now match the same corner in view 1 and inherit its depth ordering. Because the projection matrices are unchanged, the same weights serve both scopes and the model never has to learn a separate matching operator. The cost of filling those blocks is the reason view count dominates the budget, and it is also the reason non-overlapping views buy nothing: the off-diagonal blocks exist, but there is no correspondence for them to find, so the relative scale between two disjoint clusters of views stays unconstrained.

Two 3-by-3 block attention masks for three views with eight tokens each: the left mask has only the three diagonal within-view blocks filled and the six off-diagonal blocks marked masked, totalling 192 token pairs; the right mask has the diagonal within-view blocks plus all six off-diagonal cross-view blocks filled, totalling 576 token pairs

Figure 2: The same layer, two masks. Single-view models compute only the block diagonal; DA3 fills the off-diagonal blocks, and cross-view correspondence lives entirely there. The pair count grows from N L^2 to (NL)^2, a factor of exactly N.

Mathematical Formulation:
Z = [\,X_1; X_2; \ldots; X_N\,]
A_{\mathrm{within}}(v) = \mathrm{softmax}(Q_v K_v^{\top}/\sqrt{d})V_v
A_{\mathrm{cross}} = \mathrm{softmax}(QK^{\top}/\sqrt{d})V
P_v(u) = o_v + d_v(u)\, r_v(u)
s = \mathrm{median}_{v,u}\, \| P_v(u) \|
C_{\mathrm{within}} = N L^2
C_{\mathrm{cross}} = N^2 L^2

Where:

  • X_v \in \mathbb{R}^{L \times d} holds the tokens of view v and Z \in \mathbb{R}^{NL \times d} is the single concatenated sequence the transformer actually sees.
  • Q_v, K_v, V_v are the projections restricted to one view, while Q, K, V are the same projections applied to all of Z; the weights are shared, only the scope differs.
  • u indexes pixels, v \in \{1,\ldots,N\} indexes views, L = (H/p)(W/p) is tokens per view for patch size p, and d is the model width.
  • d_v(u) is the predicted depth and (o_v, r_v(u)) the predicted ray map (origin and unit direction) expressed in a shared frame, so P_v(u) is a 3D point in that frame and the camera pose follows from fitting r_v.
  • s is a single global scale estimated jointly over all views and pixels, replacing the per-image scale and shift used by affine-invariant monocular training.
  • C_{\mathrm{within}} and C_{\mathrm{cross}} count attention token pairs per layer, so their ratio is N and the KV cache of a cross-view layer grows linearly in N.

Token Budget At 518 Pixels And Patch Size 14:
L = 37 \times 37 = 1369
N L = 32 \times 1369 = 43808
C_{\mathrm{within}} = 32 \times 1369^2 \approx 6.0 \times 10^{7}
C_{\mathrm{cross}} = 43808^2 \approx 1.92 \times 10^{9}

Thirty-two views at a modest resolution already put nearly 44k tokens in one sequence, and a single cross-view layer touches about 1.9 billion token pairs against 60 million for a within-view layer. This is why the interleaving ratio is a real design knob rather than a detail: every cross-view layer you insert buys consistency and pays N times the attention cost, and it is why the practical deployment question for any-view geometry models is not accuracy but how many views fit on the device.

Log-scale line chart of attention token pairs per layer versus number of input views from 1 to 64, with a dashed blue line for a within-view layer growing linearly as N times L squared and a solid orange line for a cross-view layer growing quadratically as N L squared, annotated at N equals 32 with 43808 tokens and 1.92 billion versus 60 million pairs, and a note that the two curves coincide at N equals 1

Figure 3: Consistency is not free. A within-view layer scales linearly in view count while a cross-view layer scales quadratically, and the two curves meet at N = 1, which is the formal statement of the input-adaptive property that keeps monocular quality intact.

The target change matters as much as the attention change. A per-image affine-invariant prediction is ambiguous by construction: two frames of the same room can be individually excellent and still disagree by a factor of two in scale, so stitching them produces a doubled wall. Fitting one scale over the whole view set turns depth from a per-image ranking problem into a set-level geometry problem, and the ray map supplies the missing piece by encoding where each pixel’s viewing ray points in the shared frame. Camera intrinsics and extrinsics then fall out of the ray field by a least-squares fit rather than from a separate pose head, which is the concrete sense in which DA3 collapses a multi-task output into a single one.

PropertyDepth Anything V1 / V2VGGTDepth Anything 3
InputOne image, independently per frameA set of images in one forward pass1 to N views, optionally with known poses
Cross-view mechanismNone; consistency is a post-processing problemAlternating frame-wise and global attention with dedicated camera tokensInterleaved within-view and cross-view self-attention, no new parameters
Prediction targetAffine-invariant relative disparitySeparate heads for camera, depth, point map, trackingA single depth-ray target per view
Scale handlingFree scale and shift per imageSet-level, anchored to the first cameraOne global scale fitted over the whole view set
Camera poseNot producedPredicted by a dedicated camera headRead out of the predicted ray map
BackboneDINOv2 ViT with a DPT dense headViT with specialised camera and register tokensPlain DINOv2 ViT, no architectural specialisation
Dominant failure modeTemporal flicker and misaligned point clouds across framesMulti-task head interference and heavy memoryQuadratic cost in N; needs genuine overlap between views

Login to view more content


Log in to track your progress

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *