MIPI CSI camera resolution limits: verify the host

A high-resolution Bayer camera can fit within a host's advertised pixel count and still be incompatible. The receiver may reject its image height, lack enough lane bandwidth, or have no supported driver for that sensor mode. This guide is for engineers choosing an embedded camera before purchasing hardware. You will build a compatibility budget for a hypothetical 3264 × 2448 RAW10 stream at 30 fps, then identify the documentation and bench evidence needed to approve it.

Start with the complete camera mode

MIPI CSI camera resolution limits are properties of the complete acquisition path, not just the processor's headline specification. Approve a particular camera mode only when the sensor output, board wiring, receiver, driver and downstream processing agree.

The closest starting point is the CSI camera carrier-board compatibility checklist. Use it to establish the electrical connection before calculating throughput. A matching connector does not establish matching pin assignments, signaling or software support.

Record the proposed mode in a short requirements table:

Treat missing entries as unresolved requirements. A statement such as “supports 4K” does not answer these questions.

Check width and height separately

Pixel count is useful for estimating data volume, but receivers can impose independent width, height and line-length limits. The image processor may impose different limits from the CSI receiver or capture engine.

For example, 3840 × 2160 contains 8,294,400 pixels. The proposed 3264 × 2448 mode contains 7,990,272 pixels, which is fewer overall. However, its height is 2448 lines rather than 2160 lines. A height limit could therefore reject the smaller-megapixel image.

Check the documented limits at every stage:

• Maximum active width and height for the selected format.
• Line-buffer capacity and required width alignment.
• Maximum input pixel rate or processing clock requirements.
• Capture-engine stride, frame-size and buffer-allocation limits.
• Image-processor limits when using hardware demosaicing.
• Restrictions that change with multiple active streams.

A receiver's maximum width and maximum height are not necessarily supported together at every frame rate. Look for a supported operating envelope or an explicitly documented mode.

If the camera supports a smaller sensor window, cropping before transport can reduce both dimensions and payload. Cropping after capture does not solve an input limit.

Calculate the CSI-2 lane budget

Bayer RAW10 represents one 10-bit sample per photosite. It is not three 10-bit color channels per pixel. Full RGB values are normally generated later by demosaicing.

For an initial estimate, calculate the active-image payload before adding transport overhead. The following calculation assumes D-PHY data lanes and uses decimal units: one Gb/s is one billion bits per second.

For the proposed mode:

Dividing that payload gives approximately 1.20 Gb/s per lane across two lanes, or 0.60 Gb/s across four lanes. These values are lower bounds, not approved operating rates.

CSI-2 packet overhead, embedded data, transmission timing and implementation restrictions can raise the required lane rate. Sensor output may also arrive in bursts rather than at the frame-average rate. Use the camera's documented lane-rate setting for final compatibility, not just this division.

As an illustrative planning assumption, reserve 20% of aggregate link capacity:

That reserve is a chosen design allowance, not a universal CSI-2 overhead factor or a guarantee. The supported camera timing remains decisive.

Four lanes help only when the camera, receiver, carrier wiring and driver all support that configuration. A four-lane receiver cannot recover four-lane capacity through a connector that routes only two lanes.

Distinguish wire packing from memory bandwidth

RAW10 packing on the link does not guarantee packed storage in host memory. Standard packed RAW10 carries four samples in five bytes, but a capture driver may expose each sample in a 16-bit container.

For the example width, the ideal packed row contains:

Actual row stride can be larger because of alignment or padding. Read the negotiated stride and buffer size rather than assuming either expression describes the allocated buffer.

The following table excludes padding and uses decimal MB:

These rates describe different points in the pipeline. They should not be substituted for one another when checking the physical link or memory subsystem.

Consider a simple path that writes unpacked raw frames to memory, reads them for demosaicing, and writes RGB output:

An additional full RGB read adds about 719.1 MB/s. Buffer copies, other applications and memory-controller overhead increase contention further. Hardware processing paths may avoid some transfers, so map the actual architecture before adding every possible operation.

The RGB frame-rate and pixel-format guide explains why raw transport and processed color output can have different throughput limits. If you retain four unpacked raw buffers, their image payload alone is approximately 4 × 15.98 = 63.9 MB; allocation overhead is additional.

Verify driver and image-processor support

Electrical compatibility does not create a working capture driver. Confirm support for the exact sensor, host operating-system release, carrier board and requested mode.

