Change 3D camera depth resolution and field of view at capture time

A point cloud that comes out dense, cropped or noisy is often not a software bug at all: the depth camera was simply capturing at a different resolution or field of view than your conversion code assumed. Whether you capture PLY scans from a structured-light camera or profile parts with a laser profiler, check the device's supported configuration controls before the stream starts. This guide walks through configuration files and capture code, shows how to verify which mode is actually active, and lists the checks that save a re-scan.

What you need

• The camera SDK installed, with its C++ or Python examples building cleanly.
• The device's documented configuration file, if the example supports one.
• The list of depth stream modes your model supports, from the SDK documentation or by querying the device.
• A viewer for the result: any PLY or point-cloud viewer will do.

Obtain the SDK, examples and documentation from the manufacturer or its authorized distributor.

If you are still choosing hardware, the 3D sensors category covers laser profilers, structured-light stereo cameras and ToF models, and the camera finder filters them by type and series.

Method 1: edit the device configuration file

If the SDK example supports a configuration file, check which settings it reads and when it reads them. A file may describe requested stream dimensions, frame rate and format, but its structure and available controls depend on the SDK.

1. Close every application holding the camera. Another process may prevent your application from opening or configuring the device.
2. Open the documented configuration file and find the depth sensor block.
3. Set the requested width and height to a mode from the supported list. An unsupported request may fail or select a fallback, depending on the application.
4. Set the frame rate and pixel format for the depth stream.
5. Save the file and rerun the example according to its documentation. Confirm the file is loaded at start-up rather than compiled into the application.

The advantage is speed: you can try several modes without changing capture code. The disadvantage is that the file only expresses a request. If the device or driver cannot honour it, the application may reject it or substitute another mode. Read back the result rather than assuming the request succeeded.

Method 2: set resolution and ROI in code

For anything that ships, configure the stream in code before opening it. Adapt this pattern to the SDK's documented acquisition sequence:

1. Enumerate the devices and open the one you want.
2. Query the depth sensor's supported configurations, including dimensions, frame rate and format where available.
3. Pick the profile that fits your part, or fail with a clear message if none does.
4. Create the stream configuration from that profile and start streaming.
5. Read back the actual frame dimensions on the first frame and compare them with what you requested.

A minimal pattern, in SDK-independent pseudocode:

profiles = device.depth_sensor.stream_profile_list()
target   = profiles.find(width=1280, height=1024, fps=30)
if target is missing: raise "mode not supported"
sensor.start(target)
first = sensor.wait_frame()
assert first.width == 1280 and first.height == 1024

These dimensions and frame rate are illustrative, not a specification for any product shown here.

To narrow the captured area without changing the lens, use a depth ROI if the device supports it. Otherwise, crop the depth image or point cloud in software. Cropping does not increase the original sampling density or inherently improve depth accuracy. A device-side ROI may affect acquisition rate, but that depends on the camera's implementation. The optical field of view stays fixed; only the used portion changes.

Why the active mode decides your point cloud

Point-cloud conversion back-projects each depth pixel using the camera's intrinsics and its documented depth convention. Intrinsics depend on the image coordinate system. For simple resizing, focal lengths in pixels scale with image dimensions; cropping also changes the principal point relative to the new origin. Different sensor modes may require their own calibration rather than a simple scale factor.

Two rules keep this safe. First, obtain calibration matched to the active stream through the SDK's documented interface. Second, size the point-cloud buffers from frame.width and frame.height, never from constants. Our article on mapping image pixels to 3D points walks through the pixel-to-point path in detail.

For an undistorted pinhole image whose depth values represent optical-axis distance, the conversion is:

Here fx, fy, cx, cy must match the image you are actually converting. Apply the documented depth scale first. If the device reports distance along a viewing ray instead of optical-axis distance, use its documented conversion rather than this formula unchanged.

Choosing a mode for the part

Resolution affects point count and data volume. Available frame rates and depth noise may also change between modes, so check each supported combination. A worked example:

A hypothetical structured-light camera captures a bracket at 800 mm working distance, and the application requires lateral sample spacing no greater than 0.5 mm. At a 60-degree horizontal field of view, the footprint is roughly 2 × 800 × tan(30°) ≈ 920 mm wide. A 1280-pixel-wide depth map gives about 0.72 mm per pixel — too coarse. A supported 2560-pixel-wide mode covering the same footprint would give about 0.36 mm per pixel, meeting that sampling requirement.

This does not establish dimensional accuracy or reliable detection of a feature that small. Those also depend on depth noise, optical performance, surface properties and the number of samples needed across the feature. If both image dimensions double, the nominal point count increases by four, so check your processing budget before committing.

For a volume-measurement camera, choose coverage and sampling from the parcel-size range and permitted volume error. The widest captured area is useful only if it still meets those requirements.

Where the modes differ by camera type

Laser profilers require a different sampling calculation. Across-profile spacing depends on the measurement width and available samples. Along-travel spacing depends on motion speed and profile rate. Depth repeatability is a separate specification, not another name for lateral resolution.

For example, at 500 mm/s travel speed and 1000 profiles/s, along-travel spacing is 500 ÷ 1000 = 0.5 mm. Check encoder triggering and acquisition timing as well as the nominal rate.

The line scan calculator helps with the corresponding speed-to-sampling arithmetic:

A binocular single-line model such as the MV-DP3062-01D V2.0 is laser profiling hardware. Do not assume that it exposes the same stream controls as an area-mode depth camera.

The MV-DPS200P-02 is a projected structured-light camera, while the MV-DLS300P-04 is a laser galvanometer stereo camera. Consult each model's documentation for supported acquisition settings rather than assuming that the same profile-list API applies to both.

For laser profiling hardware, the laser profilers finder and a laser profile sensor product page provide starting points for hardware selection. Confirm the available sampling controls in the model's documentation before implementing configuration code.

Verifying the set-up before a scan run

Run this checklist once per mode you intend to use in production:

• The first frame's width and height match the requested profile exactly.
• The calibration belongs to the running mode, not an unrelated cached configuration.
• The depth ROI lies inside the mode's dimensions, and its returned dimensions match your request.
• A scan of a known gauge block returns the expected size in X, Y and Z within your tolerance.
• The point count per frame fits your processing budget at the target frame rate.

When the usual answer is wrong

If you need finer detail than the camera's highest depth mode delivers, changing settings will not get you there. Possible options include moving the camera closer within its supported measurement range, choosing a narrower field of view at the same resolution, or evaluating a laser profiler for the critical dimension.

Moving closer reduces the footprint and therefore the lateral spacing between samples, but it does not guarantee better depth accuracy. Check minimum range, usable coverage and surface behaviour before changing the mounting position.

Use the camera resolution calculator to check the lateral pixel budget:

If the depth values themselves jitter between frames at a fixed resolution, that is a stability problem, not necessarily a mode problem — see the note on close-range surfaces in close range depth dropout.

Quick checklist

• List supported depth modes once; store the list with the project.
• Request modes in code; keep the configuration file for bench experiments where practical.
• Load calibration matched to the active mode and image coordinates.
• Verify first-frame dimensions and a gauge-block scan before every production run.
• Recalibrate only when required by the documented procedure or when validation shows the existing calibration is unsuitable.

To build a complete 3D station around the camera — mount, controller and triggering — start with the system configurator or ask the team through the contact page.