Frame grabber stuck at low resolution: test the DirectShow path

An analog capture card previews crisply in the vendor's own viewer, yet your vision software offers nothing above 320×240 and throws an error the moment you change the pixel format. The cause sits between those two programs: the card's DirectShow driver publishes one small format, and a generic acquisition layer can only offer what the driver publishes. Your processing code is not involved. This guide follows the diagnosis in the order you meet it — prove which side of the driver boundary the ceiling is on, count the pixels the inspection actually needs, then decide between the vendor's supported software path and a digital replacement. Every number is carried through the arithmetic, so you can rerun it on your own field of view.

Why is my capture card stuck at 320×240?

Because the DirectShow capture driver advertises only one small output format, and an acquisition layer can only list what the driver advertises: 320×240 is a preview mode, not the capture ceiling.

DirectShow capture filters publish their sizes, pixel formats and frame rates through a stream-configuration interface. A vision library that speaks DirectShow enumerates that list and presents it — nothing more. When the driver exposes a single 320×240 entry, every host program on the machine sees one entry. The Win32 documentation on enumerating DirectShow devices and filters describes the mechanism; the format list is read the same way, from the capture pin. The hardware is usually fine: legacy analog capture chips digitize a full frame internally, and the small format is simply all the filter was built to expose.

How do I prove the limit is the driver, not my software?

Open the card in a plain DirectShow capture tool such as AMCAP, the classic sample application, and read its format list: the resolutions offered there are the complete set the driver hands to every DirectShow program on the machine.

1. Open the plain DirectShow tool and select the capture card as the video source.
2. Open its video-format or capture-pin properties dialog and write down every resolution and pixel format offered.
3. Record a few seconds at the largest format and confirm playback at that size.
4. Open the same dialogs in your vision software's device configuration and compare the two lists.

Identical short lists mean the driver is the ceiling; no setting in your vision software will change that. A longer list in the plain tool means the limit is host-side — an acquisition-layer version that filters formats, or a pixel-format negotiation that fails. The same split decides VGA and HDMI capture paths, as capture a VGA screen with a DirectShow frame grabber shows.

Why does the vendor's own viewer show full resolution?

Because the vendor's viewer does not use the DirectShow path at all: it talks to the board through the vendor's own SDK or a TWAIN interface, and that path exposes the full digitizer output.

There are two doors into the same silicon. Door one is DirectShow, used by third-party software; door two is the vendor SDK or TWAIN, used by the vendor's viewer and by TWAIN-aware imaging software. The full format list lives behind door two. That is why the viewer captures full frames while DirectShow hosts sit at the preview size, and why the two lists disagree. Some vendors also publish an integration pack that scripts their SDK from inside your development environment; when the manufacturer publishes it, that is a supported route and usually the fastest fix. The pattern is covered in frame grabber SDK support: why one viewer works and another fails, and the options for older analog grabbers in analog frame grabber integration with vision software.

Why does the card appear under the wrong interface class?

Because a generic acquisition layer enumerates every DirectShow source as a camera, so a PCIe capture card lands in the same device branch as 1394 and GigE cameras: cosmetic in itself, but a reliable marker that you are on the generic DirectShow path rather than a native device driver.

The card has not been misdetected; the tree simply has no better slot for a DirectShow source. Treat the label as information, not as a fault to chase. The same narrowing appears elsewhere: a driver that exposes one format also shrinks the property pages around it, the pattern in camera property shows only on or off in the capture API. The pixel-format error belongs here too — the single advertised format carries its own subtype, so a request for RGB against a driver offering only packed YUV has no matching media type to bind to.

How many pixels can an analog capture card really deliver?

Plan around 0.3 megapixels: 640×480 gives 307,200 pixels for NTSC sources and 768×576 gives 442,368 pixels for PAL, and that sampling is the ceiling whatever the software above it does.

The analog signal, not the card, is the limit — the visible active region carries 480 lines for NTSC and 576 for PAL. Interlace halves the vertical detail for anything that moves between fields, which matters on a conveyor. Add up what each offered mode actually contains:

The best any analog card delivers is about 0.44 megapixels. A driver stuck at 320×240 hands you one quarter of the NTSC frame.

How many pixels does my inspection actually need?

Divide the field of view by the smallest feature and multiply by three: pixels across = field of view ÷ feature × 3, with three pixels per feature the working minimum for measurement and code reading.

Worked example, arithmetic shown. Field of view 240 mm × 180 mm, smallest feature 1.0 mm, three pixels per feature.

