Text overlay on a live camera image without altering the frame

An operator station needs the measured value on screen — a 560, a diameter, a pass flag — at a size readable across the room, and nobody needs that text inside the images you save and inspect. This guide is for integrators wiring a display into a camera station. You will put the text on a display-plane overlay the camera frame never sees, set the drawing up in six steps, and check the arithmetic that decides the real frame rate: interface bandwidth, frame size and the microseconds the annotation itself costs.

Where does the text live so the camera frame stays untouched?

On an overlay plane in host memory: your program acquires the untouched camera frame into one buffer, composites the text onto a second, display-only plane, and sends only that composite to the screen, so saved and processed pixels never contain the text.

There are exactly two planes to keep apart. The acquisition buffer holds what the sensor delivered, and it is the only thing your inspection code and your file exports touch. The display plane exists only on the screen side: each refresh, your program copies the frame — or the processed frame with your graphics — into it and draws the text on top. Nothing flows back from the display plane into the buffer.

Most GenICam-based acquisition libraries expose this as an overlay, annotation or drawing layer attached to their live-view window. If yours offers only a bitmap you draw yourself, that works identically. The discipline that matters is buffer identity: one variable for camera pixels, one for screen pixels, and no assignment that carries text back upstream.

How do you draw the overlay in your acquisition software?

Draw it on the viewer's overlay layer after processing: acquire into the processing buffer, create an overlay plane the size of the display window, write the value with a text object, and composite once per display refresh.

You need three things: a camera your acquisition library streams from, a host with a live-view window, and an overlay or drawing layer in that library. No camera-side feature and no extra purchase is involved.

1. Split the path in two. Name the acquisition buffer and the display plane as separate objects in your code, and never pass one where the other is expected.
2. Acquire exactly as today. Same exposure, same trigger, same buffer. The overlay changes nothing in this step.
3. Create the overlay plane. Size it to the display window, or to full camera resolution if operators zoom into the picture; a 1920 × 1080 plane covers a workstation monitor.
4. Draw the value. Text object, anchored to a corner, font about one tenth of the plane height so it reads from a metre away. Update it after each processing cycle.
5. Composite on refresh. Copy the frame into the display buffer, draw the overlay on top, once per display refresh. The guide to updating overlay graphics every frame at full preview rate keeps that loop fast.
6. Save from the acquisition buffer only. Screenshots are for the operator, files for the record.

To format the measured value itself — width and height in one string, rounding, units — see how to display region width and height in one string. If the text draws but never appears on the live view, your library probably keeps the overlay and the image in separate buffers and needs the overlay attached to the viewer; the text missing on live overlay images page walks that attach step.

Does drawing the overlay slow the frame rate?

Almost never: a three-digit stamp at 400 × 200 pixels touches 80,000 pixels, composites in about 80 µs, and the frame period at 30 fps is 33.3 ms, so the annotation uses roughly 0.24% of the frame budget.

The arithmetic, assuming a conservative 1 GB/s memory copy speed:

• Stamp area: 400 px × 200 px = 80,000 px = 80 kB at 8 bits per pixel.
• Copy cost: 80 kB ÷ 1 GB/s = 80 µs.
• Frame budget at 30 fps: 1000 ms ÷ 30 = 33.3 ms = 33,300 µs.
• Share of budget: 80 ÷ 33,300 ≈ 0.24%.

Even a full-screen 1920 × 1080 overlay plane is 2,073,600 px ≈ 2 MB, about 2 ms per refresh at the same speed. What decides your frame rate is sensor readout and interface transport, and the interface deserves the real arithmetic.

When the overlay carries boxes and reticles around the text, draw the strokes yourself and keep their width deliberate; machine vision overlay line thickness: draw it yourself shows why default widths mislead.

How many megapixels can the host actually move?

As many as the interface moves: USB3 delivers about 350-400 MB/s of practical payload, so at 12 MB per 12 MP frame that is roughly 29-33 fps, while GigE's ~118 MB/s usable caps the same frames near 10 fps.

Where each number comes from: USB 3.0 runs a 5 Gbit/s line rate, 8b/10b encoding leaves 500 MB/s of payload, and real USB3 Vision streams sustain 350-400 MB/s of it. GigE moves 125 MB/s on the wire, about 118 MB/s usable.

