Save an image sequence from a frame grabber with a ring buffer

You need a fixed run of frames — 32, 64, a few hundred — captured in one burst and written to disk without a single dropped image. The job turns up whenever you tune a trigger chain, collect training data, or chase an intermittent defect that a single snapshot misses. A frame grabber handles it well: it writes every frame into a ring of host buffers by direct memory access, so the whole burst lands in RAM first and the slower disk write runs after the last frame is in. This guide walks the whole workflow: sizing the ring, grabbing the sequence, saving it losslessly as TIF or RAW, and proving that no frames were dropped. The arithmetic takes five minutes, and the same steps cover Camera Link, CoaXPress and 10GigE grabbers.

How many buffers does the sequence need?

Set the buffer count to exactly the number of frames you want to keep: a 32-frame sequence needs 32 buffers and a 128-frame sequence needs 128, because in sequence mode the grabber fills each buffer once and stops.

In sequence mode the ring is not a recycling loop. Every buffer holds exactly one frame of the run, and when the last buffer fills, acquisition stops until you start it again. That behavior makes the math exact: buffer count and frame count are the same number.

A count set too low is the expensive mistake. Trigger pulses that arrive after every buffer holds a frame have nowhere to land, and those frames vanish without an error in some viewers. A high count leaves buffers empty, which costs nothing but host RAM. Rounding up buys insurance for a few dozen MiB: 40 buffers for a 32-frame run wastes about 38 MiB at 5 MP Mono8 and protects the run against one miscounted trigger.

How much host RAM and disk time does the ring cost?

A 32-frame ring of Mono8 frames at 2448 × 2048 holds 160,432,128 bytes — about 153 MiB of host RAM — and writing it out at a 400 MB/s SATA solid-state-drive rate takes about 0.4 s.

Worked through:

• One frame: 2448 px × 2048 px × 1 B = 5,013,504 B ≈ 4.78 MiB
• The ring: 32 × 5,013,504 B = 160,432,128 B, exactly 153 MiB (160.4 MB)
• With the roughly 10% alignment overhead most drivers add, reserve about 168 MiB of free RAM
• Disk write at 400 MB/s: 160.4 MB / 400 MB/s ≈ 0.40 s; an NVMe drive at 2,000 MB/s finishes in about 0.08 s

RAM sums use MiB (1 MiB = 1,048,576 B) and disk figures use MB (1 MB = 1,000,000 B), matching how each is rated. SATA solid-state drives sustain roughly 400-500 MB/s and NVMe drives several GB/s, so at these sizes the save never gates the next test. Long sequences change that: 512 frames of the same size fill a 2.4 GiB ring, and the save takes about 6.4 s at 400 MB/s.

If the viewer refuses to allocate the pool, RAM is short or the driver's allocation cap is set low. The frame grabber buffer allocation guide shows how to read that error before blaming the camera.

Which frame grabbers support sequence capture?

Any frame grabber whose viewer or SDK exposes a sequence or burst acquisition mode can run this workflow, and the three interface families that cover most lines are Camera Link, CoaXPress and 10GigE — choose by the camera's interface and port count first, frame rate second.

The full range lives in the frame grabbers category, and three cards cover the common cases. The MV-GX1008 is an Octo CXP-6 frame grabber, the choice when several CoaXPress cameras deliver bursts into one host. The MV-GC1102IOL is a Camera Link frame grabber, the classic single-camera path. The MV-GT1102P is a Dual 10GigE frame grabber for cameras whose streams a plain network card would struggle to hold.

All 3 share: Client software MVS. Values as printed in each product's data sheet; open a part for its drawing and full specifications.

For what happens frame by frame inside the acquisition path, the frame grabber image acquisition guide for Camera Link and CoaXPress is the companion read. The frame grabber finder filters every card by interface and port count while you are still choosing.

How do you set the buffer count and grab the burst?

Load the grabber's acquisition configuration for your camera, switch the acquisition mode from continuous to sequence — some viewers call it burst or multi-frame — set the buffer count, and one start command takes the whole run.

Every viewer arranges these controls differently, so the steps name what each control does rather than where it sits:

