A high-resolution USB camera that offers 3840 × 2160 in every application and nothing above it is not broken: it is running on the operating system's inbox USB Video Class driver, and that driver serves only the modes the camera's descriptors declare. The sensor's full pixel count sits behind a second path — the vendor's SDK and its per-sensor configuration. What follows: how the descriptor sets a factory-fixed ceiling, how to tell which path your camera is on, the bandwidth a full-resolution stream really needs, and the decision rule for staying on UVC or moving to a native USB3 Vision machine-vision camera.
Why does a USB camera stop at 4K when the sensor has more pixels?
Because the inbox USB Video Class driver offers only the resolutions the camera's descriptors declare: if the largest declared mode is 3840 × 2160, no application can request a larger frame, no matter how many pixels the sensor behind it has.
The USB video device class is the standard that defines webcam-style streaming, and Windows, macOS and Linux all ship inbox drivers for it. An inbox driver knows nothing about vendor registers, so the entire contract between camera and host is the descriptor: a fixed list of supported frames. The sensor behind the bridge may physically expose 8000 × 6000 pixels, but if the descriptor's largest entry is 3840 × 2160, the host has no way to ask for more. No host-side setting raises that ceiling; the list is written in firmware.
What does the descriptor actually declare?
A fixed list of width, height and frame-rate triples baked into the camera's firmware at the factory — a typical webcam-class device declares 3840 × 2160 at 30 fps as its largest streaming mode, and applications can select nothing larger.
Each entry pairs a frame size with the frame rates offered at that size, and the firmware serves exactly this list. Uncompressed modes move raw pixels; compressed modes have the bridge encode MJPEG inside the camera, which is how large declared modes fit on the link at all. Many devices also declare a separate still-capture size, but it is just as factory-fixed as the streaming table. The sensor-output and bridge decisions that produce a given mode list are worked through in sensor and bridge selection for a USB MJPEG camera.
How do I tell whether my camera is on the UVC path or the native path?
Check where the device appears: a camera the operating system lists as a plain video-capture device with a generic name is on the UVC path, while a camera that only the vendor's software enumerates is on the native path.
On Windows, Device Manager shows a UVC camera under Cameras or Imaging devices, usually with a generic name. On Linux, lsusb reports interface class codes: 0x0E means video class (UVC), 0xFF means a vendor-specific protocol. The two stacks enumerate independently, so a camera can be invisible to a webcam app yet work normally inside the SDK. These pages sort out the common failure patterns: USB camera shows a generic UVC name: reinstall the device entry, USB camera configuration file missing: check device class and UVC camera not detected by software: choose the right capture path.
| Property | UVC inbox path | Vendor native path |
|---|---|---|
| Driver | OS inbox UVC class driver | Vendor runtime plus SDK |
| Mode source | Descriptor table fixed in firmware | Per-sensor configuration loaded by the SDK |
| Largest frame | The descriptor's biggest entry, e.g. 3840 × 2160 | The sensor's native size, e.g. 8000 × 6000 |
| Control | Only the controls the descriptor declares | Exposure, gain, ROI and trigger at sensor level |
| Webcam enumeration | Yes | No |
How do I reach the sensor's full resolution?
Through the vendor's native SDK, which loads a sensor-specific configuration, drives the sensor directly and returns frames at the sensor's full size — an 8000 × 6000 sensor then delivers 8000 × 6000 frames instead of the descriptor's 4K.
The SDK path works in two steps. The runtime claims the device with the vendor's driver instead of the inbox class driver, then loads a per-sensor configuration: a register set that defines the sensor's timing, its available modes and its still-capture behaviour. After that, a capture call names the size it wants, and demo tools typically expose still capture as width and height options on the command line, so one run returns a full-size frame with no streaming mode involved.
If the configuration for your sensor is missing from the installed package, it is genuinely absent rather than hidden: vendors bundle only some sensor configurations and ship others on request. Reinstall the SDK from the vendor or the distributor you bought from first; if the file is still missing, ask them for the configuration for your exact sensor model.
If the SDK connects but refuses anything above the UVC maximum, confirm which driver claimed the device; rejected sizes after that are a mode-negotiation problem, covered in USB camera format negotiation: diagnose rejected modes.
How much bandwidth does a full-resolution stream need?
Count on roughly 48 MB per mono 8-bit frame at 8000 × 6000, so USB 3.0's practical 400 MB/s payload carries about 8 full frames per second, while the same link moves a 4K mono stream at roughly 48 fps.
Treat the 8 fps as a planning figure: MJPEG on a UVC device changes the divisor, and host controllers shift the usable payload a little. A frame rate missing from the advertised list is a modes problem rather than a bandwidth one — see Camera frame rate mode missing: verify advertised modes. On the native path, an ROI readout removes the bytes before they exist: Camera ROI cropping at the source: reduce bandwidth before the host.
Which cameras stream full resolution natively?
A camera built to the USB3 Vision standard: it never enumerates as a webcam and always needs the vendor SDK, and in exchange it streams the sensor's full resolution with full control over exposure, gain, ROI and triggering.
That trade — give up webcam plug-and-play, gain the entire sensor — is deliberate: no 4K ceiling exists to escape, because the SDK delivers the sensor's full size and frame rate from the first run, with the sensor's registers under program control.
The LS-CMR-0166, a 12 MP USB3 model, streams its full 4000 × 3000 frame at 30 fps with no mode switch at all.
These area scan cameras cover the native path across sensor formats and resolutions:
- Sensor format
- 1/1.8"
- Lens mount
- C-mount
- Sensor format
- 1"
- Lens mount
- C-mount
- Sensor format
- 1/1.7"
- Interface
- USB3
For a camera that lives inside your own housing, the same native path comes on a board:
- Sensor format
- 1/1.8"
- Interface
- USB3
- Sensor format
- 1/1.8"
- Lens mount
- C-mount
USB3 models in the board-level cameras range enumerate through the vendor runtime in exactly the same way.
When is the 4K UVC mode the better choice?
When 8.3 MP is enough: a 4K frame covers 8,294,400 pixels and runs at plug-and-play frame rates near 48 fps mono, which wins over an 8 fps full-resolution stream for preview, display and coarse size checks.
The same arithmetic cuts the other way too. A 4K frame reads 8,294,400 of the 48,000,000 pixels an 8000 × 6000 sensor offers: 8,294,400 ÷ 48,000,000 ≈ 0.17, so about 17% of the sensor. Each output pixel spans 8000 ÷ 3840 ≈ 2.1 sensor pixels, so sampling is roughly 2× coarser. For a preview window, an operator display or a presence check, that is a price worth paying for plug-and-play drivers. Whether 17% of the pixels resolves your smallest feature is a measurement question: size it from your field of view in the camera resolution calculator.
Video-mode quirks have their own logic: still captures often look brighter than live video at identical settings, as explained in Video exposure and frame rate: why still images look brighter.
Which path should you choose?
Decide by capture type: stills at full resolution → stay with your camera and run the vendor SDK; continuous full-resolution video → move to a native USB3 Vision camera; 4K previews and measurements that tolerate 2× coarser sampling → stay on UVC.
- Stills at full resolution, a few times per shift: keep the camera, install the vendor SDK, and capture through it; request the per-sensor configuration from the vendor or your distributor if it is not bundled.
- Continuous full-resolution video, or exposure, gain and trigger control at sensor level: move to a USB3 Vision area-scan camera and budget bandwidth with the 48 MB-per-frame arithmetic above.
- Preview, operator display, presence and coarse gauging: stay on UVC, where 8.3 MP arrives with no driver work at all.
- Both workflows at one station: keep the UVC path for operator tools and the SDK path for setup and calibration stills.
Shortlist hardware in the camera finder, step through the whole chain in the configurator, or bring your capture path to us through the contact page. The cameras topic page collects the rest of the capture-path guides.
Questions
Why did full-resolution capture disappear after a reinstall or a driver update?
The vendor runtime and its per-sensor configuration probably did not come back with the reinstall, so only the inbox UVC driver remains and the mode table reverts to 4K. Reinstall the SDK package from the vendor or its distributor, confirm the configuration for your sensor is present, then enumerate the camera inside the SDK instead of the OS camera list.
Can I reuse another sensor's configuration file and just change width and height?
No. A sensor configuration is a register set written for one sensor's timing, PLL and limits, so a mismatched file is rejected with a sensor-mismatch error or returns corrupted frames. Get the file for your sensor from the camera or sensor vendor, or from the distributor you bought through.
Does the UVC still-photo function capture above the streaming maximum?
Only if the device declares a separate still-capture resolution larger than its streaming modes. Some UVC cameras do; many declare the same 4K ceiling for stills, and some declare no still pin at all. Read the descriptor: if no larger still size is listed, the SDK path is the only route to full resolution.
Do USB3 Vision cameras need a special interface card or driver?
No. A standard USB 3.0 port is enough; connect the camera directly to the host rather than through a hub, and use a cable rated for USB 3.0. Throughput varies slightly between host controllers, so plan frame rates around 400 MB/s of usable payload rather than the theoretical 500 MB/s.
Does MJPEG compression let a UVC camera stream above 4K?
Compression changes the bandwidth math, not the descriptor: if the mode table lists no mode above 3840 × 2160, no compressed or uncompressed stream exceeds it. MJPEG's role is letting large declared modes fit the link; measurement-critical work still belongs on the native path with uncompressed frames.