• Needed across: 240 mm ÷ 1.0 mm × 3 = 720 pixels; needed down: 180 mm ÷ 1.0 mm × 3 = 540 pixels.
• At 320 pixels across: 240 ÷ 320 = 0.75 mm per pixel, so a 1.0 mm feature spans 1.0 ÷ 0.75 = 1.3 pixels. Undersampled; edges will not be found reliably.
• At 640 pixels across: 240 ÷ 640 = 0.375 mm per pixel, so the feature spans 2.7 pixels — enough to detect, marginal to measure.
• At 0.5 mm features the requirement doubles to 1,440 pixels across, and analog is out at any format the driver lists.

Decision: the full NTSC frame just clears a 1.0 mm feature at a 240 mm field of view; the 320×240 mode fails that same task outright, and no software recovers a 1.3-pixel feature.

A digital camera answers the 0.5 mm case directly. The LS-CMR-0166 is a 12 MP USB3 area scan camera with a 4000 × 3000 resolution. Carried onto the same 240 mm field of view, its pixel pitch is 240 ÷ 4000 = 0.06 mm, so a 1.0 mm feature spans about 17 pixels and a 0.5 mm feature about 8.

What is the supported fix when the DirectShow driver is the limit?

Use the board vendor's supported path: the manufacturer's current driver package, or the vendor-supplied SDK wrapper that the vendor's own viewer uses, downloaded only from the manufacturer or its distributors.

1. Download the current driver and SDK package from the board vendor or its distributor, never from a driver-download portal.
2. Read the release notes for the DirectShow section; you are looking for a stated format list that includes the full capture sizes.
3. Install the vendor's integration components if your environment is on the supported list; these wrap the SDK path the vendor's viewer uses.
4. Re-run the plain-tool format list from the previous section; the new list is what every DirectShow host will now offer.

If the vendor states that the DirectShow filter exposes preview formats only, the card will never do better through that door. Keep the working preview for setup, and plan the replacement. Driver clashes after a software upgrade follow the same discipline, covered in frame grabber driver mismatch after a vision software upgrade; for a new analog purchase, selecting an analog frame grabber for a vision development environment lists what to demand from the vendor first.

When should you replace the analog capture path instead?

Replace the card when the task needs more than about 0.44 megapixels at that field of view, when the vendor supports no driver for your software, or when the line is being upgraded anyway — a digital camera removes the format-negotiation layer entirely.

Decide by case:

• At most 0.3 megapixels needed and the vendor's driver or SDK wrapper delivers full frames in your software — keep the card and stop.
• Features smaller than about 1 mm at a 240 mm field of view, or any need beyond 0.44 megapixels — analog cannot reach it; replace.
• No supported driver for your software — replace now, before the next reinstall makes the decision for you.
• Camera Link cameras already on the line — keep the cameras and change the host side; analog camera on a Camera Link frame grabber explains why an adapter cable is not the bridge but a real Camera Link grabber is.

For GigE cameras the host side is a PoE network card. For a first camera or two:

The LS-FGB-0004 is a PCIe x4, 4-port PoE Gigabit Ethernet card built on the Intel i210AT controller. To keep existing Camera Link cameras in service:

The MV-GC1102IOL is a Camera Link frame grabber. For the camera that clears the worked example with margin:

Camera-side, browse area scan cameras filtered by interface and resolution, and read camera frame grabber compatibility for resolution upgrades before committing to a pairing.

What should you check before ordering the replacement?

Match three things in order: the camera interface to a host card you have or are ordering, the cable to the run, and the pixel count to the smallest feature, using the numbers from the worked example above.

• Interface and ports. One camera per port, plus a spare; the frame grabbers finder filters by interface and port count.
• Cable and connector. Locking connectors for GigE, drag-chain rated where the cable moves; the cables category filters by type and length. Wiring faults cause most connected-but-no-image tickets, as camera connected but no image works through.
• Pixels at your real field of view. Rerun the formula with your numbers; hold the three-pixels-per-feature minimum.
• Frame rate. Analog delivered 25 or 30 interlaced fields per second; take the digital camera's rate from its own data, not from the old card.

For several GigE cameras, split them across ports rather than sharing one:

The MV-GE2002P is a dual-port PoE NIC; the MV-GE1104 is a 4-port GigE frame grabber.

With those settled, run the system configurator from the camera step, or send the two format-list screenshots and your pixel math through the contact page and we will size the replacement with you.