1. Connect the camera, open the grabber's viewer, and load the acquisition configuration that matches the camera's tap format and pixel format.
2. Select the direct-memory-access channel — the DMA — that the camera is wired to; multi-port cards expose one channel per connector.
3. Find the buffer setting, normally beside the acquisition mode, and set the count to the number of frames you want. Confirm the reported per-buffer size equals width × height × bytes per pixel.
4. Set exposure, gain and trigger source. For an externally timed burst, arm the hardware trigger and feed one pulse per frame.
5. Switch the acquisition mode from continuous to sequence or multi-frame.
6. Start the sequence once and watch the frame counter climb to your number and stop.
7. Save the sequence straight to a fresh folder as TIF or RAW; the next section picks between them.
8. Open frames 1, the middle frame and the last frame to confirm content and exposure before you change anything.

If a triggered run stops after a single frame, the acquisition mode is still one-shot. The hardware trigger stops after one frame guide walks the fix.

Do you save the sequence as TIF or RAW?

Save TIF when every frame must open anywhere with its dimensions and pixel format intact, and save RAW only when you will reload it with the same viewer or parse it yourself — RAW writes faster, but it is not an interchange format.

TIF is lossless: the pixels in the file are the pixels the sensor delivered, wrapped in a header that records width, height, bit depth and line stride. RAW is the same buffer written straight to disk with the header omitted, so it is smaller by the header's worth and faster by the header work.

Before you parse RAW yourself, check the line stride. Some drivers pad each line to an alignment boundary, so the step between rows can run wider than width × bytes per pixel; reload with the wrong stride and every image shears diagonally. TIF carries the stride in its header, which is what makes it the safe exchange format.

For training data, customer evidence or anything a colleague must open, save TIF. Save RAW when a script reads the folder directly and you control the stride.

How do you prove that no frames were dropped?

Read the counter, not the picture count: the grabber's frame-count indicator must stop exactly on N, and each saved frame's sequence number must climb 0, 1, 2 and so on to N-1 without a gap.

Buffer counters are built to expose drops. Grabber SDKs conventionally number buffers starting at zero and incrementing per delivered frame, so a skipped number means a frame never reached a buffer — check your grabber's own buffer documentation for the exact counter behavior it prints.

Run three checks in order:

1. The frame-count indicator reads exactly N after the run.
2. The saved filenames show every number from 0 to N-1, in order.
3. For a triggered burst, timestamps show a constant interval between frames; one stretched interval marks a late buffer.

When a check fails, two causes cover most cases: a previous acquisition that never stopped and still holds buffers, or a trigger that fired more pulses than the ring could accept. The busy-buffer stop fix and the repeated-starts fix clear both.

When is a camera-side or code-side save the better route?

For a GigE or USB3 camera there is no frame grabber to size: the network card's receive queue and the SDK's buffer pool in host RAM form the ring, and the same frames × width × height × bytes-per-pixel formula sets how many frames one burst holds.

A GigE stream needs a network card in the host; the MV-GE2002P is a dual-port PoE NIC.

A USB3 camera takes the same route through the host controller: the MV-GU2204 is a quad USB3.0 adaptor.

Script the run when the job outgrows a viewer: filename logic, per-frame metadata, or sequences long enough to need saving while the next frames arrive. The hardware trigger grab loop in Python saves each frame as it lands, the GigE Vision capture over Ethernet guide drives a GigE camera from code, and the no-code route in saving consecutive camera images covers the camera-utility equivalent. When the burst outruns the link for longer than host RAM can absorb, the camera burst capture buffer guide shows how a camera's own memory rides it out.

What do you check before you start the run?

Run the pre-flight in two minutes: free host RAM of at least the ring size plus 10%, disk space for N × frame size on the target drive, a fresh output folder, the acquisition mode set to sequence, and the trigger armed if the burst is externally timed.

Each line below has cost someone a morning:

• Buffer count equals the number of frames the trigger plan fires — extra buffers idle, missing buffers drop frames silently.
• The reported per-buffer size equals width × height × bytes per pixel; at 2448 × 2048 Mono8 that is 5,013,504 B. Any other value means the configuration's pixel format does not match the camera's output.
• Free host RAM covers the ring plus the roughly 10% alignment overhead — about 168 MiB in the example run.
• The target drive holds N × frame size with margin — 160.4 MB for the 32-frame TIF run — and sustains 400 MB/s or more.
• The output folder is empty and the filename pattern carries each frame's number.
• The acquisition mode reads sequence, the previous acquisition is stopped, and the trigger source is armed.

Once the run passes those checks, the sequence on disk is evidence you can act on. To pick the card first, the system configurator starts at the extras step; contact is the route when a camera's tap format will not load; and the systems topic page collects the other acquisition workflows.