Atlas Anchor Depth to Render πͺ’
Making a per-frame estimate trust the build's scale
- estimated
- anchor
- moge_geometry
- report
When you're warping a clip through a camera move, you need depth that tracks what moves on the right scale. And here's the trap: no single depth source gives you both. A rendered depth pass (say, from Unreal) is exact for everything in the build and has no opinion about anything that isn't - so a figure your video model invented halfway through the clip is simply absent from it, and a still render repeated across frames warps that figure with the depth of whatever it walked away from. A monocular estimate like MoGe tracks the figure, because it actually looks at each frame, but it re-derives its own scale and focal every time. Run that on its own and the move lands at the wrong depth, with nothing raising an error.
Atlas Anchor Depth to Render πͺ’ is the fix: it takes the tracking from one source and the scale from the other. Feed it a per-frame estimate (the tooltip names the upstream as "Run MoGe Inference" - geometry that tracks the moving content) and an anchor (rendered geometry - Atlas Unreal Depth Geometry, or the relief, which carries the build's true scale, shift and intrinsics). It fits z_render β sΒ·z_est + t in a single least-squares pass on the one frame the two share, trims it once, and carries that scale onto every frame of the estimate. What comes out is the estimate's depth - still tracking the invented stuff - but standing on the render's metres.
The trim is the secret, not a refinement. The two sources only disagree in two places: where the render is missing something the estimate can see, and where the render is a backplate card pretending to be distance. Both are minorities of the frame with huge residuals, so trimming drops them from the fit while leaving them in the output - which is the whole point, since those pixels are why you brought the estimate here in the first place.
The inputs that matter
Honestly, defaults get you most of the way. The ones worth touching:
fit_space-depth(default) fits in linear metres, which is right because MoGe v2 returns metric depth. Switch todisparityonly if your estimator is relative rather than metric; the author measured depth-space winning on a coastal scene except under 15 m.trim_sigma- defaults to 3. Drop it toward 0.5β2 when invented content fills the frame and you want more of it excluded from the fit.fit_shift- leave on unless your estimate is truly metric and carries no near-plane bias.
Outputs are moge_geometry (wire it wherever you'd have wired the raw estimate - it feeds the same warp) and a report string. That report is worth a PreviewText at least once: it tells you the fitted s and t. A scale far from 1 is the honest measure of how much the estimate alone was out, and the sort of thing you want to see rather than discover in the render.
Installing it
This ships in the atlas-camera pack, so it's one install:
cd <ComfyUI>/custom_nodes
git clone https://github.com/mikejamesvfx/atlas-camera.git
Restart ComfyUI, and the Atlas nodes appear under the Atlas menu. ComfyUI Manager users can search "atlas-camera" instead. No pip step for this node - the core pack is dependency-free and needs only the ComfyUI-bundled numpy/torch. What you do need upstream is a MoGe-style inference node producing MOGE_GEOMETRY per frame, and a rendered-geometry source for the anchor.
Where people get burned
The two inputs are easy to swap without noticing, and the failure is silent-ish: swap them and the fit goes the wrong direction. Also remember a still render repeated across the clip has only frame 0 - keep anchor_frame at 0 and let estimated_frame point at the frame the clip and render share. And don't read the trimmed residuals as "the depth is good everywhere" - the outliers that were excluded are exactly the pixels the estimate exists for.
One honest caveat: this node lives in the pack's advanced tier, and it's a real-pipeline tool - it presupposes you have both a rendered depth pass and a per-frame estimator over the same shot. If you're just getting a single photo moving, you don't need it. If you're compositing generated motion over a dressed render, it's the difference between a camera move that reads as real and one that drifts into the wrong layer of space.
Inputs (7)
| Name | Type | Default | Description |
|---|---|---|---|
| estimated | MOGE_GEOMETRY | Per-frame geometry from Run MoGe Inference. Supplies the depth that tracks what moves, and its own mask. | |
| anchor | MOGE_GEOMETRY | Rendered geometry β Atlas Unreal Depth Geometry, or the relief. Supplies scale, shift and the true intrinsics; its depth is not carried through. | |
| anchor_frameopt | INT | 00β4096 | Which frame of the anchor to fit against. A still render repeated across the clip has only frame 0. |
| estimated_frameopt | INT | 00β4096 | The frame of the estimate that lines up with it. Normally 0: the frame the clip and the render share. |
| fit_spaceopt | COMBO | depth | Where the fit is solved. DEPTH by measurement, not by theory: disparity (1/z) is the textbook alignment for a RELATIVE estimate, but MoGe v2 returns metric depth, so a linear relation in metres holds and fits better. Measured against a rendered pass on a 5m-1.2km coastal scene, depth-space median error was 3.6% mid-field and 9.1% far against disparity's 8.2% and 25.6%; disparity won only under 15m, 6.6% to 7.5%. Try disparity if your estimator is relative rather than metric. |
| fit_shiftopt | BOOLEAN | true | Fit an offset as well as a scale. Off forces the fit through the origin, which is right when the estimate is truly metric and wrong when it carries a near-plane bias. |
| trim_sigmaopt | FLOAT | 3.00.5β20 | Residuals beyond this many robust deviations are dropped and the fit repeated once. Lower excludes more of the disagreement; 0.5-2 if invented content fills the frame. |
Outputs (2)
| Name | Type | Description |
|---|---|---|
| moge_geometry | MOGE_GEOMETRY | β |
| report | STRING | β |