Disable the projector for a 2D live feed: brightness 0.0

You built a live 2D preview into your application around a structured-light 3D camera, and every preview frame fires the projected pattern. The image strobes, the part swims in moving stripes, and the operator sees a flash on every capture. The cause is one property, and so is the fix: in the 2D acquisition settings, brightness is the projector's output level, not image brightness. This guide shows the setting, why color turns to grayscale on projector-centered cameras, how to size the exposure that replaces the projector's light, and when a separate 2D camera is the cleaner answer.

What the brightness property actually controls

A 2D capture in this camera family is configured on one acquisition object — Settings2D.Acquisition in the Python API — with four fields: exposure_time, gain, aperture and brightness. Three behave like any industrial camera: integration time in microseconds, an amplification multiplier, an f-number on the lens. The fourth does not. brightness sets how hard the projector fires during that 2D frame. At 1.0 — the value the sample setup shipped with — the projector fires on every preview frame, so each image is lit by the pattern. At 0.0 the projector stays dark and the sensor sees ambient light, factory lighting, or a machine-vision light you add.

The property is easy to miss because it is named like an image adjustment and sits with three that are. The flash itself is the camera doing its job: a structured-light 3D scanner reconstructs shape by decoding projected patterns. For a live preview you are not measuring — you want photons without the pattern. What that pattern contributes to the depth result is a separate question, covered in projector pixel mapping to 3D points.

Turn the projector off in five steps

1. Build the 2D settings with one acquisition, projector off, and your previous exposure as the starting point:

from datetime import timedelta

# settings_2d: a Settings2D object from your camera's Python SDK
# acq: one Settings2D.Acquisition(), appended below
# camera: your connected 3D camera handle
settings_2d = Settings2D()
acq = Settings2D.Acquisition()
acq.brightness = 0.0                              # float: 0.0 = projector off
acq.exposure_time = timedelta(microseconds=2000)  # timedelta, from the projector-on setup
acq.gain = 1.0                                    # float multiplier
acq.aperture = 5.6                                # f-number
settings_2d.acquisitions.append(acq)

frame_2d = camera.capture_2d(settings_2d)
image = frame_2d.image_rgba_srgb()

2. Keep exposure_time at 2000 µs, gain at 1.0 and aperture at f/5.6 for the first capture — those values worked with the projector, and a later section sizes them for its absence.
3. Capture with camera.capture_2d(settings_2d) inside your GUI loop, one frame per tick.
4. Read the frame as frame_2d.image_rgba_srgb() for the preview widget (Qt, web or native), or the monochrome output when color is unavailable.
5. Read brightness back once after a reconnect, so a settings rebuild has not restored the 1.0 default.

The test that proves it: ten frames of a matte target, none showing stripes, with a steady mean level. If stripes appear, the capture path in use is rebuilding its acquisition with brightness above 0.0.

Color turns to grayscale on projector-centered cameras

On designs where the projector sits at the optical center and is the scene's only illumination, the color pipeline depends on it: with brightness 0.0 the 2D output is grayscale. That is the architecture, not a fault, and no setting recovers RGB from a sensor that received no color illumination. Request the monochrome frame for the preview; the sRGB conversion remaps tone values, it cannot create color that was never captured.

On designs with a separate 2D imager beside the projector, color can survive with the projector dark. Test once with a colored part in view and look at the channels. Industrial 3D camera selection: stereo, ToF or structured light settles which architecture you hold before you write GUI code around the wrong assumption.

Two 3D sensor designs from the catalog frame the split:

The MV-DPS200P-02 is a projected structured-light 3D camera: the projector is the depth engine, so the projector-off question is the first one to test. The MV-DLS300P-04 is a laser galvanometer stereo camera — a different projector geometry, same test.

Size the exposure that replaces the projector

The projector was probably the brightest source in the scene, so the frame that worked at 2000 µs goes dark when it stops. Three levers add real light; one only amplifies.

• Exposure time. Signal scales linearly: double the microseconds, double the signal. Spends frame time.
• Aperture. Light scales with one over the f-number squared: one stop open doubles it. Spends depth of field.
• Added light. A machine-vision light over the part keeps 2000 µs and the frame rate. Spends a fixture.
• Gain. Multiplies signal and noise together. No new photons; use it for the last stop at most.

