You framed the exact view you wanted in one point cloud window, and now the same view is needed in a second window, a second session or a colleague's workstation. Copying the zoom slider value does not survive the trip: zoom is a derived convenience number that each viewer computes for itself. The value that transfers is the camera's vertical field of view, saved together with the aspect ratio, the near and far planes and the projection type. This how-to shows what to read from the source viewer, the conversion between zoom and degrees with the arithmetic worked through, and the checks that prove the transferred view matches.
Why zoom will not transfer, and what will
Zoom is not a stored, portable property. The viewer internally holds a projection, and the zoom control is one way of writing to it: the number you set is converted into a viewing angle inside that window, and different tools, or two versions of the same tool, do the conversion with their own scaling. Two windows can both report 1.1 and still frame the part differently.
Field of view in degrees carries none of that baggage. 48.9° is 48.9° on every monitor, in every session, in any viewer that follows the ordinary perspective convention. Save the angle and the magnification reproduces; save the pose (eye point, look-at point, up vector) as well and the framing reproduces too. Pan and zoom a 3D view camera from a modelview matrix shows how to rebuild a view from its matrix when your viewer exposes the matrix rather than the pose fields.
What you need
- The source viewer, framed with its interactive controls and left untouched afterwards
- The target viewer or session that will receive the view
- Five values read from the source: vertical field of view in degrees, window aspect ratio, near plane, far plane, projection type
- The pose (eye, look-at, up) when the framing matters, not just the magnification
Read the values after framing is finished: any later scroll, drag or reset invalidates them. Store them in a small file beside the point cloud so the view travels with the data; positions in metres, angles in degrees:
{
"fov_deg": 48.9,
"aspect": 1.3333,
"near_plane_m": 0.05,
"far_plane_m": 12.0,
"projection": "perspective",
"eye_m": [1.2, -1.5, 0.9],
"lookat_m": [0.0, 0.0, 0.05],
"up": [0.0, 0.0, 1.0]
}
This is the save-once, load-everywhere habit of Save camera parameters as a user set that loads on startup, applied to the viewer instead of the sensor.
Steps to transfer the view
- Frame the source viewer with its interactive controls, then stop touching it.
- Read the vertical field of view in degrees from the source view control's field-of-view getter; keep one decimal place, for example 48.9.
- Compute the aspect ratio as window width divided by height: 1280 / 960 = 1.3333.
- Read the near and far planes. If the viewer hides them, set the near plane just in front of the closest geometry (0.05 m in the example file) and the far plane at two to three times the scene depth (12.0 m for a cloud reaching roughly 4 to 5 m).
- Record the projection type: perspective for the conversion below, orthographic for the separate treatment further down.
- Write the five values, plus the pose, into the file shown above.
- In the target viewer, apply the pose first, then call the projection method its view-control class exposes, passing the field of view, aspect ratio, near plane, far plane and perspective flag.
- Read the field of view back from the target and require a match within 0.1°. If it misses, the usual causes are a stale aspect value or the wrong projection type.
If the target exposes only a zoom setter, convert first; the next section has the arithmetic.
# Illustrative pseudocode; method names differ between viewers.
eye_m: list = [1.2, -1.5, 0.9] # source camera position, m
lookat_m: list = [0.0, 0.0, 0.05]
up: list = [0.0, 0.0, 1.0]
fov_deg: float = 48.9 # read from the source view control
aspect: float = 1.3333 # target window width / height = 1280 / 960
near_plane: float = 0.05 # m
far_plane: float = 12.0 # m
projection: str = "perspective"
target.apply_pose(eye_m, lookat_m, up)
target.apply_projection(fov_deg, aspect, near_plane, far_plane, projection)
# The test that proves the transfer
assert abs(target.read_field_of_view() - fov_deg) < 0.1
The zoom-to-degrees conversion, with arithmetic
Most point cloud viewers share one convention: the zoom value scales the half-height of the view plane at unit distance, and the field of view is the vertical angle. Both directions:
Work in degrees throughout so the saved number is degrees. Worked example for a zoom of 1.1:
fov = 2 × arctan(0.5 / 1.1) = 2 × arctan(0.4545) = 2 × 24.44° = 48.9°
Back the other way: zoom = 0.5 / tan(48.9° / 2) = 0.5 / tan(24.45°) = 0.5 / 0.4545 = 1.10. The round trip returns the original zoom, and your own transfer should reproduce exactly that.
| Zoom value | Vertical field of view |
|---|---|
| 0.5 | 90.0° |
| 0.7 | 71.1° |
| 0.87 | 59.8° |
| 1.1 | 48.9° |
| 2.0 | 28.1° |
A viewer reporting 1.1 and a viewer set to 48.9° are provably the same magnification.
Keeping the same coverage when the window shape changes
Aspect ratio is the second silent change: move the view to a window with a different width-to-height ratio and the vertical angle no longer shows the same slice of the part. The horizontal half-angle follows from the vertical one:
Worked example: the 48.9° view in a 4:3 window (aspect 1.3333) has a horizontal half-angle of arctan(0.4545 × 1.3333) = arctan(0.6060) = 31.21°, so 62.4° horizontally. To show that same 62.4° slice on a 16:9 window (aspect 1.7778): tan(v/2) = 0.6060 / 1.7778 = 0.3409, so v = 2 × arctan(0.3409) = 2 × 18.82° = 37.6°.
Save 37.6° for the 16:9 window and 48.9° for the 4:3 window; both then show the same horizontal slice. When screenshots must match pixel for pixel, give both windows the same pixel size and skip the conversion.
Perspective or orthographic
The conversion holds only between perspective views. An orthographic viewer has no field-of-view angle: it magnifies by mapping a fixed slice of world height onto the window height. Transfer the slice, not an angle: if the orthographic source shows 150 mm of part height, save 150 mm and set that visible height on the orthographic target. Mixing the conventions is the classic way to end up with a part that fills one window and floats as a speck in the other.
Where this earns its keep in inspection work
Standardised viewer views matter wherever clouds from 3D sensors get compared: first-article reports, defect comparisons across shifts, screenshots in a quality record. A laser profiler builds its cloud line by line as the part passes the sensor; a projected structured-light camera captures the full surface in one shot. Either cloud outlives the session that captured it, and a saved projection file lets anyone reopen it with the framing you intended.
- Type
- Laser profiler
- Type
- Stereo / structured light
The viewer's field of view is not the sensor's: the capture side sets its own field of view in hardware, which Change 3D camera depth resolution and field of view at capture time covers. Depth image field of view: why stereo coverage is smaller explains why a depth image frames less than the colour image on the same camera. Once the framing is fixed, the cloud's own sampling is a separate setting, as in 3D point cloud x y z resolution settings without distortion.
Checks before you trust the transferred view
- Resize both windows to their real running sizes and re-apply the projection with the actual aspect values, then repeat the step-8 read-back; an aspect inherited from another monitor quietly distorts the framing.
- Convert the target's own zoom back to degrees and compare with the source: the round trip above returned 1.10 from 48.9°, and your transfer should return the source zoom to two decimal places.
- Check the clipping: deepest cloud point plus margin inside the far plane, closest feature outside the near plane.
- Drop the same test part or bounding box into both windows and compare silhouettes; identical framing shows identical outlines.
If the view follows a moving part, the pose updates per frame while the projection values stay constant: 3D camera trajectory visualization from pose updates covers pushing pose updates into a live view. The 3D topic page gathers the rest of the 3D guides.
Choosing what captures the clouds
If the stations you are standardising views for are not built yet, start from the cloud the sensor must produce: line profile or full surface, resolution, mounting, trigger. The 3D camera finder filters the range by type and series:
Laser profilers and stereo 3D cameras
170 models · from $699.00Then build the station around the sensor — camera, mount, trigger and lighting in one pass — or contact us about a specific inspection task.
Questions
The transferred view still looks wrong — what usually caused it?
In order of likelihood: the aspect ratio went in stale, saved from another window size; the target window was resized after the projection was applied; the target viewer is orthographic and ignored the angle; or the pose was applied after the projection and overwrote the magnification. Read the field of view back from the target first. If it matches the saved value, the fault sits in the pose or the aspect, not in the magnification.
Does the field of view alone reproduce the entire saved view?
No. The field of view sets magnification only. The framing also needs the camera pose: eye point, look-at point and up vector, or the equivalent view matrix. Save the pose next to the projection values, apply the pose first, then the projection. A view restored without the pose keeps the same zoom but points somewhere else, which is the most common source of views that come back wrong.
Should I save the near plane as well as the far plane?
Yes. The far plane clips distant geometry; the near plane clips everything closer than it. As a rule of thumb, put the near plane just in front of the closest geometry: 0.01 to 0.05 m for desk-size scenes, 0.2 to 0.5 m for robot cells. Set it too far and the front face of the part disappears from the cloud, so check the closest feature after applying.
How do I keep two windows matched while I keep moving the view?
Save the projection once and re-apply it after any interaction that changes it. Lock both windows to the same pixel size and update the aspect value on every resize event, since resizing changes the ratio even at a constant field of view. If one window shows a live stream of pose updates, push the same projection values into it each frame: the pose moves, the projection values stay fixed.
Is a viewer's field of view the same number as a 3D camera's field of view?
No. The viewer's field of view is the opening angle of the virtual camera that draws the cloud, in degrees. A 3D camera's field of view comes from its lens and sensor at the working distance and is normally quoted as an area in millimetres. The two numbers never correspond; only the pose and projection values reproduce what you saw on screen.