A recorder application can display every camera while your vision software detects none of the board's inputs. That usually calls for an acquisition-interface check before a hardware change. For engineers integrating existing analog cameras, the useful test is whether a documented interface delivers identifiable, correctly described image buffers. Start with one channel, prove that path, then expand. The related frame grabber SDK support guide explains why success in one viewer does not establish support in another.
Separate a working viewer from a supported acquisition path
A board-specific viewer proves that some combination of hardware, driver and software can receive video. It does not prove that another application can enumerate the device or obtain its frames.
Likewise, an application listing only USB cameras tells you which acquisition interfaces it currently recognizes. It does not establish that an installed analog capture board is defective.
Check the following causes in order. Change that order when logs or a documented compatibility statement point elsewhere.
| Symptom | Likely cause | First discriminating test |
|---|---|---|
| Video works only in the recorder application | No compatible acquisition interface is installed or supported | Find the documented API and run its acquisition example |
| A supported example cannot open the board | Driver mismatch, access conflict or unsupported configuration | Close other capture applications and inspect the returned error |
| The board opens but the selected input stays blank | Wrong channel, signal mode or input routing | Test a known working source on one documented input |
| Images arrive with shifted rows or incorrect colors | Stride, packing or plane interpretation mismatch | Compare buffer metadata with the conversion code |
| Capture starts, then freezes or mixes images | Buffer reuse, ownership or queue-management error | Copy each frame before returning its acquisition buffer |
The camera acquisition software compatibility guide helps distinguish a native acquisition module from an SDK bridge or decoded-stream route.
Establish the driver and SDK route first
Record the board identity, operating-system version, application architecture and installed driver package. Obtain drivers, SDKs and documentation from the manufacturer or an authorized distributor. Match the package to the actual board and supported operating system, rather than relying on a similar product name.
Then establish which access route is documented:
- Native acquisition support: the vision application explicitly supports the board or its acquisition driver.
- An SDK bridge: your program calls the board's SDK and transfers images into the vision library through its documented image-import interface.
- A supported operating-system capture interface: the board exposes video through an interface that your application actually accepts.
- A documented encoded-stream route: software receives compressed video, decodes it, and supplies decoded images to processing.
Do not assume that any of these routes exists. A file-export feature or recorder preview is not equivalent to live image-buffer access.
Run the smallest official acquisition example before writing a bridge. If it fails, record its error code and resolve that failure first. If it works only after closing another program, follow the frame grabber access-conflict checks.
If a supported interface requires a separate license, use the documented licensing path. Reinstalling unrelated drivers will not establish entitlement or add missing API support.
Isolate one input and verify signal handling
Disable processing and recording while testing one camera on one input. Use the same signal mode that produces a stable image in the board's supported viewer. Confirm the input connector, channel identifier, video standard and acquisition mode through documented settings.
Keep physical connectors and software channel identifiers in a small mapping table. The first connector might not have the identifier your application assumes. Some devices expose separate acquisition objects; others select an input through a shared capture object.
Do not infer simultaneous acquisition from the number of connectors. Check whether the board provides independent channels, multiplexes inputs, or divides an aggregate capture rate among them.
For interlaced sources, establish whether the SDK returns individual fields, woven frames or deinterlaced images. Moving edges can appear combed when fields from different times are combined. A single-field image can have a different height from the expected full frame.
A stationary test pattern separates geometry problems from motion-related field artifacts. Once the picture is stable, repeat with motion representative of the inspection. For horizontal displacement or periodic row corruption, use the analog video scanline distortion checks rather than adjusting unrelated processing thresholds.
Verify the complete image-buffer description
A memory address and an image width are not a sufficient interface contract. Read the SDK's returned image description and compare it with what the vision library expects.
For each frame, establish:
- Width and height in pixels.
- Pixel format, meaningful bit depth and storage size.
- Packed or planar organization and component order.
- Row stride in bytes, including padding.
- Plane offsets and plane-specific strides, where applicable.
- Top-down or bottom-up row order.
- Channel identifier, sequence identifier and timestamp, when provided.
- Valid payload length and buffer capacity.
For a single-plane, byte-addressable image, the required storage is commonly calculated as follows. The SDK's documented allocation rules remain authoritative.
These equations do not describe every packed high-bit-depth or multi-plane format. For those formats, use the documented packing rules and sum the required plane allocations.
The multi-channel image buffer sizing guide covers allocation checks when several images share a processing path.
Also distinguish a raw pixel buffer from compressed data. Compressed video bytes cannot be presented to an image library as though they were grayscale pixels. Decode through a supported route, then validate the decoded image description. After conversion, confirm the actual output type using the converted image pixel-format checks.
Prove buffer ownership before processing asynchronously
An image can look correct initially and still fail under load because the application keeps a pointer after the capture driver reuses its buffer.
Read exactly when the SDK permits access and when ownership returns to acquisition. A callback may provide only temporary access. Other interfaces require an explicit release, requeue operation or documented buffer-retention mechanism.
For the first integration test, copy the image into application-owned memory before releasing the acquisition buffer. Pass that copy, along with channel and sequence metadata, to processing. This is a diagnostic simplification, not a claim that copying is the final performance optimum.
Use this logical sequence:
- Receive a completed frame and its metadata.
- Validate status, dimensions, format and payload length.
- Copy pixels into a correctly sized destination.
- Associate channel, sequence and timing information with that copy.
- Return the acquisition buffer according to the SDK contract.
- Queue the owned image for processing.
Keep callbacks short. Display, disk access and inspection algorithms can block acquisition if performed directly inside a time-sensitive callback.
Bound the processing queue and define what happens when it fills. The multi-camera callback and buffer-queue guide explains how delayed release and blocked consumers can stop an otherwise valid acquisition path.
Work through stride, throughput and queue delay
Consider a hypothetical decoded grayscale stream with a width of 640 pixels, a height of 480 pixels and one stored byte per pixel. Suppose the SDK reports a row stride of 672 bytes.
The packed image calculation gives:
Allocating only the packed size leaves the buffer short by 15,360 bytes. Alternatively, copying the full buffer into a tightly packed image without removing padding produces incorrect row boundaries. Either preserve the stride through a supported import interface or copy the valid pixels row by row.
Now assume four such channels each deliver 30 frames/s. The acquisition-buffer traffic is:
This estimate uses decimal megabytes and excludes additional copies, decoding, color conversion, display and recording. Measure the actual workload rather than treating this figure as a complete host-performance requirement.
Queue depth also affects freshness. If six frames are waiting ahead of a new frame in a per-channel queue consumed at 30 frames/s, the waiting time is approximately:
That estimate assumes steady consumption and excludes processing time for the new frame. A larger queue can absorb a brief stall, but it cannot fix sustained processing slower than acquisition.
Verify each channel before running the full workload
Start with capture and metadata logging only. Then add format conversion, image copying, processing, display and recording separately. The first stage that introduces corruption or missing frames narrows the investigation considerably.
For each stage, record received frames, incomplete frames, queue occupancy and processing duration. Track sequence identifiers when available. If the SDK provides none, assign local identifiers at receipt, while recognizing that these cannot reveal frames lost before delivery.
Use a defined acceptance run. For example, a hypothetical channel delivering 30 frames/s for 60 seconds would produce approximately 1,800 frames, excluding startup effects. Compare that expectation with the actual delivery rate and documented acquisition behavior. Count completed frames rather than callback invocations if callbacks can represent other events.
Repeat with every input enabled, then add the intended production workload. Watch for aggregate-rate limits and channel identity errors that were invisible during a single-input test.
For a system organized around several capture objects or shared device resources, review the multi-camera acquisition session architecture before assuming that each input can be opened independently.
Change hardware only when the interface evidence supports it
Replacing the board is justified when no documented acquisition route meets the application's requirements, support is unavailable for the required host, or verified capture limits are insufficient. Changing hardware before resolving the interface question can reproduce the same integration problem.
The frame grabbers category and accessories finder cover several digital interfaces. They are not a list of interchangeable analog digitizers.
For example, MV-GC1102IOL is listed with a Camera Link interface. That identifies a different camera connection, not an analog-input solution.
- Interface
- Camera Link
MV-GE1104 is listed with a GigE interface and 4 ports. Its listing does not establish compatibility with an existing analog camera or a particular vision application.
- Interface
- GigE
- Ports
- 4 ports
If replacing the camera is practical, compare area scan cameras through the camera finder. Select the acquisition interface alongside resolution, shutter behavior and application support. A digital redesign still needs a verified driver, pixel-format contract and buffer lifecycle; it does not remove those responsibilities.
Complete the integration checklist
Before committing to the final integration, confirm these items:
- Supported route: documentation identifies how your application obtains live images, not merely how a viewer displays them.
- Matched software: driver, SDK, application architecture and any required license are compatible.
- Known input mapping: each physical connector maps to the intended software channel.
- Stable signal: video mode and field handling produce correct stationary and moving images.
- Verified layout: dimensions, stride, packing and payload length match the imported image.
- Explicit ownership: every buffer is retained, copied or released according to the documented contract.
- Bounded latency: the processing queue stays within the application's permitted delay under sustained load.
- Recorded evidence: the acceptance run includes counts, errors and channel identities.
If the supported route remains unclear, bring the board identity, documented interface, host details and smallest failing example to application support. If the evidence calls for a digital acquisition redesign, use the configurator to compare the required accessory interface rather than choosing by connector count alone.
The configurator matches a camera, lens, light, light controller and cables to each other, step by step, and lists only parts that fit what you already picked.
Questions
Why does the recorder show video while the vision application finds no camera?
The recorder may use a board-specific driver that your vision application does not support. Identify the documented acquisition API and check whether your application accepts it directly or needs an SDK bridge. USB device discovery alone does not test access to an installed capture board.
Can recorded or compressed video be used as live inspection input?
Only if the recorder provides a documented live export interface suitable for that purpose. A preview window or saved video file does not establish access to current image buffers. Check decoding, image layout, timing and permitted buffer lifetime before treating exported data as inspection input.
Why is the reported buffer larger than width times height?
Stride describes the byte distance between rows and can include alignment padding beyond the visible pixels. Allocate according to the documented buffer requirements. When the destination requires tightly packed rows, copy the valid pixel data row by row instead of including source padding.
When should an existing analog capture board be replaced?
Consider replacement when the required operating system or acquisition interface lacks documented support, or measured capture limits cannot meet the task. First prove the limitation with an official example and a controlled test. Select replacement hardware against camera signaling and application support together, not port count alone.