Full resolution capture while showing a low res preview

A live preview streamed at the sensor's full resolution slows the station for no gain: a 1920 × 1080 window cannot show a 4000 × 3000 frame at 1:1, so the screen throws most of the data away while the link carries almost 6× more than the operator ever sees. The fix is to decouple the two resolutions. Run the preview from the camera's binning or decimation settings at a size the window can show, and take the full-resolution frame only when a trigger or a command asks for it. This guide sizes both streams with bandwidth arithmetic you can copy, compares the three patterns that work on GigE and USB3 cameras, walks through the setup steps, and ends with the checks that keep full frames landing on the line.

Why a full-resolution preview costs you

Display pixels you cannot show. A 1920 × 1080 monitor shows 2.07 MP at 1:1. A 4000 × 3000 sensor delivers 12 MP per frame, so about 83% of the streamed pixels never reach the operator's eye; they only pass through the downscaler.

Link bandwidth you probably need elsewhere. At 8 bits per pixel the full stream runs 360 MB/s — 90% of a USB3 link's usable payload and more than three times what a GigE link moves. That leaves little room for a second copy of the image, however small the preview should be.

A frame-rate ceiling you never benefit from. Sensor readout time scales with the pixels read. Cut the preview to a quarter of the width and height and the camera can often double or quadruple its preview frame rate at a lower link load — see how 4×4 and 2×2 binning change frame rate.

Fine focus still needs a full frame. A decimated or binned preview shows composition and coarse focus. Confirm fine focus on a captured frame viewed at 100% zoom, where every sensor pixel is its own display pixel.

Three patterns for decoupling preview from capture

Pick the pattern before you pick parts; the arithmetic that ranks them follows in the next section.

Pattern A is the default. It works on any camera whose feature tree exposes binning, decimation, width and height — standard GenICam features on nearly every industrial area scan camera — and the preview never competes with the capture for bandwidth because the two never run at the same time.

Pattern B needs the camera to expose a second stream channel or an onboard preview mode. Check the feature list before you design around it; many GigE and USB3 models expose exactly one stream.

Pattern C is right when you record or inspect every frame at full rate anyway. The link carries one stream and the display copy is made host-side: no reconfiguration, maximum bandwidth.

Worked example: 12 MP USB3 camera with a 640 × 480 preview

Inputs, and where each comes from:

