Your structured-light 3D sensor keeps handing back a color map from the previous scan: the depth data updates, the RGB does not, and waiting between captures changes nothing. The cause is almost never a caching bug in your code. It is the 2D exposure mode.
In Flash mode the sensor generates the 2D image from the 3D scan data, so the texture only refreshes when a new 3D capture completes. This guide shows you how to confirm the setting in a few minutes, how to choose between the two fixes — switch the 2D exposure mode to Timed, or always run the 3D capture before reading the color map — and how to order your capture calls so the pen you just placed on the table actually appears in the image. It applies to any sensor whose 2D parameters offer a Flash/Timed exposure mode, programmed in C#, C++ or Python.
Why does captureColorMap return the previous scan's RGB data?
Because in Flash 2D exposure mode the color map is generated from the 3D scan data and only updates when a new 3D capture completes; your depth values look current because every scan returns fresh XYZ, while the texture is still the one from the last 3D scan.
The classic reproduction takes two captures. Scan an empty table, place a pen on it, capture again: the point cloud shows the pen immediately, while captureColorMap — and capturePointXYZBGRMap, which fuses the same texture into the point data — returns the bare table, ten seconds later or ten minutes later. Elapsed time is irrelevant because the texture does not age; it simply never re-rasterizes until a new 3D pipeline runs.
If your station also returns stale pick poses, the same family of ordering bugs is usually at work; conveyor vision scene timing: troubleshoot stale pick data walks through that variant.
How to confirm the 2D exposure mode is the cause
Open the parameter set your project actually loads and read the Exposure Mode value in the 2D parameters: if it reads Flash, that is your cause, and one capture proves it — run a 3D capture to completion, request the color map immediately afterwards, and the pen appears.
Check what the runtime imports, not the file you edited last week. A configuration named Default, or one imported wholesale from another project, can carry Flash long after anyone remembers choosing it. Reading the value back from the sensor at startup beats trusting any file.
Work down the likely causes in this order:
| Likelihood | Cause | Test | What the result means |
|---|---|---|---|
| Most likely | 2D Exposure Mode set to Flash | Read the value back at runtime, then run a 3D capture followed by an immediate color read | Color updates right after a completed 3D capture: the mode is the cause |
| Possible | Color requested before the 3D capture finishes, or with no 3D capture in the cycle | Log a timestamp before the 3D call and before the color call | Color timestamp earlier than 3D completion: reorder the calls |
| Rare | A wrapper or SDK object reusing a buffered frame | Recreate the capture object, reconnect, and capture twice in a row | Image advances one scan per fresh object: the buffering is in your wrapper, not the sensor |
How does Flash mode build the 2D image from the 3D scan?
In Flash mode the sensor does not run a separate 2D exposure: the projector fires its structured pattern, the cameras capture, and the texture you get back is generated from that same 3D sequence, so color and depth stay pixel-aligned and the texture exists only when a 3D capture exists.
That is the point of the mode. The Flash texture doubles as the depth-source image for judging 3D exposure: it is what you look at when setting Exposure Multiplier and Exposure Time in the 3D parameters. The consequence for production code is that color brightness tracks the 3D exposure rather than any 2D setting, so a part that scans well can still look flat in RGB.
In Timed mode the sensor takes a real 2D exposure with its own exposure time, which behaves like any area scan camera exposure you already set every day. That single difference is what makes color independent of the 3D pipeline.
It also explains a related observation: a capture can take longer through your program than through the viewer tool, because the viewer always runs the full 3D sequence before it shows a texture and so never displays a stale frame. 3D camera capture time slower in the API than in the viewer breaks that timing down.
Timed exposure or 3D-first capture order: which fix fits your line?
Switch the 2D exposure mode to Timed when your application needs color that is fresh on every request, and keep Flash — with a strict capture-3D-first rule — when color and depth are always consumed together and you want the leanest capture per scan; both fixes remove the staleness.
| Situation | Setting | Why |
|---|---|---|
| Color read on demand between 3D scans: preview, label presence check | Timed | A Timed 2D exposure runs per capture, so the color map refreshes whether or not a 3D scan ran |
| Texture-mapped inspection, color always consumed with the point cloud | Flash, with 3D-first ordering | One sequence per scan; the fused map is pixel-aligned by construction |
| Reading print, labels or codes from the 2D image | Timed | You own the 2D exposure time, so you can set contrast for the print instead of accepting the 3D exposure |
| 3D exposure still being tuned | Flash, for now | The Flash texture is the depth-source image for judging Exposure Multiplier and Exposure Time |
Timed costs one extra 2D exposure plus readout per capture — typically tens of milliseconds at indoor exposure times — and puts the 2D exposure time in your hands: too long and the part overexposes and texture washes out, so shorten the exposure or add light. Flash keeps the capture lean but couples color brightness to the 3D exposure and refreshes color only once per scan. If your cell fires an external strobe, the exposure window doubles as the shutter; depth camera external flash sync: use exposure time as your shutter covers that timing.
How to sequence the capture calls in your code
In Flash mode, any call that returns a texture-bearing map — captureColorMap or capturePointXYZBGRMap — must come after the 3D capture of the same scene has completed, so structure every cycle as one 3D capture followed by the color reads, and never issue a color read on its own.
- At startup, connect, load the parameter group, then read the 2D Exposure Mode back from the sensor and log it. Fail fast if it is not the mode your capture order assumes.
- Per part, trigger one capture and wait for real completion — the completion flag or the blocking call's return, never a fixed sleep.
- Read the depth or point cloud from that capture.
- Read captureColorMap and capturePointXYZBGRMap from the same capture.
- If a between-parts request needs live color, switch the mode to Timed or accept that Flash returns the last scan's texture.
When different parts run different parameter sets — a fine scan for small features, a fast scan for logistics — the rule holds per set, and switching 3D camera capture parameters per part between scans shows how to change sets cleanly. For the wider set of capture-order and parameter traps, the 3D vision topic page collects the guides in one place.
Which 3D sensors pair color with depth in one capture?
Structured-light and speckle-projection sensors are the family that behaves this way: they project a pattern, capture with their cameras, and can hand you depth alone, color alone or a color-fused point map, which is why the texture's exposure mode matters here while a stereo rig exposes its texture directly.
ToF cameras also expose their 2D feed directly, so the stale-texture trap is specific to sensors that can generate the 2D image from the 3D data. Laser profilers take the other approach by design — height and intensity from one synchronous sweep, no separate texture to go stale:
- Type
- Laser profiler
For area-based structured light, you will find the family in the 3D sensors category; the camera finder filters it by type. Two structured-light 3D cameras from the range:
- Type
- Stereo / structured light
- Type
- Stereo / structured light
How to keep a stale 2D image from coming back
Log the exposure mode at startup, refuse to run if it is not the mode your capture order assumes, and add a scene-change check to commissioning — capture twice with an object moved in between and assert the color map changed — so the fault surfaces on the bench, not in production.
A short prevention list for every deployment:
- Read the 2D Exposure Mode back from the sensor at startup and log it; a parameter file imported from another project is how Flash usually sneaks back.
- State the assumed mode in the handover notes: "color assumes Timed" or "color assumes Flash with 3D-first ordering".
- Commissioning test: empty scene, capture, move an object into view, capture again — the color map must show it. One minute on the bench saves a day of remote debugging.
- In Flash mode, assert in code that every texture-bearing read follows a completed 3D capture of the current part.
- In Timed mode, check the 2D exposure on the production part at production speed; over-long exposure bleaches the texture.
- After any viewer or SDK update, re-read the shipped parameter set, because defaults and mode names move between versions.
If an exported map still looks different from what the viewer tool rendered, that is a separate comparison problem: why exported point clouds differ from the viewer render.
For a new cell, pick the sensor and the capture mode together so the color behavior is a decision, not an accident. If you want a second pair of eyes on capture order and exposure settings before commissioning, contact us with the part, the cycle time and the SDK language.
Questions
Does Flash mode make each capture faster than Timed?
Usually yes, by roughly the separate 2D exposure plus its readout — on the order of tens of milliseconds at typical indoor 2D exposure times. That is the trade in one line: Flash buys a leaner capture and a texture that only exists after a 3D scan; Timed spends the extra exposure and returns a color map that is fresh on every request.
Does switching the 2D exposure mode to Timed change depth quality?
No. The setting lives in the 2D parameters and changes only how the texture is taken; depth still comes from the projected pattern and the camera pair. Run one capture of a known part after the switch anyway and compare depth with your reference — not because the mode moves depth, but to confirm nothing else in the parameter set changed along with it.
Can one parameter set use Flash and another use Timed on the same sensor?
Yes, as long as your SDK switches capture parameter sets between scans: put the 2D exposure mode inside each set, so a fine-scan set keeps Flash for fused maps while a fast set uses Timed for live color. Read the mode back after every switch, because a set that loads without the expected mode reintroduces the stale image silently.
Can you keep Flash mode and still get a live color image between scans?
No. The texture is a product of the 3D capture, so between scans there is nothing new to return; the freshest color available is the last scan's texture. If you need live color between scans, switch the 2D exposure mode to Timed, or trigger an extra capture in a faster parameter set each time and pay its scan time.
What should you check first if color is current but washed out after switching to Timed?
The 2D exposure time. In Timed mode you own it, and too long an exposure overexposes the part until texture disappears. Shorten the 2D exposure until highlights recover, or add light if the part is dark, and judge the result on the production part at production speed rather than on a bench sample.