RGB only in point cloud view: why the screen is blank and the fix

You switch on the color camera of a depth camera, and the 3D window shows nothing at all. The camera and the color sensor are fine: the 3D pane is a point cloud, a point cloud is computed from the depth stream, and a color stream on its own carries no distance values to draw. This guide explains why the RGB stream sits blank in a point cloud view, why the display fragments once depth has been switched off again, how the viewer builds a colored cloud from depth plus RGB, and which of the two fixes — enabling depth or clicking the 2D view — fits the check you are making.

Why does the point cloud go blank when only the RGB camera is enabled?

The 3D display is a point cloud, and a point cloud is drawn from the depth stream; an RGB frame carries color but no distance, so with depth off the renderer has no X, Y and Z coordinates to plot and leaves the view empty.

A color image is a flat grid of pixels: each pixel knows its place in the picture, and nothing about its place in the world. The viewer's 3D pane plots geometry, so it waits for depth frames you have not asked the camera to send. Streaming RGB alone harms nothing — the camera delivers exactly what you requested, into a display that cannot use it. A blank 3D pane with RGB running is the normal behavior of a depth-camera viewer in point cloud mode, not a fault in the camera, the driver or the link.

Why does the picture turn fragmented when you switch the depth stream back off?

You are seeing leftovers: the viewer keeps the last point cloud it computed while depth was running, so the screen holds fragments of geometry from those frames, with holes wherever the depth map had invalid pixels, while fresh RGB frames arrive that have no geometry to attach to.

The cloud is rebuilt for every frame set in which depth takes part. Switch depth off and the geometry pipeline stops receiving input, so the residue of the last computed clouds freezes or fades as the renderer recycles its buffers. The holes sit where no depth value existed — out of range, too dark, or occluded — the same pixels that form the invalid band at the edges of stereo depth images.

How do you get the RGB image to display properly?

Two paths work: click the viewer's 2D display option to watch the RGB stream as a plain image, or enable the depth and stereo streams so the 3D view has geometry and can wrap the RGB data onto it as a colored point cloud.

Pick by what you are checking. Use the 2D view when you are setting exposure, white balance, focus or framing on the color image: the RGB imager streams on its own and needs nothing else. Use the textured 3D cloud when color and geometry must line up — color-to-depth alignment for robot guidance, volume records, or a scene record for a colleague.

Expect one trim: on stereo cameras the depth image covers less of the scene than the RGB image, so the outer margin of the color picture has no geometry to land on and the textured cloud looks cut in — why stereo depth coverage is smaller than the RGB view.

Where is the 2D and 3D switch in a depth camera's viewer?

Look at the top corner of the viewer window: depth-camera viewers keep a small 2D/3D display toggle there, where 2D lays each enabled stream out as a flat image and 3D draws the point cloud, so one click moves you between them.

The label changes with the SDK — 2D, image view or stream panels on one side, 3D, point cloud or scene on the other — but the split is always the same: 2D shows the raw streams, 3D shows computed geometry. With depth and RGB both enabled, the 3D pane textures the cloud by itself; you never ask for the mapping separately. Each stream keeps its own 2D panel too, which is the fastest place to confirm a stream is alive before you hunt for deeper causes.

How is a colored point cloud built from depth and RGB?

The viewer unprojects every valid depth pixel to a 3D point with the factory calibration, then maps the registered RGB frame onto those points, so each point carries X, Y and Z plus its color — and without the depth step there is no point to color.

fx and fy are the focal lengths in pixels and cx, cy the principal point, all read from the camera's factory calibration. The RGB frame is projected onto the depth pixel grid with the factory extrinsics; that is the registration step, the same one you follow when registering RGB and depth images for a colored point cloud. Depth pixels with no valid value are dropped before unprojection, which is where the holes come from — and if you build clouds in your own code, turning a NumPy depth image into a point cloud runs into the identical rule.

Do laser profilers, structured-light cameras and ToF sensors work the same way?

Yes, every depth-producing sensor builds its 3D display from a depth or profile stream, so the same rule holds: with no depth stream enabled there is nothing to plot, and an RGB or intensity image alone belongs in the 2D view.

The 3D sensors category splits into laser profilers, stereo and structured-light cameras, ToF cameras and 2.5D inspection systems, and the display rule reaches all of them. A laser profiler triangulates the reflected laser line into one depth profile per scan, so its cloud grows as the part moves; a structured-light stereo camera projects a pattern and computes depth per pixel; a ToF camera times the round trip of its emitted light. Different physics, same viewer logic: geometry from the depth or profile stream, intensity or color as texture.

One Hikrobot model from each family:

Each family above produces depth or profile data as its geometry source, so the blank-screen rule applies equally: a dark 3D pane means the geometry stream is off, not that the sensor has failed.

When is a blank or broken 3D view a real fault, not a display mode?

If the depth stream itself will not enable, or the cloud stays empty while depth runs and a target sits well inside range, you have a connection, bandwidth or firmware problem — fix the stream first, because no display mode can draw geometry from data that never arrives.

1. Switch to the 2D view and enable streams one at a time. A color image that shows on its own clears the color path, the cable and the driver.
2. Enable the depth and infrared streams. Raw infrared frames that show the scene prove the imagers work; depth that stays blank beside them points at the compute side — check for scene texture and a sane exposure first.
3. Nothing streams at all: try a shorter cable or another port. A camera carrying depth, infrared and color at once fills the bandwidth of its link, and a marginal cable fails exactly here.
4. Depth enables but the cloud never builds: check that SDK and firmware expect the same data layout, as in the header version mismatch between a 3D camera and its SDK, and run the connection checks for a stereo depth camera that fails only on the depth stream.

Next step: if you are specifying hardware rather than debugging a display, compare the sensor families above against your part size and cycle time in the camera finder.