Webcam selection ignores the name: open cameras by index instead

Two different webcams on one computer, and your vision software lists both names. You feed one of them to the open function, and the image never changes: it is always the camera whose name sorts first. Nothing is wrong with the cameras, the cables or the ports. The name in that list is a display label, and the open call is not using it — the driver is opening the first device it found. This walkthrough proves that in two minutes, then shows how to open the camera you actually wanted by index or by persistent device path, and when to accept that the wrapper supports one camera and route around it.

What the symptom tells you

The giveaway is which camera wins: the one whose name comes first alphabetically. A wrapper that honored your choice would fail loudly when you picked a camera that does not exist, and would switch images when you picked the other one. A wrapper that ignores the choice opens whatever sits at the front of its device list — and device lists are sorted for display, so the front is the alphabetically first name. Your selection is being drawn on the front panel and thrown away before the open call.

The two cameras are different models, so they carry different vendor and product ID pairs on the bus. The information needed to tell them apart exists; this open call simply does not use the name to do it.

Two-minute tests that settle it

1. Pass a name that cannot exist, such as zzz-not-a-camera. An error here means selection is honored; a silent open of the front-of-list camera means the string is never read at all.
2. Unplug the camera that always wins and restart the program. The other camera should now appear on its own — exactly what a call that always takes the first enumerated device produces.
3. Swap the two cameras between their USB ports and restart. If the same camera still wins, the choice tracks the sorted name list, not the physical port.

Any one positive test settles the question. All three together leave no room for doubt, and none of them needs a second computer or extra hardware.

The fix: map the name to an index at every startup

Work in this order:

1. Enumerate the cameras at program start — never carry the list over from a previous run.
2. Find the position of the name you want in that fresh list.
3. Open the camera by that position, not by the string.
4. Assert that the device you opened reports the name you asked for; if it does not, stop before grabbing frames.

Illustrative pseudocode — the calls are named for what they do, not for any one library:

devices: list[str] = enumerate_cameras()   # e.g. ['HD Web Camera', 'USB 2.0 Camera']
wanted:  str      = 'USB 2.0 Camera'
idx:     int      = devices.index(wanted)  # 1
cam:     handle   = open_camera(idx)       # opens device 1, not device 0
assert cam.device_name == wanted           # the test that proves the open honored the map

On Linux, the numbered capture nodes shuffle between boots in exactly this way; the persistent path aliases that encode the physical USB port do not. Prefer the alias when the wrapper exposes it, and see multiple USB cameras on Linux: stop device path conflicts for the same fight at the node level. If your two cameras are the same model and report the same name, the name cannot separate them at all — open them by physical port instead, as two identical USB cameras: same name, open one by port and USB port ID the same for all cameras: fix multi-camera identification show. A plain loop over the interface names is enough to build the map — see enumerate camera interface names with an index loop.

Worked example: two different webcams, one open call

Inputs, with the camera names as illustrative placeholders:

• Camera A reports the name HD Web Camera — sorts first, always wins.
• Camera B reports the name USB 2.0 Camera — the view you want.
• The enumeration list at startup reads A then B, so A sits at index 0 and B at index 1.
• Goal: display B now, and both cameras later.

The rule: open the index the name maps to, and prove it with the name the opened device reports. Open index 1 and assert the reported name is USB 2.0 Camera; the assert passes only if the open honored the index. If both cameras must run at once, add the bandwidth check, assuming 640 × 480 pixel frames, uncompressed at 2 bytes per pixel, 30 frames per second:

USB 2.0 is 480 Mbit/s on paper, and UVC cameras reserve isochronous bandwidth when they start, so plan on about 320 Mbit/s usable per controller. The pair fits — with about 8% headroom, which one renegotiated format will consume.

Decision: open by mapped index for switching, and commit to compressed streams or one controller per camera before you grow past 640 × 480. Above about 250 Mbit/s of uncompressed video per controller, compress or split.

When the wrapper is one-camera by design

Some lightweight wrappers state plainly, usually in a known-issues list, that they support one camera at a time. If the open function exposes no index or device-ID parameter at all, no amount of re-selecting can fix this: there is nothing to select with. Three ways out:

1. Replace the wrapper with one that opens by device ID and holds several cameras — the clean fix when both views must be live.
2. Keep the wrapper and keep switching one camera at a time, but make the switch correct: re-enumerate, re-map, open by index, assert.
3. Accept the limit for the prototype, and plan the production rig on cameras whose software opens by unique ID — the next section.

The decision rule: one camera at a time is a design limit, not a setting. Spend your time on options 1 or 3, not on the selection dropdown.

Both cameras at once

If the replacement wrapper holds two handles, two things decide success: bandwidth — the arithmetic above — and stream format. Compressed streams cut the payload by an order of magnitude; stream multiple USB cameras as MJPEG: ports, buffers and device names covers the settings, and acquire from multiple USB cameras: bandwidth and sync covers sharing and triggering. Put the two cameras on separate controllers when the housing allows it and the bandwidth question disappears.

The clean way out: cameras with real device IDs

Interface standards for machine vision settle this at enumeration: cameras that follow USB3 Vision or GigE Vision present a unique device identifier, and their software opens by that identifier, so two cameras can never be confused by a label. For area scan cameras that means your effort goes into lens and lighting, not identity.

The LS-CMR-0166 is a 12 MP USB3 area scan camera.

The same 6 MP camera generation comes in USB3.0 and GigE versions:

Lock the connection down as well: the LS-CBL-0219 is a 3 m USB3.0 camera cable built for drag-chain use.

Even on the GigE side, where every camera also carries a unique address, duplicate host names can still confuse software that lists before it opens — two identical GigE cameras on one PC: fix duplicate names and IPs walks that case. Browse the USB and GigE camera finder, or start the configurator at the camera step to build both views in one pass.

Checks before you commit

• The enumeration list is captured at program start, not carried over from installation day — port and boot changes reshuffle it.
• The selection parameter is proven live: the opened device reports the name you asked for.
• No index is hard-coded anywhere, including defaults.
• The two cameras sit on labeled ports, so a physical swap is noticed rather than guessed at.
• Both-at-once bandwidth is computed for your actual format and frame rate, per controller.
• The wrapper's known-issues list has been read for a one-camera limit before you build on it.
• Connections lock: webcam pigtails are the first thing a production station breaks, so use locking camera cables.

If the wrapper's behaviour is still unclear after the two-minute tests, send the enumeration list and the open call to us through the contact page and we will pin down which parameter the driver actually reads.