Nodes/ComfyUI-Majoor-OmniCam/OmniCam Extractor
ComfyUI Node

OmniCam Extractor

Steal the camera move from real footage without queueing a workflow

By MajoorWaldi·Created 23 days ago·Updated a day ago· 12
OmniCam Extractor
  • video
  • motion_scene
  • solver_coverage
  • report
methodauto
lens_modeauto
fov_degrees53.0
focal_length_mm24.0
sensor_width_mm36.0
max_dimension840
frame_step1
normalize_origintrue
motion_scale1.00
position_smoothing0.15
rotation_smoothing0.10
simplify_keystrue
position_tolerance0.010
rotation_tolerance_deg0.25

Handing a real shot to a video model and saying "replicate this move" is usually a coin flip - most models only half-follow the motion you show them. The OmniCam Extractor attacks it from the other end: it solves the actual 6DoF camera trajectory out of your footage, then hands that trajectory to the rest of the OmniCam pack as a MotionScene. Instead of hoping a model mimics a clip, you give it the recovered camera path - the thing it can actually act on.

It's a matchmove/visual-odometry tool wearing a ComfyUI coat. Feed it one continuous shot and it recovers a relative camera track: where the camera was and how it rotated, frame to frame. It doesn't reconstruct the 3D scene, doesn't recover metric scale, and won't stitch across hard cuts (it reports them instead). What comes out is a canonical one-camera MotionScene you can send straight to a Monitor, or drop into the Director's solved_scene input to keep massaging the move.

The part that surprises people: no queue required

The Extractor carries its own solve panel with a ▶ TRACK button. Clicking it runs the solve immediately as a background job - it does not queue a ComfyUI prompt, load a model, or touch your VRAM for diffusion. You get a live viewport with solver points overlaid, a 3D tab showing the recovered path, and a STOP control that cooperatively halts between safe frames. Solves also happen inside a normal graph run if that's how you wired it, but for iterating on a clip you'll mostly use the panel.

Backends: read this before you're confused by method

There are three solvers, all optional, and none is installed by the pack:

  • DPVO - deep visual odometry; the most accurate, and the only one that wants a CUDA build plus its checkpoint at the fixed path ComfyUI/models/omnicam/dpvo/dpvo.pth.
  • pycolmap - incremental Structure-from-Motion; pip install pycolmap is the whole install (prebuilt wheels). Handles rotation-only shots better than the classic VO below.
  • OpenCV/SIFT - classic essential-matrix visual odometry; needs opencv-python. It can zero out translation on low-parallax or pure-rotation segments.

method defaults to auto, which tries DPVO, then pycolmap, then OpenCV/SIFT and uses the first one that's actually installed. The report output names which backend ran - check it before you trust a solve. If DPVO stalls, its global optimization has a 120-second watchdog that fails with advice (shorten the clip, drop max_dimension, or pick opencv_sift).

The inputs that matter

Beyond video and method, a beginner should care about:

  • motion_scale - the one to actually think about. Monocular translation has no metric scale, so this sizes it for your scene. A handheld shot of a table reads fine at 1.0; an aerial shot may want much more. Rotation is never touched.
  • lens_mode / fov_degrees / focal_length_mm / sensor_width_mm - lens priors. auto guesses; set fov or focal_mm when you know the lens, because the solve gets meaningfully better with a sane prior.
  • max_dimension (default 840) - longest edge fed to the solver; it only ever downscales. Lower it when a solve crawls.
  • The smoothing trio (position_smoothing, rotation_smoothing, simplify_keys + tolerances) - clean-up pass. Defaults are reasonable; smoothing is centred so it adds no lag, and 0 gives you the raw solve.

Outputs

  • motion_scene - the recovered camera as an OMNICAM_MOTION_SCENE; wire to the Director's solved_scene or straight to a Monitor.
  • solver_coverage (FLOAT) - the share of sampled frames that produced a pose. This is not an accuracy score; low coverage means parts of the shot didn't solve.
  • report (STRING) - the human-readable rundown: backend, lens, key count, warnings.

Install & gotchas

Same pack as the Director/Monitor: ComfyUI-Majoor-OmniCam, needs ComfyUI 0.31+. Manager → search Majoor OmniCam, or:

cd ComfyUI/custom_nodes
git clone https://github.com/MajoorWaldi/ComfyUI-Majoor-OmniCam.git

Restart, then install whichever solver you want - with none installed, auto degrades to OpenCV/SIFT and that only works if opencv-python is present. One hard cut mid-clip comes back as a warning and pycolmap keeps only the largest reconstruction. And remember: this is a relative camera track. No metric scale means what you get is motion, not a measure of the world - that's exactly why motion_scale exists. The node is marked experimental like the rest of the pack, so expect the panel and report format to shift as it matures.

CategoryMajoor/OmniCam

Inputs (15)

NameTypeDefaultDescription
videoVIDEO,IMAGEOne continuous shot, as a VIDEO or as an IMAGE batch. Hard cuts are reported, not stitched.
methodCOMBOautoauto takes the first solver actually installed: DPVO, then pycolmap, then OpenCV/SIFT. The report names the one it ran. Pick a solver by name to force it and get an install hint if it is missing.
lens_modeCOMBOauto3 options: auto, fov, focal_mm
fov_degreesFLOAT53.010–140
focal_length_mmFLOAT24.01–300
sensor_width_mmFLOAT36.04–70
max_dimensionINT840320–1920
frame_stepINT11–10
normalize_originBOOLEANtrue
motion_scaleFLOAT1.000.01–100Monocular translation has no metric scale; this sizes it for your scene.
position_smoothingFLOAT0.150–1
rotation_smoothingFLOAT0.100–1
simplify_keysBOOLEANtrue
position_toleranceFLOAT0.0100–10
rotation_tolerance_degFLOAT0.250–20

Outputs (3)

NameTypeDescription
motion_sceneOMNICAM_MOTION_SCENE
solver_coverageFLOAT
reportSTRING