• Stream spec (data sheet): 4000 × 3000 pixels, 30 frames per second, USB3 — the LS-CMR-0166.
• Pixel format (assumption): Mono 8, 1 byte per pixel; a 16-bit format doubles every byte count below.
• Preview design (this guide's target): 4×4 binning gives 1000 × 750, a 4:3 image that over-covers a 640 × 480 window.
• Interface ceilings (interface standards, bulk streaming): USB3 ≈ 400 MB/s usable payload, from its 5 Gbit/s line rate after encoding and protocol overhead; GigE ≈ 110 MB/s usable payload from its 1 Gbit/s line. MB means 1,000,000 bytes.
• Planning rule: a single stream must fit the usable rate, and capture plus preview together must stay within 80% of it, leaving room for retries and packet gaps.

The camera behind the example's stream spec:

Capture stream. 4000 × 3000 px × 1 byte = 12,000,000 bytes = 12 MB per frame. At 30 fps that is 12 × 30 = 360 MB/s, or 2.88 Gbit/s of payload.

Preview stream. 4×4 binning gives (4000 ÷ 4) × (3000 ÷ 4) = 1000 × 750 px, so 750,000 bytes = 0.75 MB per frame. At 30 fps that is 0.75 × 30 = 22.5 MB/s. A 2×2 binned preview would be four times larger: 3 MB per frame, 90 MB/s at 30 fps.

Results and decisions:

• Preview alone loads 22.5 ÷ 400 = 5.6% of a USB3 link, or 22.5 ÷ 110 = 20% of a GigE link. A binned preview always fits.
• Capture alone: 360 ÷ 400 = 90% of USB3. A single full-rate stream fits — which is what a printed 30 fps over USB3 means in practice.
• Both at once: 360 + 22.5 = 382.5 MB/s, or 96% of USB3. That fails the 80% rule, so two concurrent streams do not fit at full capture rate.
• To make Pattern B fit, solve the rule for the capture rate: (0.8 × 400 − 22.5) ÷ 12 MB per frame = 24.8 fps. Cap the full-resolution stream at about 24 fps and both streams fit USB3 with margin.

Decisions for this sensor:

1. Build Pattern A: preview binned to 1000 × 750 at 22.5 MB/s, capture full frames on trigger, switch the feature set between modes.
2. The bandwidth cost of one full frame after the preview stops is 12 ÷ 400 MB/s ≈ 30 ms — negligible. The real cost of Pattern A is the switch itself: budget 0.1–0.5 s with the preview blanking, and replace that planning number with a measured value from your camera.
3. Do not plan two concurrent streams for this sensor at full rate on USB3, and not at all on GigE: on GigE, 12 MB × 9 fps = 108 MB/s is already 98% of the usable link, leaving about 2 MB/s.

Set up the binned preview and the full-resolution capture

1. Open the camera's feature tree and locate the image-format block: width, height, and the horizontal and vertical binning and decimation controls. These are standard GenICam features on nearly every industrial area scan camera, so the same pattern ports between SDKs.
2. Choose binning on mono sensors: each preview pixel sums a 4×4 charge block, so the small image is brighter and cleaner per pixel than a skipped one. Choose decimation on color sensors unless you know how the camera merges Bayer colors — averaging pixels of unlike filters falsifies preview colors. How quad-cell color sensors handle binning shows what color sensors do to pixels when you bin.
3. Size the preview to the display window, not to the sensor. A 640 × 480 window needs a 640 × 480 stream; the 1000 × 750 binned image over-covers it and leaves room for overlays. Do not ship more preview pixels than the window shows.
4. Raise the preview frame rate. The binned readout moves 16× fewer pixels per frame, so set the preview rate to 30–60 fps and read back the camera's reported frame rate to confirm the sensor keeps up.
5. Define the capture feature set once: binning and decimation off, full width and height, trigger source armed. Industrial camera trigger modes compared, free run to PTP scheduled lists the trigger options and their latency behavior.
6. Write the mode switch as stop, set, start: the preview set is 4×4 binning at 1000 × 750; the capture set is 1×1 at 4000 × 3000. Most SDKs apply width, height and binning at stream start without a device reconnect — the details are in switching a GigE camera's resolution without reconnecting and applying camera settings while streaming without stalling capture.
7. Rebind the display pipeline after every switch. A stream restart can orphan a preview window that was drawn from the old stream; restarting a live camera preview without reopening the device covers the rebind.
8. Size host buffers for the large frames, not the small ones: a capture frame is 12 MB against 0.75 MB for preview, and buffers tuned to the preview will drop full frames mid-cycle. The host-side failure mode is in raising the host USB buffer for full-resolution USB3 streams.
9. Log every frame's byte size and timestamp in both modes. The log is your proof: preview frames at 0.75 MB, capture frames at 12 MB, and switch durations you can subtract from the cycle budget.

Verify before it goes on the line

Trigger 20 full captures in a row and check each frame: 4000 × 3000, not 1000 × 750 — binning left enabled is the classic silent failure. Confirm no dropped frames and a steady trigger-to-frame latency.

Measure the switch by timestamping the stop and the first full frame. Put the measured value in the cycle budget instead of the 0.1–0.5 s planning range.

If capture and preview ever overlap in your cycle, the margin equation from the example decides it: 382.5 MB/s of combined load against 400 MB/s usable fails the 80% rule; a capture capped at 24 fps passes.

Compare the two catalog versions of this sensor:

All 2 share: Sensor size 1/1.7". Values as printed in each product's data sheet; open a part for its drawing and full specifications.

The GigE model's 9 fps is the readout that fits a GigE link at full resolution. The arithmetic: 12 MB × 9 = 108 MB/s against about 110 MB/s usable, which is why the rate is 9 and not 30.

Common mistakes

• Switching width, height or binning while the acquisition runs. Stop the acquisition first; stop, set, start is the safe sequence on every camera.
• Binning left enabled during capture. The inspection then runs on 1000 × 750 frames in which features closer than about 4 px merge into one.
• Color binning without checking the Bayer merge. Preview colors shift or smear; decimation keeps each preview pixel a true sensor pixel.
• Host buffers sized for the preview stream. Full frames arrive after the switch and drop.
• Designing Pattern B on a camera that exposes one stream. Read the feature list before the architecture is drawn.
• Judging link load by frame rate alone. 22.5 MB/s and 360 MB/s are both 30 fps — always multiply by bytes per frame.

Cameras for a split-resolution station

Pattern A works with any area scan camera that exposes binning and decimation, so choose the sensor and interface from the example's arithmetic. When the inspection itself can live on the camera, the question shrinks: smart cameras run the acquisition on the device and show their own setup view, so nothing is streamed to a PC for display. The smart cameras category starts there; the area scan cameras category covers the full-resolution capture side.

Two smart cameras that run the inspection on the device:

To spec the rest — lens, lighting, controller — start at the camera step of the configurator or browse the camera finder. More stream-side fixes, from restarts to buffer sizing, sit on the systems topic page.