Split one camera image into multiple ROIs and display each

Three windows on the host screen, each showing its own third of one camera view: the intent is simple, yet the first attempt usually puts the same picture in every window or crashes the program. The camera is not struggling to serve several regions at once. The failures come from reading the live acquisition twice and from rectangle coordinates read in the wrong order. This how-to gives you the working pattern — acquire each frame into one buffer you own, copy every region of interest (ROI) into its own display buffer, and drive one window per ROI — with the memory and bandwidth arithmetic for a 4000 × 3000 example, so you can size the host before ordering parts.

Why both windows show the same picture

The symptom has three causes, and any one of them produces it. Check them in this order.

A shared source. A running acquisition holds one latest frame. Every extraction that reads from the live acquisition pulls that same frame, so window two receives exactly what window one received. Both reads point at one image and the camera is doing nothing wrong.

A mixed-up rectangle. ROI rectangles come in two coordinate styles — left, top, right and bottom corners, or left, top plus width and height — and that is the only place where the conventions matter, so read the rectangle section of your copy function once. Supply a width where a right-hand corner belongs and the second rectangle collapses or lands over the first, which again reads as the same picture in both windows.

Buffer lifetime. Many SDKs reuse one capture buffer for the next frame. A window that draws straight from that memory tears or crashes once the driver reclaims it mid-redraw.

One architecture fixes all three: a persistent acquisition buffer you own and one display buffer per window. Copying the frame out of the SDK buffer before anything else touches it is the same ownership rule that ends corrupted stereo saves, set out in Stereo frames saved wrong: copy Mat data from the SDK buffer.

What you need

• One area scan camera that delivers the full frame at your display rate: filter the area scan cameras by resolution, sensor format and interface, or go straight to the camera finder.
• A host that owns the buffers and the windows. A vision controllers box combines camera LAN ports, built-in light channels and display output in one unit.
• Your SDK's frame-copy and rectangle-copy functions, plus one image display control per region.
• The ROI list in integer pixels, fixed before you write code.

Nothing else: the split is arithmetic on pixels you already have.

The working sequence

1. Define the ROIs once. At start-up, store each region as integers: left, top, right, bottom. Test every one: 0 ≤ left < right ≤ frame width and 0 ≤ top < bottom ≤ frame height. Write a single helper that converts to whatever order your copy function expects.
2. Start acquisition full-frame. Set the sensor to the whole area and fix the pixel format for the run; 8-bit mono moves one byte per pixel, half the traffic of 16-bit.
3. Copy the frame in. On every acquired frame, copy all pixels from the SDK buffer into your persistent acquisition buffer. One copy, allocated once, reused every frame.
4. Copy each ROI out. For each region in turn, copy its rectangle from the acquisition buffer into that window's own display buffer, also allocated once.
5. Hand the buffers to the windows. Each window redraws on its own schedule from the buffer it owns; set size and screen position once at start-up (Control vision display window size and screen position).
6. Loop per frame. Nothing downstream of step 3 ever reads the live acquisition again.

Worked example: split a 4000 × 3000 frame three ways

Take three vertical thirds: one view, three windows. The LS-CMR-0166 delivers a 4000 × 3000 frame at 30 fps over USB3. Work the pipeline in 8-bit mono, one byte per pixel.

4000 pixels split three ways is 1333.33, so the widths run 1333, 1333 and 1334. With corner coordinates:

Memory: the frame is 4000 × 3000 = 12,000,000 bytes, about 12 MB, so the acquisition buffer plus three display buffers total 12 + 3 × 4 ≈ 24 MB. That is about 0.3 % of the 8 GB a small vision controller carries.

Traffic: the arrival copy moves 30 × 12 MB = 360 MB/s and the three ROI copies add 30 × 3 × 4 MB = 360 MB/s, so roughly 720 MB/s of memory traffic in total. The 24 MB moved per frame takes 24 ÷ 4 = 6 ms at a 4 GB/s memory-copy rate, comfortably inside the 33 ms a 30 fps frame allows. The 360 MB/s inbound is also why this camera class speaks USB3 rather than GigE, which tops out near 118 MB/s.

When each third must carry more detail, raise the sensor before you complicate the software. The MV-CS200-10UM is a 20 MP mono USB3.0 camera on a 1" sensor. The same three rectangles on a 20 MP frame hand each window about 6.7 MP, and the frame copy alone moves about 20 MB, or 600 MB/s at 30 fps — check the interface budget before you scale.

Verify the split

Four checks, in order:

• Boundary test. Lay a straight edge across both cut lines and grab one frame. Window two's leftmost column must continue window one's rightmost without repeating it. Decide whether your right and bottom edges are inclusive or exclusive and stay consistent, because a one-pixel slip duplicates or drops a boundary column.
• Difference test. Block two of the three thirds, or hold a different target in each, and confirm the windows diverge. If all three still update in lockstep with identical content, a copy is still reading the shared source.
• Timing test. Log the copies from steps 3 and 4. Single-digit milliseconds per frame is right at the rates above; tens of milliseconds means a per-frame allocation crept back in.
• Soak test. Run an hour. A crash a few minutes in, with a window frozen mid-frame, points back to a display drawing from the driver's buffer.

Keep each display region no larger than the screen needs: the machine vision image display ROI design guide sizes display ROIs so the interface stays responsive.

Common mistakes and their fixes

• Convention converted at every call site. Convert once, in one helper; three call sites guarantee one of them drifts.
• Copy inside the paint event. Move it to frame arrival and let the paint event only draw.
• Buffers allocated per frame. Allocate the acquisition buffer and every display buffer once. Per-frame allocation shows up as millisecond jitter in the timing log.
• Extraction calls from a camera callback. Two re-entrant reads of one session collide. Keep callbacks short and queue one copy per frame; the freeze pattern is described in Multi-camera acquisition freezes: callbacks and buffer queues.
• A tool bound to the wrong image source. When the fault appears in one window only, check which buffer each tool actually reads; the binding faults behind region errors are set out in ROI image source binding: fix inspection region errors.
• Annotations drawn into pixels. Draw overlays in the display layer; Text overlay on a live camera image without altering the frame shows the pattern.

When to shrink the camera ROI instead

If the screen needs one narrow strip — a web, a ramp, a seal line — set the sensor ROI to that strip instead of copying. Inbound data falls in proportion to the pixel count and the frame rate rises. One acquisition still yields one image, though, so three independent windows from one view remain a host-side copy job. What a partial readout buys in frames per second is worked through in Multi ROI camera capture: the frame rate arithmetic. If the destination is a PLC-side screen rather than your own interface, what displays live changes again, as Smart camera image in a PLC HMI: what actually displays live explains.

Parts for a three-window station

Decide by pixels per window and by where the windows run.

• Modest windows from one USB3 view: the LS-CMR-0166 above covers it end to end.
• More detail per window: the MV-CS200-10UM roughly triples the pixels each region carries, still over USB3.0.
• The machine that acquires, copies and displays: the MV-VC2140-128G40-1T pairs 8 GB of memory with a 128 GB SSD and a 1 TB HDD, 3-4 LAN ports, two USB 3 ports and four built-in light channels for per-frame strobing. The 24 MB of buffers in this example sit well inside 8 GB of RAM.

That is the whole decision: one acquisition buffer, one display buffer per window, rectangles in corner coordinates, copies on frame arrival. Configure the camera side from the call-out below, and if your layout spans several cameras or an HMI, describe the region sizes and frame rate through the contact page and we will size the host with you. More acquisition and display guides sit on the systems topic page.