Camera listed in one app but not another: DirectShow vs GenTL

Your capture utility shows the camera: the live image updates, the exposure sliders move, everything on the USB side works. Then your acquisition program — a Python script, a C++ service, a configuration tool — enumerates devices and returns an empty list. The camera did not change. The two programs are reading different driver stacks: one talks to the operating system's USB video class driver, the other talks only to GenTL producers, and a program with zero registered producers shows an empty list by definition. Below are the two stacks, the arithmetic that produces an empty list, and the fix in the order that works — for USB3 and GigE area scan cameras, and for whatever desktop or vision controller the software runs on.

Two driver stacks, one camera

A Windows PC can carry two independent camera enumeration mechanisms at once, and neither looks at the other. The first is the operating system's own path: for a USB camera that follows the USB Video Class (UVC) specification, Windows loads a class driver, and any program built on DirectShow or the media APIs lists the device as soon as it is plugged in. The second is GenTL, the transport layer of the GenICam standard: a program asks which GenTL producers are registered, then asks each producer which cameras it can reach.

The practical consequence is easy to state. A live image in the viewer proves the cable, the port, the bus bandwidth and the class driver. It proves nothing about the producer registration your SDK depends on, and an empty SDK list proves nothing wrong with the camera. Two lists, two sources, one device.

This split between 'the device is fine' and 'the tool that must list it' reaches beyond cameras. The same shape appears in factory networks, where a PROFINET node replies to a ping yet stays invisible in the configuration tool until it is registered where that tool looks.

What the DirectShow side actually proves

DirectShow enumeration is handled by Windows itself. A UVC camera appears in Device Manager the moment it is plugged in, and DirectShow-based programs list it with no vendor software installed. The viewer list therefore tests three things: the camera enumerates on the bus, its USB descriptors are in order, and the link sustains the negotiated format's bandwidth.

It tests nothing GenTL-related: not whether a producer is installed, not whether the variable pointing to it exists, not whether the SDK and producer versions match. Treat the working viewer as a cleared hardware bill and move to the software stack.

One boundary to keep in mind: not every industrial camera is UVC, and some need their maker's driver even for DirectShow programs. Frame grabbers sit further from the class still, which is why a frame grabber stuck at low resolution gets diagnosed by testing its DirectShow path — the same isolation trick, one layer down.

What a GenTL producer is

A GenTL producer is a library — a .cti file on Windows — that implements the GenICam transport layer for one physical link. One producer handles a vendor's USB3 Vision cameras, another handles GigE Vision cameras through the network interface, a third belongs to a frame grabber and speaks for the cameras on its connectors, a fourth carries a depth camera's data path. The SDK never touches hardware directly. It loads producers and asks each one to enumerate.

You get the producer from the camera or frame grabber maker: the manufacturer's support or download area, or the distributor that supplied the hardware. It installs alongside the class driver; the two categories are separate files and coexist without configuration. The pairing that matters is version. An SDK and a producer from far-apart releases can load and still fail on missing functions — the GenTL producer version compatibility problem.

Where a GenTL application looks for producers

The GenICam standard defines the discovery mechanism as environment variables holding paths to producers. On 64-bit Windows the variable is GENICAM_GENTL64_PATH, on 32-bit it is GENICAM_GENTL32_PATH. Each holds one or more entries, separated by semicolons, pointing at producer folders or .cti files. Installers normally create and fill them; an SDK or producer copied by hand often does not.

A process reads its environment once, at start. Change the variable and nothing happens until you close and relaunch the program — the running process still holds its old, possibly empty, producer set. From a command prompt, echo %GENICAM_GENTL64_PATH% shows what the next launch will see, and every entry in it should exist on disk and match your camera's transport.

Enumeration then reduces to a sum:

Two failure modes hide in the second line. A producer can be installed while its .cti is not listed — the GenTL producer not listed despite a correct DLL layout case. Or the entry can be present but malformed: the producer loads with an empty result. Print the variable, quote each path entry on its own, and check the file exists at exactly that location before restarting the application.

Worked example: a USB3 camera listed in the viewer, absent from a 64-bit Python list

Inputs. One 12 MP USB3 camera, 4000 × 3000 pixels, 30 fps, 1/1.7-inch rolling-shutter sensor — in this build the LS-CMR-0166. One DirectShow-based capture utility that lists it and streams live video. One 64-bit Python SDK built on GenTL that returns an empty device list. GENICAM_GENTL64_PATH prints nothing: no producer is installed.

