Depth camera color stream missing: the enable-order fix

You connect a stereo depth camera, open the viewer, and only the depth channel is there — the color stream is missing. Before you suspect a broken camera, look at the architecture: many stereo 3D cameras have no separate RGB sensor at all. The color image is generated from one of the stereo imagers inside the camera and processed through an internal image signal processor (ISP), so it never appears as an independent device. Here you will find where the color control actually lives, why the 3D point cloud only takes color when depth and color are enabled together before streaming starts, what the black patches mean, and how to tell a configuration problem from a host that never delivers color frames.

Why there is no color device in the list

Most industrial stereo 3D cameras pair two monochrome infrared imagers and compute depth from their offset. On models without a discrete RGB sensor, the left imager's capture is routed through an ISP chip inside the camera, which turns that mono feed into the color stream. Other designs pass a separate RGB sensor through the same ISP for adjustment and scaling; either way the ISP sits between the imaging hardware and your software.

That architecture explains three things you see in the viewer. The color stream belongs to the stereo module, so there is no RGB entry in the device list. Its controls sit inside the stereo module group in the options side panel — expand the group beside the depth controls to find them. And the raw imager feed is black and white, because its source is a mono sensor; if you are looking at that feed by mistake, depth camera RGB shows black and white: you are on the IR stream sorts out which stream you have.

Because color shares the imager front end with depth, the viewer treats the two streams as a pair, and color cannot be added to a session that started without it. That single constraint causes most missing-color reports on this camera class.

Four causes, most likely first

Symptom: depth streams normally, but no color appears anywhere — either the control is hard to find or the color panel stays empty. Work through the list in this order.

1. The color checkbox is hidden inside the stereo module group. Expand that group in the side panel; the color stream control lives there, not at the top level beside the module list.
2. Depth and color were enabled only after streaming had already started. The viewer cannot join color to a running point cloud on these cameras, so the fused view silently stays untextured.
3. You are judging from the 3D view alone. Switch to the 2D option: if color renders there, the stream works and the point-cloud problem is enable order.
4. Color enumerates but no frames arrive. The device lists color support, yet the panel stays empty even in 2D — that points to the host platform, covered in the platform section below.

The mirror failure — color present but depth missing on a stereo camera — has a different cause list, and stereo camera works for RGB but no depth: fix missing mono sensors walks through that one. Causes 1 to 3 are settled at the bench in under a minute; cause 4 is a platform decision.

Fix: enable depth and color, then start streaming

1. Stop streaming: switch the stereo module off in the viewer.
2. Expand the stereo module group in the options side panel.
3. Tick the color stream control and leave depth enabled — both on, neither added later.
4. Start streaming again, so both streams begin together.
5. Open the 3D point cloud: textured surfaces confirm the fix.
6. Cross-check the 2D option, which renders the color image on its own.

Worked case: Ubuntu 20.04, SDK 2.54.1, depth-only point cloud

Inputs, as the case arrives at the bench: a stereo depth camera with ISP-derived color on firmware 5.15.0.2, a PC running Ubuntu 20.04 (kernel 5.15.0-76-generic), and SDK 2.54.1 built from source. The viewer shows only the depth channel, and there is no RGB entry in the device list. Each input comes from the camera class and the reported environment; nothing else is assumed.

The rule on this camera class: the 3D point cloud renders color only when depth and color were both enabled before the stereo module started streaming, and the absent RGB entry is normal, because color is a stream of the stereo module rather than a device of its own.

Applying it: expanding the stereo module group reveals an unticked color control. Streaming is stopped, depth and color are enabled together, streaming restarts. The 2D view renders color at once, and the restarted point cloud comes up textured.

The decision has a clean threshold. Color present in 2D but absent from a freshly restarted point cloud means enable order was the fault — enable both before starting, every time. Color still empty in 2D, while the SDK's enumerate-devices tool lists color support, means the frames never reach the host — move to the platform checks below.

Black patches are missing depth, not missing color

Even with color correctly enabled, patches of the point cloud can stay black. Each pixel in the fused cloud needs a depth value before its color can be placed in 3D. Where the stereo matcher finds no valid correspondence, the pixel has no position, so its color has nowhere to go — the patch reads as black, and the same pixels drop out of any depth math.

Causes, in order of how often each explains a patch: a surface too featureless to match, such as flat untextured plastic or machined metal; distance outside the camera's depth range; occlusion, where one imager cannot see the region; and glossy or light-absorbing material.

The fixes move the measurement, not the color pipeline. Give the matcher texture to work with, by roughening the surface or by choosing a camera that projects its own pattern. Keep the working distance inside the camera's depth range. And mask the unmeasured pixels deliberately instead of averaging them in: 3D camera confidence image values: decode bitflags and mask bad pixels decodes the confidence flags, and segmentation mask average depth: select valid object pixels shows the valid-pixel selection that keeps zeros out of an average. Exposure is the remaining lever, set on the depth camera itself even with no RGB sensor, as set color exposure on a depth camera with no RGB sensor walks through.

Color listed but no frames arrive

On single-board Linux computers the story changes. The SDK installs cleanly, the enumerate-devices tool lists color support, both controls are ticked before streaming — and the color panel still receives no frames while depth runs fine. The usual cause is a board outside the camera vendor's supported platform list: the board's native USB camera stack claims part of the device, so the color endpoint never opens.

Building the SDK with its USB video-class back-end enabled (the libuvc route on Linux) restores basic depth and color streaming on many such boards, at a real cost: no depth-to-color alignment, no IMU data and no post-processing filters. Depth to color alignment breaks up: match stream resolution first explains what alignment does when it is present. The language wrappers, including the Python bindings, may also fail to detect the camera on these boards.

The decision: treat a single-board build as bench work. A production cell runs the camera on a supported host — an x86 controller in most cells — and vision controllers are built for exactly this, with interfaces rated for sustained camera loads.

Checks before you order the next 3D camera

Read one line of the data sheet before anything else: whether color comes from a discrete RGB sensor or is derived from the stereo imager through the ISP. Both deliver color registered to depth; they differ in whether color behaves as an independent stream you can start, stop and expose on its own — the property the whole workflow above depends on.

• Confirm the color-source line, so nobody hunts for a device that was never there.
• Check the depth range against your real part distance, so the matcher never starves.
• Freeze the host only after the camera is on a platform from the vendor's supported list.
• Plan the pipeline around the confidence map, so unmeasured pixels are masked, not averaged.

If untextured parts are what punch holes in depth maps, favor a camera that supplies its own pattern. Both classes sit in the 3D sensors range: the MV-DPS200P-02 is a projected structured-light 3D camera, and the MV-DLS300P-04 pairs stereo with a galvanometer-scanned laser.

The decision, and where to go next

Two minutes at the bench settles most of it: stop, enable both streams, restart, then judge in the 2D view. If color still refuses to appear after that, write from the contact page with the camera model, host and SDK build, and we will work the platform path with you. To plan a new cell around these cameras instead, the configurator below starts at the camera step, and the 3D guides on the topic page cover the surrounding set-up work.