Vertical lines in a camera image: display path, not the sensor

Periodic white vertical lines in a live machine-vision image look like a dying sensor or a damaged cable, and most teams reach that conclusion after swapping hardware that was never at fault. In one reported integration — a Windows XP workstation, a PCI image-acquisition card and a WPF front end — the lines appeared only when frames were pushed through an accelerated bitmap update, their repetition tracked frame rate and frame aspect ratio, and the very same frames drawn through GDI came out clean. The cure was a graphics driver from a newer Windows generation, not a replaced camera, cable or grabber. The tests below assign vertical lines to the right layer in minutes, explain the mechanism, and fix it without touching the acquisition side.

The decision: name the layer before you unplug anything

Three behaviors, together, put vertical lines in the display render path rather than the sensor:

• The lines appear only when frames reach the screen through WritePixels() on a WriteableBitmap, or Invalidate() on an InteropBitmap, while that bitmap is bound to an Image control.
• Their repetition rate changes with frame rate and with image size — behavior a pixel defect cannot produce.
• The same frames, drawn through GDI, the classic Windows 2-D drawing API, come out clean.

When those three hold, stop troubleshooting the camera. The decisive evidence is the file test: save the frame that shows lines on screen straight from the acquisition buffer, open it in an external viewer, and if the pixels are clean, every component upstream of the save is cleared. A defective sensor column sits at one x position in every frame and ignores your frame-rate setting. Dropped packets on a network link draw horizontal bands at random heights instead — a different signature, covered in GigE Vision packet loss: horizontal lines in live images.

Why the accelerated render path corrupts pixels

A WriteableBitmap keeps two buffers: a front buffer the rendering system samples, and a back buffer your code fills through WritePixels(). The WriteableBitmap class description states that the rendering system controls the exchange between the two to avoid deadlocks and redraw artifacts such as tearing. That protection holds only while your writes and the compositor's reads stay synchronized. Under heavy rendering load they do not: issue reports against current .NET describe updates landing in the middle of a draw, leaving bands of mixed old and new pixels on screen.

The heavier each update, the longer the collision window. Every WritePixels() call moves width × height × bytes per pixel, and the calls repeat at the display rate, so the artifact's frequency tracks frame rate and frame geometry — the dependence on aspect ratio seen in the reported case. InteropBitmap with Invalidate() shares the mechanism: your code fills the memory section the renderer samples, and an unsynchronized fill shows up as tearing.

That case added one more clue: the FRAME_DONE timing pulse wobbled on an oscilloscope exactly when the glitches appeared. Read that as load, not corruption — the accelerated path was loading the machine enough to disturb interrupt timing while the frames themselves kept arriving. To see the whole road from sensor to screen, walk GPU-accelerated vision streaming: trace the video pipeline.

Isolation procedure, in order

1. Save ten suspect frames from the acquisition buffer to disk, upstream of all display code. Lines in the files: work the camera side. Clean files: the display path owns them.
2. Log the x position of the lines across 100 frames. One fixed position means a column defect; wandering positions point to transport or rendering.
3. Redraw the saved frames through a second render path — GDI into a plain window. Lines gone: render path confirmed, hardware cleared.
4. Unplug the camera and put a test pattern on screen. Lines that persist with no camera attached belong to the display or its driver.
5. If the connector exposes FRAME_DONE, scope it while toggling between render paths. Deflections that follow the accelerated path and vanish under GDI confirm display-induced load.
6. Update the graphics driver to the current WHQL release and retest. In the reported case the driver generation was the entire fix: the same version family, built for a newer Windows, cleared the lines with no other change.
7. Only now swap hardware — reseat the card, try another camera — and re-run the file test after each change so each swap proves something.

What each line signature points to

Split and offset halves are the classic tap-geometry error on older interfaces; frame grabber image acquisition for Camera Link and CoaXPress covers that setting. If the lines survive step 4, the fault is in the display chain itself — panels and their drivers fail on their own, and vertical lines on an industrial HMI panel walks that diagnosis.