Ask for a supported mode table showing resolution, frame rate, lane count, lane rate and pixel format together. A driver that supports a lower-resolution mode is not evidence that arbitrary larger dimensions will work. Sensor register programming, receiver configuration and capture timing must all agree.

Check these software details before ordering:

• The sensor driver exposes the requested mode without undocumented modifications.
• The receiver accepts the sensor's CSI-2 data type and virtual-channel assignment.
• Pipeline stages negotiate compatible media-bus and memory formats.
• The image processor supports the Bayer pattern, bit depth and dimensions.
• Required firmware, tuning files and software licenses are available through authorized channels.
• Applications can access the resulting frames on the intended processor architecture.

A Bayer-order mismatch can produce incorrect color even when frame transport works. A packing mismatch can produce apparent stripes, shifted values or unexpected buffer sizes.

Use the pipeline format-negotiation troubleshooting guide when adjacent stages disagree. For supplied application libraries, also check ARM64 acquisition binary compatibility. A functioning kernel driver does not make a library built for another architecture usable.

Ask for evidence at the intended operating point

The strongest pre-purchase evidence is a documented, supported configuration matching your proposed mode. If that evidence is incomplete, arrange an evaluation before committing to the design.

Start by capturing raw frames without display, demosaicing or storage. Then add processing stages individually. This separates receiver capacity from application throughput.

A useful evaluation sequence is:

1. Read back the negotiated dimensions, format, stride and buffer size.
2. Confirm the actual sensor mode, lane count and lane rate.
3. Capture continuously while checking receiver errors and frame sequence numbers.
4. Measure completed frames over a defined interval, such as 60 seconds.
5. Add demosaicing, display and recording separately, repeating the measurement.
6. Repeat with the other workloads expected on the deployed host.

At 30 fps, a 60-second interval should contain about 1800 frames. Measure after startup transients, and distinguish completed capture buffers from display refreshes. Define acceptable losses and latency before calling the evaluation successful.

If acquisition never starts, follow the MIPI CSI no-image diagnostic sequence. If capture starts but falls behind, use the camera frame-rate bottleneck guide to separate exposure, transport and processing restrictions.

Know when another interface is the better choice

A direct CSI connection is attractive when the sensor, carrier and software stack are already supported together. It can be the wrong choice when the project depends on an undocumented mode or substantial driver development.

Compare complete integration effort, not connector size alone. The board-level camera category includes options for embedded packaging, while area scan cameras provide another route to a complete acquisition interface. Use the camera finder to compare interface, shutter and mounting requirements.

The following products are USB3 alternatives, not CSI modules or evidence of compatibility with a particular CSI receiver.

The LS-BCM-0003 is a USB3 board-level camera with a C-mount and global shutter. It is a candidate when board-level packaging matters, but its supported modes still need to match the inspection task.

The LS-CMR-0166 is a USB3 area scan camera with a rolling shutter. Evaluate motion distortion as well as acquisition requirements before choosing it.

Neither alternative should be treated as a drop-in replacement for the hypothetical Bayer mode. Recheck resolution, exposure, frame rate, optical coverage and software support independently. A passive cable does not convert CSI-2 signaling into USB3 acquisition.

USB3 also has host-controller and buffering limits. The USB3 throughput and latency checks are useful when evaluating that alternative.

Complete the compatibility checklist before ordering

Approve the camera only after each requirement has a documented answer or an agreed evaluation result:

• Exact mode: Width, height, frame rate and RAW format are specified together.
• Physical connection: Lane wiring, pin assignments and required electrical conditions match.
• Lane capacity: The documented operating rate fits both endpoints with justified margin.
• Receiver dimensions: Width, height, alignment and packet handling are supported.
• Software path: Sensor driver, receiver configuration and format negotiation support the mode.
• Processing path: Bayer handling and image-processor limits match the intended output.
• Memory budget: Stride, buffer count, copies and competing traffic are included.
• Verification: Sustained capture has been measured with the intended processing workload.

A lower frame rate can reduce average payload, but it does not automatically reduce the sensor's lane rate or remove a height limit. Likewise, adding lanes cannot repair unsupported driver programming. Change the constraint that actually fails, then recalculate and verify the new mode.

Bring the completed mode table to the camera configurator, or request compatibility support with the host documentation and required output format. The useful purchasing question is not simply how many megapixels the host accepts, but which complete camera mode it can acquire and process reliably.