Your 3D camera is fine. The raw depth image shows the object, the vendor's viewer shows it too, yet the point cloud you build in your processing library stops dead at a short distance and everything beyond it is gone. In nearly every case the cause is not the sensor but one number: the depth scale. The library that converts depth pixels into 3D points assumes a default unit, your camera reports a different one, and the conversion silently compresses your entire scene into the first few centimetres. This guide shows how to read the scale, pass it correctly, and verify the result.
What the depth scale actually does
A depth image is a grid of integers. To turn one into a 3D point, software multiplies the pixel value by a scale factor to get metres:
Here u, v are pixel coordinates, fx, fy, cx, cy come from the camera intrinsics, and depth_scale is the factor that converts raw units to metres. A sensor reporting in millimetres has a scale of 0.001; one reporting in tenths of millimetres has 0.01. Get that factor wrong by a factor of ten and a target at 1.5 m is interpreted as 0.15 m, or points are clipped by a range check long before they reach your display.
The failure is silent because the conversion still succeeds. You get a plausible-looking cloud, just a compressed or truncated one.
The symptom pattern
The mismatch has a recognisable signature:
- The vendor's own viewer shows the full scene at correct distances.
- Your point cloud contains nearby surfaces only, or nothing at all.
- The cutoff distance is suspiciously round: the scene ends near 0.15 m when the camera's rated range is 1.5 m, a clean factor of ten.
- Changing exposure, lighting or mounting changes nothing.
If your cutoff distance equals the true range divided by ten (or a hundred), you are looking at a unit error, not a range problem. Before blaming the sensor, run the stereo disparity map troubleshooting after rectification checks to confirm the raw depth stream itself is healthy.
Why the default fails
Many point-cloud libraries and RGBD wrappers carry a built-in default depth scale, often 0.001, because most depth cameras report millimetres. When you construct a cloud from a raw depth image without passing a scale, that default is applied. Cameras in our 3D sensors category span laser profilers, structured-light stereo cameras and ToF sensors, and their reporting conventions are not all the same; a value that is correct for one model is wrong for the next.
The same trap appears when you switch cameras mid-project. Code written against one sensor carries its hard-coded scale to another, and the cloud geometry quietly changes.
Fix: read the scale at runtime and pass it explicitly
- Start the depth stream with your camera SDK and let the profile come up, exactly as you would for any acquisition.
- Query the depth scale from the active stream profile. Most SDKs expose it as a property of the depth sensor or stream; on some cameras it is called depth units. Never copy it from a tutorial.
- Build your depth image and colour image from the same acquisition so they stay registered. The timing matters too; see depth and color synchronization: check the right timestamps.
- Pass the queried scale into the conversion call. In a typical Python path, the function that creates the cloud from an RGBD image accepts a
depth_scaleargument; supply the value you read, not the default. - Convert intrinsics to the library's format from the same profile, so focal lengths and principal point match the depth image exactly. The mapping details are in camera intrinsic parameter conversion for depth and texture images.
- Rebuild the cloud and check that points now exist at the far end of the working range.
The same rule applies if you bypass the wrapper entirely: read depth into a NumPy array, query the scale, apply Z = value × scale yourself, and build the cloud from those coordinates. Doing the conversion by hand makes the unit explicit and auditable.
Worked example: the factor-of-ten error
Suppose a structured-light camera reports depth in tenths of millimetres, so its scale is 0.01, but your conversion uses the default 0.001. A target at 500 mm is reported as the integer 50000.
Depending on how the library handles out-of-range values you either see a close-in remnant or an empty cloud, which is exactly the cutoff symptom. The reverse error (camera in millimetres, code assuming 0.01) squeezes a 500 mm target to 5 mm, producing a flat sliver of points near the origin.
Where cameras differ
Laser profilers work differently from area 3D cameras: the sensor returns a profile per scan and the SDK assembles calibrated 3D points for you, so there is often no user-facing depth scale to misuse. Structured-light and stereo cameras such as the MV-DPS200P-02 or the MV-DLS300P-04 deliver depth images that your own code converts, which is where the scale matters. ToF cameras like the MV-DT01WMU report depth over a different working principle and range, so never carry a scale constant between sensor types.
- Type
- Stereo / structured light
- Type
- Stereo / structured light
- Type
- Depth / ToF camera
Whatever the sensor, the verification step is identical: measure a real object with a tape, compare its Z in the cloud, and confirm the error is within the camera's specified depth accuracy.
Checks before you trust the cloud
Run this short sequence after any conversion change:
- Raw stream check: the vendor viewer shows depth at the far end of the range. If not, fix acquisition first.
- Scale check: the queried depth scale is printed in your log and matches the sensor documentation for the current firmware.
- Distance check: a target at a known 500 mm reads within a few millimetres of that value in the cloud.
- Far-range check: points exist at the far end of the working volume, not just close up.
- Coordinate check: X and Y agree with the measured width and height of the target, not only Z. A scale error distorts all three axes together.
If X and Y are right but Z is wrong, the problem is not the scale but the intrinsics or a rectification issue; the depth image field of view article explains how stereo depth coverage can differ from the colour image even when everything else is correct.
When the usual answer is wrong
A scale fix will not help if the raw depth image is already empty at range. Check these in order before touching conversions:
- The object is beyond the camera's specified working volume. Structured-light sensors have a limited range; a laser profiler or a long-range model is the right tool there.
- The surface itself returns no depth: dark, shiny or fuzzy materials drop out, as covered in close-range depth dropout on fuzzy surfaces and thin parts.
- External infrared light or bright sunlight is drowning the projector pattern; the fixes in stereo depth lighting optimization for dark surfaces apply to over-bright scenes too.
- Processing power: a cloud with millions of points needs real compute headroom, which is why we size vision controllers with enough CPU, RAM and network ports for every camera in the cell.
Prevention checklist
- Query and log the depth scale at every startup; never hard-code it.
- Re-check the scale whenever firmware, SDK or camera model changes.
- Keep a 500 mm and a 1000 mm reference target on the line for daily geometry verification.
- Store the scale value alongside recorded captures so archived data can be re-processed correctly.
- Convert intrinsics and scale from the same active profile in the same call path.
Next step
If you are selecting a 3D camera for a cell where the working range is fixed, start from the 3D sensor finder at /shop/cameras/ and filter by type and range, or walk the full selection in the system configurator. For help matching a sensor's depth units and output format to your processing pipeline, contact our applications team via the /contact/ page.
Questions
Why does my point cloud only show objects within a short distance?
Almost always a depth scale mismatch. The camera reports depth in units it declares itself, such as millimetres or tenths of millimetres, but the conversion library assumes its own default unit. Every value is interpreted with the wrong factor, and anything beyond a short range falls outside the volume the library keeps. Reading the scale from the camera at runtime and passing it explicitly fixes it.
How do I find the depth scale my camera uses?
Query it from the SDK after the stream starts, not from documentation or a hard-coded constant. Most machine-vision SDKs expose it as a property or profile attribute on the depth stream, such as a depth unit or scale factor. Print it once at startup during development and log it in production so a firmware or model change cannot silently alter your geometry.
Do I need to change anything on the camera itself?
Usually no. The camera is reporting correct data; the error is in how downstream code converts depth values to metric coordinates. Leave the sensor at its factory depth setting unless your SDK documents a specific unit change, and fix the conversion on the software side where the mismatch actually lives.
How can I verify the fix worked?
Place a flat target at a known distance, say 500 mm, and read the Z coordinate of the cloud at that surface. It should match within the camera's depth accuracy. Repeat at two or three distances across the working range, including the far end where the cutoff appeared, and confirm points are present at every distance.
When is the cutoff a real camera limitation instead?
If the raw depth image from the vendor tool already shows no values beyond a certain range, the sensor itself is at its limit, and no conversion change will recover it. Structured-light and stereo sensors have published working volumes; a ToF camera differs again. Check the raw stream first, then debug the conversion, never the reverse.