You plug in a USB camera whose page promises 16 megapixel stills, open the Windows Camera app, and the resolution list stops at 1920 × 1080. A browser tab shows the same ceiling. Nothing is broken: the camera is a USB Video Class (UVC) device, and UVC offers exactly the formats its firmware wrote into the USB descriptors, while consumer apps show a short, safe subset of that list. This explainer covers why 1080p sits at the top of the list, what the bandwidth arithmetic allows on each USB link, how many measurement pixels the default mode costs you, and how to enumerate and select every format the camera carries — plus the point at which the right answer is an industrial camera.
The decision first
Three cases cover nearly everyone who hits this wall:
| What you need | What to do |
|---|---|
| 1080p-class streaming, plug and play | Nothing is wrong. Use the default mode. |
| Full sensor pixels occasionally — one still per part | Enumerate all formats with a real capture tool, pick the largest frame size, accept single-digit frame rates. |
| Full pixels continuously, hardware trigger, control from your own code | A UVC module is the wrong part. Buy an industrial USB3 or GigE area scan camera. |
For the third row, browse area scan cameras or open the camera finder and filter by resolution. For the first two, read on: the missing pixels are usually one descriptor entry away.
What UVC actually advertises
A UVC camera hands the host a set of USB descriptors: a video-streaming interface, then format descriptors, then frame descriptors that each hold a frame size, a list of frame intervals and a marked default. The operating system trusts that list — there is no negotiation beyond it — and every capture option on your PC is built from it. The specification defines a short menu of uncompressed pixel formats — YUY2, NV12, M420 and I420 in version 1.5 — plus compressed streams such as MJPEG and H.264 (USB video device class formats).
Firmware authors put a 1080p MJPEG entry at the top because it plays on every port, OS and app at a usable frame rate. The sensor's full size is usually in the list too: as a larger frame size under the same format, as a separate format block, or on the still-image capture endpoint that rides alongside a video mode. Apps built on the standard media pipeline surface the first entries, and the still endpoint goes unused — on cameras like this, both the Windows Camera app and browser-based viewers stop at the entry marked default.
One layer down sits a different list with a different cause: the sensor's own binned and skipped readout modes, covered in how sensor resolution modes work. A UVC module exposes only the subset its bridge firmware translated into descriptors. If you build the device side yourself, those descriptors are exactly what you write when configuring UVC modes on a Linux USB gadget.
The bandwidth arithmetic behind the default
Uncompressed YUY2 at 1080p and 30 fps needs about 995 Mbit/s, above the 480 Mbit/s a USB 2 link carries — which is why the default entry is MJPEG, compressed to a fraction of that. One full 4656 × 3496 frame is 32.6 MB, so continuous full-resolution capture wants a USB 3 link. Vendors that expose the full size over video usually list it as an MJPEG entry, since compression is the only way it fits alongside the other modes. Budget for MJPEG artifacts on fine edges when you set your margin.
What the default mode costs you at the part
Put the loss in physical units. The part is a circuit board 140 mm across the frame, and the smallest feature that matters is a 100 μm pad. The working rule is three pixels across the smallest feature for measurement, two as the floor for detection.
| Mode | Detail per pixel | Pixels on a 100 μm pad | Verdict |
|---|---|---|---|
| 1920 × 1080 (default) | 72.9 μm/px | 1.4 | Detection at best |
| 4656 × 3496 (full) | 30.1 μm/px | 3.3 | Measurable |
For that board the mode switch is not optional: at the default you can see the pad exists, at full size you can measure it. Feed your own field of view and smallest feature to the calculator below and it sizes the pixel count the task demands.
A second, quieter loss is aspect ratio. The sensor's 4656 × 3496 is 4:3; 1920 × 1080 is 16:9. A 16:9 video mode on a 4:3 sensor crops top and bottom, keeping 4656 × 2619 — about 12.2 of the sensor's 16.3 MP. If the part is taller than it is wide, the crop can hide more than the resolution drop does.
How to reach every mode the camera carries
- Put the camera on a USB 3 port with a USB 3 cable. The advertised list stays the same on a slow link, but the large modes fail when you select them, and that failure reads as a missing mode.
- Open the camera in software that enumerates every media type on the capture pin: a capture-capable media player, a DirectShow or Media Foundation enumeration tool on Windows, or a video4linux2 device listing on Linux. The Camera app and browser pages are the wrong instruments here.
- Select format, frame size and frame interval as one set. Asking a capture stream for a width and height snaps the driver to the nearest advertised frame size, so an app that never offers the big size never selects it. When a request comes back at a lower mode, diagnosing rejected USB camera modes separates a bandwidth refusal from a bad request.
- Expect the pairing rule: the larger the frame size, the shorter the interval list. A full-size entry offering one or two frames per second is normal hardware, not a fault — why a frame-rate mode can be missing covers where that list comes from.
- Try still-image capture where the tool offers it. On many modules that is the full-resolution path: stream a small preview, trigger one full frame per part — the pattern behind full-resolution capture alongside a low-resolution preview. If the stream refuses to start at all once you force a mode, begin at getting a UVC camera streaming with no config file.
- Stop when two full enumeration tools on two machines agree on the same short list: nothing above 1080p advertised means the firmware does not contain it. No PC-side setting adds formats to a fixed device list — the same reason a camera's pixel format will not change.
When the answer is a different camera
Some bridge chips list one uncompressed 1080p entry plus MJPEG and nothing above. The number of frame sizes a module can offer is fixed when sensor and USB bridge are chosen, and no driver changes it. If you need every pixel continuously, with a hardware trigger and format control from your own code, move to the machine-vision side: an industrial camera publishes its full format list through a standard feature description your software reads directly, with no consumer media pipeline choosing a default for you.
The LS-CMR-0166 is a 12 MP USB3 area scan camera, IMX226, 4000 × 3000 at 30 fps.
- Sensor format
- 1/1.7"
- Interface
- USB3
- Resolution
- 12 MP
- Shutter
- Rolling
Where the enclosure is tight, board-level cameras bring the same direct control on a bare board. The LS-BCM-0003 is a 3.1 MP USB3 board-level camera with the IMX252 global shutter at 120 fps.
- Sensor format
- 1/1.8"
- Lens mount
- C-mount
- Interface
- USB3
- Resolution
- 5 MP
And when no PC belongs in the loop at all, smart cameras and vision sensors capture and judge on board, so the resolution question is settled on the sensor page and the line only receives a pass/fail verdict.
Checks before you spend another hour
- USB 3 port and cable on the machine that will run the line, not only the bench PC.
- Enumeration by a tool that lists every media type — never the Camera app.
- Frame size and frame interval requested together, as one setting.
- Aspect ratio matched to the part: 4:3 full mode against the 16:9 crop.
- μm per pixel computed at the mode you will actually run, not the one on the box.
- Two tools, two machines, same short list: the limit is in the firmware.
When the decision is a new camera, run the system configurator from the camera step: the resolution you settle on there is the one your software can select. More host-side capture problems are collected under the systems topic.
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 my 16 MP USB camera only show 1920x1080 in the Camera app?
Consumer apps present the format entry the camera marked as default, plus a small subset of its neighbors. The sensor's larger frame sizes sit further down the descriptor list or on the still-image capture endpoint, and those apps never query either. Enumerate all media types with a capture-capable tool and select the frame size explicitly; the pixels are there unless the firmware omits them.
Does plugging into a USB 3 port raise the resolution by itself?
No. The format list comes from the camera's firmware, not from the port. USB 3 matters for bandwidth: uncompressed 1080p at 30 fps is about 995 Mbit/s, above the 480 Mbit/s of USB 2.0, so full-size modes only stream over USB 3. The mode must first be advertised and then selected, so a faster port alone changes nothing the app shows.
How do I list every resolution a UVC camera supports?
Use software that walks every media type on the capture pin: a capture-capable media player or a DirectShow and Media Foundation enumeration tool on Windows, or a video4linux2 listing on Linux, where the driver reports each frame size per node. If two such tools agree the list stops at 1080p, the firmware contains nothing above it.
Is full-resolution capture slower than 1080p video?
Usually. A 4656 × 3496 frame in YUY2 is 32.6 MB, roughly eight 1080p frames, so the frame rate falls accordingly, often to single digits. Modules that pair the full size with a still-image endpoint deliver one frame per trigger rather than continuous video; plan one capture per part and time the cycle before you commit.
When should I stop troubleshooting UVC and buy a machine-vision camera?
When you need full sensor resolution continuously, deterministic triggering, or format selection from your own code. Industrial USB3 and GigE cameras publish every format through a standard feature description the software reads directly, with no consumer app deciding the default; smart cameras go further and run the inspection on board, sending only a pass/fail verdict.