You have a 13 MP sensor that outputs 10-bit raw Bayer, and a board that offers two candidate inputs: a MIPI CSI-2 receiver and a USB3 port. The real question is whether picking one locks you out of the pipeline you have planned: debayering to 4K UHD, image stabilization on periodic frames, encoding to NVMe, display on a 4K monitor, and a neural network later. It does not. Both ports deliver the same raw frames, and every stage after capture is software on your host. What the choice changes is bandwidth, where the demosaic runs, and which hosts and drivers accept your sensor. This comparison works the arithmetic for your exact case, then commits to a decision for each way you could build it.
The short answer: neither port limits your processing
Raw Bayer is pixel values with a color filter pattern, and the port is a byte pipe. Whichever input you choose, identical frames arrive: same 13 MP grid, same 10-bit samples, same Bayer pattern. Debayering, stabilization on periodic frames, encoding, display and AI inference all run on the host, so every one of them stays available either way. If you are not yet sure your stack delivers raw Bayer at all, the guide on knowing you have a raw Bayer stream shows the checks. The choice therefore comes down to three engineering variables, not functionality.
What the port actually changes
- Bandwidth ceiling. How many bytes per second the link sustains at full frame rate and bit depth.
- Where the demosaic runs. USB3 delivers raw frames into host memory, so your CPU or GPU debayers them; CSI-2 feeds the SoC's image signal processor, which demosaics in hardware.
- Host and driver support. A USB3 camera works with any PC that has a USB3 host; a CSI-2 sensor must be supported by the SoC's receiver, ISP and camera stack.
Everything else — frame formats, stabilization, encode, AI — is downstream software and behaves the same on both ports.
Bandwidth, CPU and support side by side
The table uses MB/s for one million bytes per second and assumes the common lane arrangements: four CSI-2 data lanes at 1.5 Gbit/s each, USB3 at 5 Gbit/s, USB 3.1 Gen2 at 10 Gbit/s.
| MIPI CSI-2, 4 lanes at 1.5 Gbit/s | USB3, 5 Gbit/s | USB 3.1 Gen2, 10 Gbit/s | |
|---|---|---|---|
| Line rate | 750 MB/s | 625 MB/s | 1,250 MB/s |
| Practical payload | about 640 MB/s | 400-450 MB/s | 1,000-1,100 MB/s |
| 13 MP 10-bit packed at 30 fps (488 MB/s) | fits, about a quarter headroom | does not fit | fits with margin |
| 13 MP 10-bit unpacked at 30 fps (780 MB/s) | does not fit | does not fit | fits |
| Demosaic runs on | the SoC ISP, in hardware | your CPU or GPU | your CPU or GPU |
| Host support | SoC camera stack; the sensor must be supported | any USB3 host, standard camera stack | host, cable and camera must all do 10 Gbit/s |
On USB3 the host spends interrupt and copy time on every frame and then debayers on the CPU or GPU. On CSI-2 the receiver writes frames into memory without host CPU cycles while the ISP demosaics, white-balances and denoises inline, which leaves the processor free for stabilization, encoding and AI. The load after the demosaic is identical either way: a 4K UHD RGB display stream at 30 fps moves 3840 × 2160 × 3 bytes × 30 = 746 MB/s through memory, no matter which port delivered the raw data.
Worked example: 13 MP, 10-bit Bayer at 30 fps over each port
The inputs: 13,000,000 pixels (your sensor, taken at its 13 MP rating); 10 bits per pixel (your sensor's raw output); 30 fps (your 4K UHD display target); packed 10-bit, which stores four pixels in five bytes and costs 1.25 bytes per pixel, against 2 bytes per pixel for unpacked 10-bit in a 16-bit word.
The arithmetic:
- Packed 10-bit: 13,000,000 px × 1.25 bytes = 16.25 MB per frame; × 30 fps = 487.5 MB/s, call it 488 MB/s.
- Unpacked 10-bit: 13,000,000 × 2 × 30 = 780 MB/s. 8-bit: 13,000,000 × 1 × 30 = 390 MB/s.
- USB3 at 5 Gbit/s: 5,000 Mbit/s ÷ 8 = 625 MB/s of line rate; 8b/10b coding consumes a fifth, leaving 500 MB/s; protocol overhead brings sustained practical throughput to 400-450 MB/s.
- USB 3.1 Gen2 at 10 Gbit/s: 1,250 MB/s of line rate; 128b/132b coding leaves about 1,212 MB/s, and hosts sustain roughly 1,000-1,100 MB/s.
- CSI-2 on four lanes: 4 × 1,500 Mbit/s ÷ 8 = 750 MB/s of line rate; about 15% for packet headers and sync leaves roughly 640 MB/s of payload.
Result: the 488 MB/s packed stream fits a four-lane CSI-2 receiver with about a quarter headroom, fits a 10 Gbit/s USB port comfortably, and does not fit a 5 Gbit/s USB3 port, whose 400-450 MB/s practical ceiling sits below the demand.
The decision rule, for any sensor: below about 350 MB/s of sustained payload, a good 5 Gbit/s USB3 host has comfortable margin; from 350 to 450 MB/s, 5 Gbit/s works only with packed formats and a controller measured at the bench; above 450 MB/s, plan a 10 Gbit/s USB port or a four-lane CSI-2 receiver at 1.5 Gbit/s per lane. If you must stay on 5 Gbit/s with this sensor, drop to 8-bit at 30 fps (390 MB/s) or keep 10-bit at 25 fps (487.5 × 25 ÷ 30 = 406 MB/s); both squeeze under a measured 450 MB/s ceiling with little room to spare.
Where the demosaic runs decides your CPU headroom
On USB3 the raw frames land in host memory and your software debayers them — straightforward on a PC with a GPU, expensive on a small embedded board, where the demosaic can eat most of the frame budget. On CSI-2 the SoC ISP demosaics, white-balances and denoises in hardware, so your code receives a finished RGB stream and keeps the CPU for the stabilization loop, the encoder and the AI network. Most SoC camera stacks can also hand you raw frames on request when the stabilization algorithm wants them; the MIPI CSI ISP inline processing guide explains how that pipeline is arranged. One CSI caution: a receiver without an ISP leaves you raw frames and no hardware demosaic, which moves the whole debayer onto your GPU — the raw sensor output explainer covers that case.
Host support comes before the bandwidth math
CSI-2 is a board-to-board link, so support is fixed at design time: the SoC receiver must accept the sensor's lane count, data type and per-lane rate. The per-lane rate fails more often than the lane count: in one documented bring-up, a sensor streaming 1.728 Gbit/s per lane exceeded the 1.5 Gbit/s its D-PHY supported and had to be lowered to 1.44 Gbit/s per lane. Re-run the budget after such a cut: four lanes at 1.44 Gbit/s give 720 MB/s of line rate, about 612 MB/s of payload, still enough for the 488 MB/s stream. The platform compatibility guide for MIPI camera modules walks the sensor-support question.
When a CSI stream runs and then times out, the cause is usually power, clocking or device-tree setup rather than bandwidth; the CSI camera timeout troubleshooting guide walks that pattern.
USB3 support is easier to get: any PC or vision box with a USB3 host runs a standard camera stack. What varies is sustained rate: controllers spread across the 400-450 MB/s range, so measure on the exact host and cable before you commit. On embedded boards, also confirm the port is not negotiating USB 2; the USB3 camera fallback troubleshooting guide lists the usual causes.
Which port for which case
A custom device around an embedded SoC, tight space, CPU reserved for stabilization and AI: choose MIPI CSI-2 with four lanes at 1.5 Gbit/s per lane. The 488 MB/s stream fits with about a quarter headroom, the ISP absorbs the demosaic, and the short flex stays inside the housing. Confirm the sensor in the SoC camera stack first; that check decides the project before any bandwidth math does.
A camera on a PC or vision controller, standard tooling, interchangeable optics: choose USB3, matched to the numbers. For 13 MP 10-bit at 30 fps you want a 10 Gbit/s port; on a measured 5 Gbit/s host, 8-bit at 30 fps (390 MB/s) fits and packed 10-bit sits at the top of the range. Cameras in this class are standard products: the LS-CMR-0166 streams 4000 × 3000 at 30 fps over USB3, and the MV-CS200-10UM gives you 20 MP over USB3.0 on a 1" sensor if the inspection needs more pixels. Shortlist the rest in the area scan camera range or the camera finder.
- Sensor format
- 1/1.7"
- Interface
- USB3
- Sensor format
- 1"
- Lens mount
- C-mount
A sensor inside your own housing, no SoC ISP in the plan: a board-level module is the middle path. The shop's board-level cameras are USB3 or GigE modules you mount and cable, for example the LS-BCM-0003, a 3.1 MP USB3 board camera with global shutter at 120 fps, or the MV-CB060-10UM-B, a 6 MP bare-board USB3 camera on an IMX178 sensor. A native MIPI sensor is specified from your SoC vendor's supported-sensor list instead.
- Sensor format
- 1/1.8"
- Lens mount
- C-mount
- Sensor format
- 1/1.8"
- Interface
- USB3
Checks before you order
- Pixel formats. Get the camera's format list and confirm a packed 10-bit option exists; without one, the stream needs 780 MB/s, which only a 10 Gbit/s port carries.
- Measured host throughput. Run a known stream on the exact host controller and budget from the measured number.
- CSI lane budget. Lanes × lane rate must clear 488 MB/s of payload after overhead: 4 × 1.5 Gbit/s gives about 640 MB/s, and 4 × 1.44 Gbit/s still gives about 612 MB/s.
- Cable run. USB3 passive copper reaches roughly 3 m at 5 Gbit/s and nearer 1 m at 10 Gbit/s; CSI-2 flex belongs inside one housing, typically well under 30 cm.
- Configure the pair. The camera configurator pairs sensor, mount and interface in one pass.
When the standard answer is wrong
A driver that delivers unpacked 16-bit. It doubles the stream to 780 MB/s and blames the port. Pack on the wire, unpack after the copy; the packed Bayer acquisition debugging guide shows how to confirm what you actually receive.
GigE as the fallback. At 1 Gbit/s, GigE carries 125 MB/s of line rate, a quarter of the 488 MB/s demand, so it is out for this sensor at full rate; the host bandwidth budget for two GigE cameras shows the same arithmetic at GigE scale.
A MIPI-native sensor on a PC host. CSI-2-to-USB bridge hardware can connect the two, but the bridge's own budget becomes the limit; size that path with the CSI-2 to USB bridge bandwidth guide.
The decision for the case in front of you: a 13 MP 10-bit sensor feeding debayer, stabilization, encode and AI fits a four-lane CSI-2 receiver at 1.5 Gbit/s per lane on an embedded SoC, or a 10 Gbit/s USB port on a PC; on 5 Gbit/s USB3, run 8-bit at 30 fps or 10-bit at 25 fps, never full-rate packed 10-bit. If you want the budget checked against specific parts, send the sensor, the host and the target frame rate through the /contact/ page; every order includes free expert support.
Questions
Does MIPI CSI-2 carry more bandwidth than USB3?
With four data lanes at 1.5 Gbit/s each, MIPI CSI-2 moves 750 MB/s of line rate, roughly 640 MB/s of payload after packet overhead. USB3 at 5 Gbit/s carries 625 MB/s of line rate and sustains about 400-450 MB/s. A four-lane CSI-2 receiver therefore beats a 5 Gbit/s USB3 port, while a 10 Gbit/s USB port at roughly 1,000-1,100 MB/s beats both.
Does the port choice change what my stabilization, encoder or AI network can do?
No. Both ports deliver identical raw Bayer frames, and debayering, periodic-frame stabilization, encoding and inference are host software either way. The port decides where demosaic cycles are spent: a CSI-2 ISP does it in hardware and frees the CPU, while a USB3 host pays for the debayer in CPU or GPU time. Nothing downstream is gated by the port.
How much NVMe space does a raw 13 MP 10-bit stream consume?
At 30 fps the packed stream is about 488 MB/s, roughly 1.75 TB per hour (487.5 MB/s × 3,600 s = 1.755 TB). Encode before writing: a 4K30 encode at a typical 20-50 Mbit/s writes 2.5-6.25 MB/s, about 80-200 times less, so the drive holds days of footage instead of hours.
What happens if my camera only offers unpacked 10-bit over USB3?
Unpacked 10-bit stores each sample in a 16-bit word, so the same sensor at 30 fps demands 780 MB/s, which neither a 5 Gbit/s USB3 port nor a four-lane CSI-2 receiver carries. Check the camera's format list for a packed 10-bit option, or fall to 8-bit or 25 fps to fit the link.
Can I stream two 13 MP 10-bit cameras on one host?
Two packed streams add to about 975 MB/s. A single 10 Gbit/s port sustains roughly 1,000-1,100 MB/s, which is too tight to trust; give each camera its own controller, or split them across CSI-2 and USB if the board offers both. Five-gigabit ports cannot carry even one such stream at full rate.