Apply it to 12 MP at 8 bits per pixel (mono or raw Bayer): one frame is 4000 × 3000 = 12,000,000 px = 12 MB. At 30 fps the interface must move 12 × 30 = 360 MB/s. The ceilings: 400 ÷ 12 ≈ 33 fps and 350 ÷ 12 ≈ 29 fps on USB3; 118 ÷ 12 ≈ 9.8 fps on GigE.

The LS-CMR-0166 pairs exactly that stream — 4000 × 3000 pixels at 30 fps — over USB3.

The LS-CMR-0053 runs the same 12 MP IMX226 sensor class over GigE and prints 9 fps. Nine frames of 12 MB is 108 MB/s, essentially GigE's usable ceiling: the interface, not the sensor, set that number. An operator display that refreshes a few times per second is comfortable at 9 fps; pace-critical verification wants USB3 or faster.

The ceiling generalises. A thousand full frames per second needs 1000 × 12 MB = 12,000 MB/s, and even a four-connection CoaXPress-12 link moves roughly 5,000 MB/s of payload, so 1000 fps is a job for a reduced ROI, binning or line scan — not full frames. Adding cameras divides the same budget: a hub or a shared controller port splits the interface's MB/s across every stream, which is why USB hubs dropping camera frame rate are solved by budgeting bandwidth first.

What hardware does overlay plus acquisition take?

A normal host does it: a camera whose interface your computer speaks, a port per camera, and a vision controller with enough memory to hold the frame buffer plus the display plane — even an 8 GB, Core i3-class unit handles that comfortably.

Because the overlay is drawn after acquisition, the camera needs no overlay feature: any model in the area scan cameras range works with whatever interface the host speaks. What the host owes you is a port per camera and memory bandwidth to refresh the display plane, which is trivial next to the acquisition copy.

An Intel Core i3-class vision controller such as the MV-VC3301H-128G66 — 8 GB of memory, 5+ LAN ports, 4 built-in light channels — runs several camera streams and the overlay loop together.

Shortlist cameras by interface and resolution in the cameras finder, then match port count and memory in the vision controllers range, which sorts the same hardware by light outputs too.

How do you check the saved frame is really clean?

Save from the acquisition buffer, never from the screen, then prove it: trigger one frame with the overlay on screen, export, and diff against an overlay-off capture of the same scene — with a display-plane overlay the two files match byte for byte.

Run this four-point check before the station ships:

• Byte-compare on versus off. Export the acquisition buffer with the overlay displayed and again without; identical files confirm the display plane never leaked upstream.
• Inspect the export. Run the full inspection on the saved frame: no phantom text blobs, no OCR hits, because text in the buffer corrupts counting and character reading first.
• Watch the fps counter. Three seconds live with the overlay on, then off: the rate should not move, since nothing in the acquisition path changed.
• Archive both. Export the clean buffer alongside the composited video — one is the inspection record, the other is what the operator saw.

When is burned-in text on the camera the right answer?

Only when the text must survive without your host: a standalone camera feeding a monitor with no PC in the loop, where the camera burns the characters into every frame and you accept that the inspection pipeline sees them too.

Network cameras are the everyday case: their on-screen display is set through an authenticated HTTP interface, and when the login fails the overlay call returns HTTP 401 — the camera overlay call returning HTTP 401 page shows the failure and the fix. Note what you give up: every pixel now contains the text, so measurement, OCR and retraining all see it.

Medical imaging drew the same line: the DICOM standard forbids burned-in annotation in enhanced CT and MR objects, so annotation travels as metadata and the pixels stay clean. Where audits want raw pixels, host-side overlays are the design that survives review.

Why does my overlay vanish or my frame rate drop?

Usually a buffer-identity mistake: your code drew into the processing buffer instead of a display plane, or a screen capture replaced a file export; both disappear when the overlay is composited after acquisition and exports read the acquisition buffer directly.

The three failures, in order of how often they show up:

1. Text in the saved image. You drew on the processing buffer. Fix: move the drawing to a display plane created after acquisition.
2. Overlay invisible on the live view. The overlay object exists but is not attached to the viewer window. Fix: attach it, as in the setup steps above.
3. Frame rate drops when the overlay turns on. Almost always bandwidth, not drawing: another stream joined the same hub or port. Fix: budget the interface per camera and give each stream its own controller port.

The decision in three lines: draw on a display plane composited after processing; budget the interface before choosing the sensor (frame size × fps against usable MB/s); prove the file is clean with a byte-diff. Speccing the station now? Start the camera configurator with the resolution your bandwidth check allows — and if you want the budget checked before you order, send it through the contact page.