Measure the loss before choosing a lever: same matte gray target, same 2000 µs, brightness 1.0 then 0.0, and the ratio of mean linear gray levels is the light you lost. Convert to linear before averaging — the sRGB copy applies a gamma curve that inflates the ratio, and the linear RGB versus sRGB walkthrough shows the conversion. Then fix exposure and gain by hand for the preview, or aim auto exposure at a fixed brightness target so the camera does not re-time every projector-off frame.

Worked example: preview at 2000 µs, f/5.6 and 30 fps

Inputs. Exposure time 2000 µs, aperture f/5.6, gain 1.0 — the projector-on settings from the sample setup. Preview target 30 fps, a comfortable live-view rate. Reserve 20% of each frame period for readout and overhead.

Rule. At a fixed frame rate, the exposure ceiling is 0.8 × (1 / frame rate). The light recoverable from time alone is that ceiling divided by the current exposure.

Arithmetic.

• Frame period = 1 / 30 s = 33.3 ms.
• Exposure ceiling = 0.8 × 33.3 ms = 26.7 ms.
• From time alone: 26.7 ms / 2.0 ms = 13.3× = log2(13.3) ≈ 3.7 stops.
• Aperture f/5.6 → f/2.8: (5.6 / 2.8)² = 4× = 2 stops more; total ≈ 5.7 stops.

Result. Exposure buys 3.7 stops at 30 fps, and the lens can add two.

Decision. Take the measured loss from the previous section and commit:

• Up to 3.7 stops: lengthen exposure to 2.0 ms × 2^stops, capped at 26.7 ms. Thirty frames per second holds.
• About 4 stops: 2.0 ms × 4 = 8.0 ms of exposure plus the lens opened from f/5.6 to f/2.8. Gain stays 1.0, and 8.0 ms of a 33.3 ms period leaves 25 ms of margin.
• Lens only reaches f/4: that is one stop, so 2.0 ms × 8 = 16 ms of exposure covers the rest — still inside the ceiling.
• Beyond 5.7 stops: add a machine-vision light. It is the only lever that adds photons without spending frame rate or depth of field.
• Fifteen frames per second acceptable: the ceiling becomes 0.8 × 66.7 ms = 53.3 ms, so time alone buys 53.3 / 2.0 = 26.7× ≈ 4.7 stops.

Verify the fix

• Ten consecutive preview frames of a matte target: no stripes, steady mean level.
• A colored part reads gray on a projector-centered camera — expected there, colored on a design with an independent 2D imager.
• A depth capture right after the preview still fires the projector and returns a cloud: the off state is scoped to the 2D settings.
• Exposure and gain hold fixed values; the preview keeps its level over minutes instead of pumping.

Common mistakes

• Reading brightness as image brightness and leaving 1.0 in place while searching exposure and gain for the flash control. The property is the projector.
• Recovering four stops with gain alone: gain 1.0 → 4.0 restores the gray levels and lifts the noise by the same factor, so dark regions grain over.
• Leaving auto exposure on: each projector-off frame re-times itself and the image pumps. Fix it manually, or turn every auto mode off when the level drifts over a shift.
• Rebuilding the acquisition from defaults on reconnect — the 1.0 returns with it.
• Designing the GUI for RGB on a projector-centered camera. Plan grayscale, or plan a second camera, from the first day.

When a separate 2D camera is the cleaner answer

If the preview must be color, must hold a steady frame rate while 3D captures run, or must view the part from another angle, stop sharing the 3D camera: an area scan camera with its own light runs the preview and leaves depth to the 3D unit. The same trade-off at system level is walked in 2D or 3D camera for conveyor pick and place. For the preview role, the LS-CMR-0166 is a 12 MP USB3 area scan camera running 30 fps at 4000 × 3000 — enough resolution to read markings in the view an operator watches.

When grayscale is acceptable and the frame rate can drop a little, adding hardware is not justified: the preview stays on the 3D camera and the projector stays dark.

Checklist before you ship the preview

• brightness 0.0 in the one constructor every capture path uses, read back after a reconnect.
• Exposure and gain fixed; stops lost measured on linear mean levels.
• Exposure inside the 0.8 × frame-period ceiling from the worked example.
• Grayscale accepted on a projector-centered camera, or a dedicated 2D camera added.
• Depth capture re-tested with the projector firing.
• Laser or LED class precautions posted where 3D captures run.

If the answer is a second camera, size it in the camera finder or the configurator, or bring the measured stops and target frame rate to the contact page and we will pick the 2D path with you.