SphereSfM Add Camera Path (Dual-Res)

If you're on the dual-res track - SfM on low-res equirects, training images reprojected from 8K - then SphereSfM Add Camera Path (Dual-Res) is the incremental-add sibling of the plain Add Camera Path node. Same idea: grow an existing dataset with one more Camera Plot + WAN trajectory instead of rebuilding it. Same world-registration mechanism against the base run's _spheresfm_work/. The difference is that the new trajectory arrives with its own hi-res face source, and the node keeps the low-res pose solve and the 8K reprojection in lockstep the whole way.

Where the plain version takes a raw WAN equirect video, this one takes the proxy frames from a HiRes Composite - the low-res equirects SfM will pose - plus that same HiRes Composite's hires_manifest, which carries the exact list of 8K files for the trajectory. You don't point it at a folder; you wire the manifest. That's a cleaner contract than the base dual-res node's hires_dir folder (no count-mismatch guessing), at the cost of being tied to the HiRes Composite graph.

Inputs that matter

• dataset_dir (required) - the existing dual-res dataset to grow. Same value the dual-res build node used as output_name.
• pano_frames_1 (required) - the new trajectory's proxy_frames from its HiRes Composite. Must be the same resolution as the proxies the base dataset was posed on, or the shared-camera assumption breaks.
• hires_1 (required) - the hires_manifest from the same HiRes Composite feeding pano_frames_1. pano_frames_2/3/4 and hires_2/3/4 let you add up to four trajectories at once, concatenated in order.

Everything else mirrors the plain add node, with dual-res flavour:

• frame_stride - stride here, not in a loader. It thins the proxies and the matching 8K files together, which is the only way the two stay aligned.
• matcher_type - exhaustive (default) matches the new frames against the existing ones, which is what lets a separate path link into the reconstruction. sequential only if the clip is a direct temporal continuation.
• adjust_existing_cameras - off (default) keeps existing poses fixed, purely additive. On lets a global solve refine them - and re-renders every cube face from 8K, so it's slow. You'll feel that one.
• retriangulate (default on) - the new images contribute 3D points; off registers poses only.
• face_size - 0 = COLMAP default off the rescaled 8K SPHERE camera. Set the same value the base build used so faces match.
• abs_pose_min_num_inliers (default 30) - lower it if the new frames won't register.
• cleanup_hires_source - off by default, and leave it off until you're done iterating on this dataset. On, it deletes the new trajectory's consumed 8K frames from the HiRes Composite's frames/ folder, but only once a same-size copy is confirmed staged in _spheresfm_work/equirect_hires. Note the hardlink caveat: if frames/ and the staging area are on the same volume, deleting reclaims the directory listing but ~no disk.

Outputs: model_dir, num_images, num_points, and num_added_frames - the last one is your "did it actually register" sanity check.

Install & gotchas

Pack-wide install as usual:

cd ComfyUI/custom_nodes
git clone https://github.com/mickmumpitz/ComfyUI-SplatKit
python_embeded\python.exe -m pip install -r ComfyUI-SplatKit/requirements.txt

Restart, let colmap_sphere.exe auto-download on first SfM run, and make sure the base dataset was built with mode=colmap_now (that's what leaves _spheresfm_work/ behind - a panorama_only build can't be extended).

The failure modes are the same as the plain add, just with one extra way to trip:

• The base dataset must exist and have _spheresfm_work/ - "dataset folder does not exist" means you built it panorama_only or pointed at the wrong folder.
• New frames won't register - the new path has to share view with the existing scene (start it near where earlier paths looked), keep matcher_type on exhaustive, and lower abs_pose_min_num_inliers if needed. It still needs real parallax; a static pan registers nothing.
• Resolution mismatch - if pano_frames_1's proxies aren't the same resolution as the base dataset's, the shared-camera solve breaks. Match them before wiring.

And the same chainability and ordering rules apply: each successful add becomes the base model, so you can keep adding paths; run adds before upscaling the dataset; and keep adjust_existing_cameras off unless the new path genuinely reveals the base poses were off.