Trigger a full resolution still from an on-device detection

A detector runs happily on a small image, but the image you archive has to stand on its own: an auditor, a customer complaint or a retraining run wants the sensor's full resolution, not the detector's downscaled input. The trap most teams hit first is trying to switch the sensor to full resolution when something is found. Sensors do not change resolution between frames, so the switch never comes.

The working pattern is different: run the sensor at full resolution from the first frame, downscale a copy for on-device detection, and gate the full-resolution branch on each detection, matched frame for frame. This guide gives you the numbers to size both branches, the sequence-number rule that keeps detection and still on the same scene, the tracker setting that stops duplicate saves, and the bandwidth arithmetic that decides whether one GigE link carries your line.

Can a camera switch to full resolution when a detection fires?

No — sensor resolution is fixed when the pipeline starts and cannot be changed per frame, so the working pattern is to run the sensor at full resolution from frame one, produce a downscaled copy for detection, and save the untouched frame only when the detector fires.

Resolution mode, exposure and gain are acquisition settings, applied before frames flow; a capture request can only hand back the next frame in the mode already running. That constraint sets the design rather than blocking it. The full-resolution readout runs from startup and sets the frame-rate ceiling, and the detector never needs those pixels anyway — it needs the copy. The same split serves display, which the guide on full-resolution capture while showing a low-res preview covers; here the second branch is the archive still.

How do you build the two-branch pipeline?

You split the frame stream at the camera: one branch downscales every frame to the detector's input size, the other holds full-resolution frames in a short buffer, and a gate writes one buffered frame per detection — four buffered frames is about 48 MB of 12 MP mono.

Build it in this order:

1. Configure the sensor at start-up: full resolution, working exposure, working gain. Everything downstream inherits the mode.
2. Add a downscale stage on a copy of the frame stream and reduce it to the detector's input width — 640 pixels in the worked example below. The detector never sees the full frame.
3. Run the detection model on the downscaled copy, and make every result message carry the source frame's sequence number and its box.
4. Hold a ring buffer of recent full-resolution frames at the sink. Size it from the measured pipeline delay plus one frame; four frames covers a two-frame delay with margin.
5. On each detection, write the buffered frame whose sequence number matches. If no frame matches, log the detection as dropped. Never substitute the next frame.
6. Run an object tracker on the detections and gate the write on each unique track ID, so one part produces one still.
7. Fire the light strobe on the capture trigger so every saved still is lit the same way; machine vision trigger timing puts camera, light and reject gate in the right order.

How many pixels do you keep on each branch?

Size the detector branch at three pixels across the smallest defect you must catch, then keep everything else on the still: a 300 mm field of view and a 2 mm defect need 450 detector pixels across, which a 640-pixel-wide input covers with margin.

Work the example. The still branch is a 12 MP sensor at 4000 × 3000, so 4000 ÷ 300 = 13.3 px/mm across a 300 mm field of view. The detector branch downscales to 640 pixels: 640 ÷ 300 = 2.1 px/mm, or 0.47 mm per detector pixel. At three pixels per feature the detection floor is 3 × 0.47 ≈ 1.4 mm. A 2 mm burr spans 2 ÷ 0.47 ≈ 4 detector pixels, comfortably detectable; a 1 mm scratch spans about 2 and sits on the edge. On the still branch the same burr spans 2 × 13.3 ≈ 27 pixels, enough to measure width and profile. Detection happens on the coarse branch; the still proves what the detector saw.

Check your own field of view against the detector width before you fix the input size.

Decision: keep the full sensor for the still, size the detector input at 3 pixels per smallest defect, and treat 1.4 mm as the detection floor in this example — smaller defects need a narrower field of view or a wider detector input.

How do you keep the still matched to the frame the detector saw?

Stamp every frame with an incrementing sequence number at capture, send that number with each detection, and save the still whose number equals it — on a belt moving 200 mm/s at 20 fps, a one-frame error puts the still 10 mm away from the detection.

Sequence numbers make the match mechanical. Stamp each frame where it is captured, before any queue, and carry the number through every derived message: the detection box, the tracker output, the still. The sink writes the frame whose number equals the detection's, so no timestamp guessing enters the archive. The detection result lands one or two frames after capture, because inference consumes part of the frame period; that delay is what the buffer absorbs.

If the camera cannot buffer and must capture on demand, budget that 10 mm per frame or slow the belt through the inspection window. The buffer is the clean fix: the matched frame leaves at write time, and lag leaves the archive with it.

How do you save one still per part instead of one per detection?

Run a tracker on the detections and save only the first frame of each unique track ID: a part that sits in view for 500 ms at 20 fps triggers about 10 detections, and the tracker cuts that to a single 12 MB still per part.

Without the tracker you write ten near-identical images per part. An object tracker assigns one ID per part and holds it across frames, so the gate opens once. When one shot holds several parts, the same IDs let you write one still per part from a single frame; multiple object detection in one snapshot scales that to a full tray.

The stills are real data. A 12 MP mono frame is 4000 × 3000 = 12,000,000 pixels at one byte each: 12 MB, or 36 MB in color. At one part per second the archive grows at 12 MB × 3600 = 43 GB per hour.

