Visual localization works out where a camera is, and which way it points, from the image it took. It compares the photo against a 3D map of the place and returns a 6-DoF pose, three numbers for position and three for orientation, in the map's coordinate frame.
It works under a roof that blocks GPS, and on any device with an ordinary camera. MultiSet's API returns that pose with a sub-5 cm median error, from a map built out of the scans you already have.
A pose has six numbers. X, Y and Z place the camera in the map, and roll, pitch and yaw give the direction it faces. Position alone is enough to draw a route on a floor plan. You need the full pose to put a label on one valve among forty, or to tell a robot which shelf it's facing.
The pose is absolute. It's stated in the map's own frame, so a phone today, a headset next week and a robot on the night shift all get coordinates that agree with each other. Georeference the map once and the same pose also comes back as an OSCP GeoPose, with latitude, longitude and altitude.
Every MultiSet response carries a confidence value next to the pose. A wrong pose delivered confidently does more damage than no pose at all, so a correct integration checks it before placing anything.
Camera localization is the name machine-learning papers tend to use, especially for methods trained on one scene at a time. Image-based localization turns up mostly in the older computer-vision literature. Visual relocalization, or camera relocalization, usually means recovering pose after tracking was lost, which is the same computation started from a cold view.
Camera pose estimation is the wider family. It also covers the relative pose between two photos, and pose against a printed calibration target, where nobody has mapped the place.
All four use a camera to reason about place, which is why they get mixed up. Each answers a different question.
| What it tells you | Output | Frame | Survives a restart | |
|---|---|---|---|---|
| Visual localization | Where the camera is in a known map | 6-DoF pose | The map's, shared by every device | Yes |
| Visual SLAM | How the device moved, and what the space looks like | Pose plus a map built on the fly | Starts wherever the device started | No |
| Visual odometry | How far the device moved since the last frame | Relative motion | Relative, drifts with distance | No |
| Visual place recognition | Which mapped place the image resembles | The closest mapped image or place | Place level, usually metres | Yes |
In production they're layered. The device's own tracking (ARKit, ARCore or a robot's odometry) handles motion from frame to frame, and visual localization supplies the absolute fix that cancels the drift. The full comparison is on VPS vs SLAM.
Published methods fall into four families. They differ in what they store about the scene, and in how close to the true pose they get.
Structure-based methods keep a 3D model of the scene and match the photo against it. The open-source hloc toolbox (Sarlin et al., CVPR 2019) is the usual baseline on large benchmarks such as Aachen Day-Night and LaMAR. Map size and query compute are what this family pays for its accuracy.
Scene coordinate regression trains a network to predict where each pixel sits in the scene. ACE (Brachmann et al., CVPR 2023) cut per-scene training from hours to minutes while holding the accuracy of earlier methods in this family. Each new space still needs its own training run.
Absolute pose regression trains a network to output the pose straight from the image, starting with PoseNet (Kendall et al., ICCV 2015). It's compact and fast. Sattler et al. (CVPR 2019) showed these networks behave more like image retrieval than 3D geometry, and that they didn't reliably beat a simple retrieval baseline.
Retrieval-only localization finds the most similar mapped photo and borrows its pose. That's place recognition pressed into service, and it's accurate to roughly the spacing between mapped images, which is enough to route a person and too coarse for an AR overlay.
Benchmarks score recall, the share of query photos localized within a distance limit and an angle limit at once. A query that returns nothing counts as a miss.
7-Scenes (Shotton et al., CVPR 2013) covers small indoor rooms recorded with a Kinect. Cambridge Landmarks arrived with PoseNet in 2015 and covers outdoor scenes in central Cambridge. Aachen Day-Night (Sattler et al., CVPR 2018) localizes night photos against a map built in daylight, scored from 25 cm and 2° up to 5 m and 10°. LaMAR (Sarlin et al., ECCV 2022) comes from ETH Zurich and Microsoft and was built for augmented reality. Its three Zurich scenes were captured over about a year, queries were often recorded months after the map, and it scores at 10 cm and 1° and at 1 m and 5°.
The long-running leaderboard for Aachen Day-Night and its sister datasets is at visuallocalization.net.
Averaged over LaMAR's three scenes, MultiSet Gen2.5 localizes 79.74% of phone queries within 10 cm and 1°, from a single photo per query with Deep Search. That's more than any published method. The previous best published result, ImLoc (Jiang et al., 2026), is 74.24%. Within 1 m and 5° the figures are 89.07% and 85.89%.
These are validation-split results, with the map built only from LaMAR's own images and laser scans. The full table, protocol and sources are in the Gen2.5 announcement.
Validation split. ImLoc and hloc (SuperPoint with SuperGlue) from Jiang et al., ImLoc, 2026, Table 2. LaMAR official pipeline with MegaLoc retrieval from Berton and Masone, CVPR Workshops 2025, Table 2. Gen2.5 with Deep Search. Scene renders use LaMAR's own images, Sarlin et al., ECCV 2022.
Field queries are harder than benchmark ones, and the conditions that fail them are the ones LaMAR was designed around.
Look-alike spaces. Stations, office floors and plant rows repeat, so a photo of one platform can resemble another.
Time since the scan. Lighting shifts, pallets move and walls get repainted in the months after a map is captured.
Awkward views. Close-ups, motion blur, odd angles and partial occlusion leave little of the scene in frame.
Weak texture. Blank walls, glass and uniform racking give the camera very little to recognize.
Taking visual localization from a paper to a product means hosting maps, answering queries in seconds and keeping maps current as the site changes. MultiSet runs all of that as a service.
Maps from any scan. E57 from Leica, NavVis, FARO or Matterport, Matterport MatterPak, Gaussian splats, 360 video, and LiDAR or phone captures from the MultiSet app. Phone mapping without LiDAR reaches the same localization accuracy and suits areas under 5,000 sq ft.
Accuracy and speed. Sub-5 cm median 6-DoF error, an SLA under 10 cm, and drift under 1 cm at 10 m. A cloud query takes 1.5 to 2.5 seconds for one frame and 2.7 to 3.5 seconds for four to six. On-device localization runs in about 52 ms.
SDKs for each device. Unity, native iOS and Android, WebXR, Meta Quest and smart glasses, a Unitree Go2 adapter for ground robots, with ROS 2 as a supported SDK target. A REST API covers anything else with a camera.
Deployment where your data must live. MultiSet's cloud, a single-tenant private cloud in your region of choice, on-premises, or fully on-device.
Versioned maps. Re-scan a changed site and anchored content stays where it was placed, and a bad update can be rolled back.
The Free plan doesn't expire, so you can map a space and test localization against it before talking to anyone. Start free or request a demo.