Rule. A GenTL application lists only cameras reached through producers it can load. The DirectShow list is computed from the class driver and shares nothing with that sum.

Arithmetic.

• Producers the SDK can load: 0
• Cameras each loaded producer would reach: 1 (the camera enumerates on USB — the viewer proves it)
• SDK device list = 0 × 1 = 0 cameras
• Viewer device list = 1 camera
• After installing the producer and setting the variable: 1 producer × 1 camera = 1 camera in the SDK list

Result. The camera was never at fault. The list was empty because zero producers were registered, and no amount of USB troubleshooting changes that product.

Decision. Viewer count at 1 or more with SDK count at 0 means: install the maker's GenTL producer, point the variable at it, restart the application — in that order. Move to transport-level causes such as packet size or power only when both lists are non-empty and acquisition still fails.

Fixing the list, in order

1. Name each program's stack. The documentation or release notes state whether a program enumerates through the class driver or through GenTL. The viewer-versus-SDK split above is the common pairing.
2. Download the GenTL producer for your camera and your application's bitness from the manufacturer's download area or your distributor, and install it.
3. Print the variable for that bitness — echo %GENICAM_GENTL64_PATH% for a 64-bit program — and confirm the new producer's path is present and exists on disk.
4. Restart the application so it reads the environment again, then enumerate.
5. If the producer is registered but the list stays empty, check the CTI against the SDK: the empty camera list caused by a mismatched CTI and the CTI file that loads without error but still needs validating cover the two halves of that test.

GigE Vision and other transports

DirectShow never enters the picture for GigE Vision: Windows ships no class driver for the protocol, so every program that lists a GigE Vision camera, viewer or SDK, goes through a producer. A 2.5 MP GigE camera such as the MV-CU020-90GC, global shutter, C-mount, appears in a program only when that program's producer can reach it. When the viewer shows a GigE camera and the SDK does not, the usual cause is that the two programs load different producers — or one of them loads none.

Camera Link and CoaXPress cameras hang off frame grabbers, and the grabber maker supplies the producer for its boards. Depth and 3D cameras ride producers too; the data path behind a depth camera's GenTL setup follows the same pattern as a 2D camera's. On Linux the variables carry the same names and the failure mode is identical, with its own loading quirks covered in GenICam producer loading errors in Linux applications.

Near misses that look identical

Three other faults produce the same one-app-sees-it experience, and each has a quick discriminator:

• Bitness. A 32-bit program reads GENICAM_GENTL32_PATH and cannot load a 64-bit producer, so it lists nothing even with the 64-bit variable perfectly set. Install the matching producer. A bitness mismatch in a Python SDK fails the same way — the ImportError from a wrongly-bitted camera SDK is that fault surfacing at import time.
• Exclusive access. Enumeration can succeed while opening fails, because another program still holds the camera. Close the viewer before the SDK opens the device; the release discipline is the same one that lets a ROS camera driver hand cameras back to other applications.
• Windows permission. Privacy settings on current Windows builds can deny applications access to cameras outright, which looks exactly like an empty list. The Windows camera access permission check takes a minute and rules it out.

The stack logic runs unchanged on dedicated hardware. Whether your acquisition code runs on a desktop or a compact vision controller such as the MV-VC2140-128G40-1T — 8 GB of RAM, a 128 GB SSD plus a 1 TB HDD, 2 USB 3 ports, 4 built-in light channels — the same variables decide what the software sees.

Checks before you blame the hardware

• Device Manager shows the camera with no warning icon. The bus, cable and class driver are healthy; the fault sits on the software stack.
• echo %GENICAM_GENTL64_PATH% prints at least one path that exists on disk. An empty print means the next launch will enumerate nothing, whatever you plug in.
• The listed path belongs to your camera's maker and its transport. Producers are link-specific: a GigE producer never lists a USB camera.
• The application's bitness matches the variable you set and the producer you installed.
• Only one program holds the camera when the SDK opens it.
• SDK and producer versions come from release families that are known to work together.

If you are re-running this diagnosis because a camera change triggered it, the camera finder and the system configurator lead to cameras whose producer, class driver and documentation ship together, and the systems guides collect the rest of the enumeration fixes. Anything still unresolved, the contact page is the direct line to the applications team.