The link carries only gated stills, and that is what makes the transfer fit. GigE moves 1000 ÷ 8 = 125 MB/s at the physical layer, roughly 110 MB/s once protocol overhead is paid, so about 110 ÷ 12 ≈ 9 mono stills per second. The untracked ten per second is 120 MB/s and overruns the link.

Can you grab several exposures of the same detection?

Only if the scene holds still for the whole set: three exposures at 20 fps need 150 ms of no motion, and a belt at 200 mm/s travels 30 mm in that time, so multi-exposure belongs at a stop-and-shoot station, not on a moving belt.

Every extra exposure is another frame of the same scene. Put the set where the part dwells: a robot holding the part, an indexing table, a stop gate. Exposure and gain can change between frames without stopping acquisition — changing camera gain at runtime shows the mechanics — but each new setting takes effect on a later frame, the one-frame delay covered in setting exposure every frame. Count the settle frames into the 150 ms.

Decision: on a moving belt, pick the one exposure that serves the decision and save one still. Where the part can dwell, fire the exposure set there on the same trigger chain as the detection.

What hardware runs this pattern?

Two shapes fit: a vision sensor that detects on the device and a controller that stores the stills, or one x86 smart camera doing both; the decider is sustained still rate — one GigE link carries about 9 stills of 12 MB per second.

Shape one splits the work: the sensor runs detection and streams gated stills to a vision controller that buffers, tracks and stores. Shape two keeps everything in one housing: an x86-class smart camera runs the detector, the tracker and the still writer on the same processor, so gated stills never cross a network link. On a moving line, use a global-shutter sensor either way; a rolling shutter smears fast motion across the frame.

Size the sensor for your field of view in the camera finder, then match the shape to your rate. The MV-SC3050XC-16M-ATN-H is a 5 MP color vision sensor with a global shutter and an M12 mount, built for the detect-on-device role in shape one.

The MV-SC6050C-08M-XBN stays in that class and adds an integrated multi-color light source with a fixed 8 mm M12 lens, so illumination rides on the camera instead of a separate light.

The LS-SMC-0017 is shape two in one unit: an x86 platform carrying an 8.8 MP global-shutter sensor in 1" format behind a C-mount, with detector, tracker and still writer on the same processor.

The MV-VC5525-256G70-NN takes the sink role in shape one: 32 GB of memory, a 256 GB SSD, PoE camera ports and 8 built-in light channels for the strobes.

A 256 GB drive holds 256,000 MB ÷ 12 MB ≈ 21,000 mono stills, nearly six hours at one still per second, so plan archive rotation to a server as part of the design.

How do you verify the pairs before go-live?

Run three tests with the line stopped and then running: a step test that moves the part one frame's worth of travel between captures, a sequence-number continuity log that exposes dropped frames, and a one-hour audit that compares track IDs counted against stills saved, which must match one to one.

• Step test. Stop the line, place the part, run one cycle. Then move the part 10 mm — one frame of travel in the example — and run again. Each archive still must show the part where the detection box said. A still showing it 10 mm downstream means the sink is writing the following frame.
• Sequence audit. Log every sequence number the sink receives for an hour. Gaps are dropped frames; count detections fired against stills written and account for every difference.
• Tracker audit. Tracks created must equal stills written over a full shift. A mismatch means a track died before its still landed; widen the buffer or write on track confirmation instead of first sight.
• Timing check. Measure the capture-to-result delay at the frame counter, not with a stopwatch; measuring frame trigger wait time shows the method, and the buffer must exceed the measured delay.
• Headroom. Keep sustained link use under about 70% of the 110 MB/s the link really delivers: roughly 6 stills of 12 MB per second in this example.

The costliest mistake is testing only on a stopped line; every timing error above stays hidden until the part moves.

When should you not gate stills on detections?

Skip the gate when the defect is smaller than one or two detector pixels — no gating recovers a feature the detector never saw — or when nearly every frame needs saving, because 20 stills of 12 MB per second is 240 MB/s and overruns any single GigE link.

Feature size is a geometry problem. For a 640-pixel detector branch and 1 mm features, the largest field of view that keeps 3 pixels on the feature is 640 × 1 ÷ 3 ≈ 213 mm; a 300 mm field of view cannot see a 1 mm defect at this input width. Shrink the field of view, or grow the detector input and pay for it in inference time.

Keeping nearly every frame fails on bandwidth before it fails on disk: 240 MB/s has no headroom on GigE, so record full-resolution frames at a lower frame rate, or keep the pipeline on one device so the frames never cross a link at all.

On a static station where the part always stops, a plain hardware trigger with a fixed exposure does the whole job — the buffer, tracker and sequence machinery are overhead you can leave out.

Commit before you order: full resolution from frame one, detector input at 3 pixels per smallest defect, sequence-number matching, one still per track ID, and a link budget of about 9 stills of 12 MB per second on GigE. Work through the system configurator to match sensor, lens and light to your line, and if your numbers do not fit these shapes, the contact page reaches the applications team. More patterns like this sit on the systems topic page.