Worked example: 12 MP at 30 fps through WritePixels

Inputs, each with its source:

• Frame size: 4000 × 3000 pixels — the printed resolution of the example camera below.
• Rate: 30 fps — its printed maximum.
• Pixel format: 8-bit mono, one byte per pixel — the assumed display format for this example.
• Display policy: a naive full-rate redraw, one WritePixels() call per acquired frame.

The example camera is the LS-CMR-0166, a 12 MP USB3 area scan camera with a 4000 × 3000 sensor and 30 fps output.

In words: the back-buffer write load is frame width times height times bytes per pixel times displayed frames per second.

The arithmetic:

• 4000 × 3000 = 12,000,000 pixels per frame
• 12,000,000 × 1 B = 12,000,000 B ≈ 12 MB per frame
• 12 MB × 30 fps = 360 MB/s of back-buffer writes
• 1 s ÷ 30 = 0.033 s, so one 33 ms update window, repeated 30 times a second

Decision: 360 MB/s of unsynchronized bitmap writes sits far above our working ceiling of about 150 MB/s, where collisions with the compositor become routine. Throttle the operator view to 10 fps — 12 MB × 10 = 120 MB/s, under the ceiling — and let acquisition keep its full 30 fps, or move the live image to a GDI blit path. Throttling is the five-minute fix; the GDI path is the permanent one.

Here is the camera this example is built on:

Fixes that hold

• Marshal the copy synchronously. Call Dispatcher.Invoke() rather than BeginInvoke() for the WritePixels() update, so each copy completes before the next render pass — the standard first fix for this tearing.
• Throttle the display loop. An operator view at 10-15 fps shows everything a person needs; run acquisition at full rate in its own loop, as continuous camera acquisition mode for live image loops explains. Sharing the GPU with playback has limits of its own — GPU contention in machine vision covers them.
• Draw the live image with GDI. In the reported case, GDI playback was clean from the first day; keep the WPF surface for controls and overlays.
• Disable hardware graphics acceleration for the application — the WPF setting of that exact name — as a diagnostic and a stopgap. It costs CPU on the UI thread in exchange.
• Patch the runtime and the graphics driver. Vendors have shipped hotfixes for several WPF rendering defects, and in the reported case the driver alone cured it. One caution: a driver update can break acquisition instead — the failure mode in frame grabber driver mismatch after a vision software upgrade — so re-run the file test afterwards.

If the fault does trace to aging acquisition hardware, a current card rebuilds that side cleanly: the MV-GE1104 is a 4-port GigE frame grabber, and the LS-FGB-0004 is a PCIe x4 4-port PoE Gigabit Ethernet card for GigE cameras. Compare the whole frame grabbers range or the frame grabber finder when port count and interface drive the choice.

When the lines really are the camera

The file test convicts the upstream side in one pass, and the signatures then separate further. A fixed column present in every saved frame is a sensor defect; rotating the camera 90° in its mount turns that line horizontal in the file, which a display artifact never does. On line scan cameras vertical striping has causes of its own — resolving vertical image lines on a line scan camera walks them. When several cameras corrupt at once, suspect the shared layer first: multi-camera image corruption: isolate shared hardware faults gives the order. And when the sensor is genuinely at fault, replace against resolution, shutter and mount — the area scan cameras page and the camera finder filter on exactly those.

Checklist before you order parts

• Save suspect frames to disk and inspect them in an external viewer before changing anything.
• Redraw the saved frames through GDI once; minutes of work clear or convict the render path.
• Record whether line positions are fixed or wandering across 100 frames.
• Note whether the glitch rate moves with frame rate and image size — the fingerprint of a rendering artifact.
• Update the graphics driver and retest before any hardware swap.
• Cap the operator display at 10-15 fps and keep acquisition at full rate.
• Re-run the file test after every change so each fix is proven, not assumed.

If the lines survive every test here, bring the saved frames plus your OS, driver and .NET versions to the contact page — a clean file next to a corrupted screen is a strong starting point. To replace the acquisition chain outright, start at the accessories step of the configurator.