YUV Camera Modules: Why YUV422 Is the Default Output
Updated: 7 hours ago
A team specifies a 20MP module, writes their pipeline against RGB, and then finds the host spending most of its budget converting frames instead of processing them. The camera was never the bottleneck. The format was.
Every processed frame leaving a camera has to be encoded somehow, and that choice sets your bandwidth, your latency, and how much work your host does before it can start. Most embedded modules settle on one answer.
This post covers what a YUV camera actually outputs, why YUV422 became the default, how it compares to RAW and MJPEG, and which Vadzo modules deliver it. If you are choosing between YUV cameras and RAW ones, the decision is about where the processing happens.
Most YUV camera modules on the market share one answer, and understanding why makes the rest of the specification straightforward. For a YUV camera for embedded systems, that answer is usually the deciding factor in your host budget.
What a YUV Camera Outputs and Why the Format Exists
Answer first: a YUV camera outputs color video already converted out of the sensor’s native Bayer pattern, encoded as one brightness channel and two color channels rather than three color channels.
Y is luma, meaning brightness. U and V are chroma, meaning the color difference components. Together they describe the same picture RGB does, but split along a line that matches how human vision works.
That split is the whole point. Your eye resolves brightness detail far better than color detail, so the two chroma channels can be sampled at lower resolution without a visible difference. RGB has no equivalent structure to exploit.
So asking what a YUV camera is really asking where the color processing happened. A YUV output camera has already run demosaicing, white balance, and color correction on board, and hands your host something it can display or process immediately.
The alternative is raw Bayer, where the sensor’s mosaic goes to the host untouched, and your software does that work. Both are legitimate. They put the effort in different places.
What Is YUV422 and How Chroma Subsampling Works
YUV 4:2:2 samples luma at full resolution and the two chroma channels at half horizontal resolution. That is the notation: four luma samples, two of each chroma, per block.
Work out what that saves. Full RGB at 8 bits per channel costs three bytes per pixel. YUV422 costs two. You have removed a third of the data before anything else happens.
The other common ratios sit either side. YUV 4:4:4 keeps chroma at full resolution and costs the same as RGB. YUV 4:2:0 halves chroma both horizontally and vertically for 1.5 bytes per pixel, which is what most video codecs use internally.
Why 4:2:2 is the sweet spot for cameras. Chroma subsampling at 4:2:0 loses vertical color resolution, which shows on fine colored detail and diagonal edges. YUV422 halves only horizontally, keeps every line of color information, and still cuts a third of the data.
That balance is why what is YUV422 has become the standard format rather than a niche one, and why every Vadzo module with an onboard ISP outputs it. An onboard ISP YUV pipeline hands the host finished frames, which is what most YUV camera modules are built to do.
YUV vs RAW: Where Should the Processing Happen?
This is an architecture decision, not a quality one. Both paths start from the same sensor.
A YUV camera does the work on the module. Demosaicing, white balance, noise reduction, and color correction run in the camera's ISP, so your host receives finished frames. Integration is quick, and host load is low.
A raw camera hands you the sensor data. You control every step, which matters when you are training a model or need color science the ISP does not offer. Your host pays for it in compute.
The byte count misleads here. Raw Bayer at 8 bits is one byte per pixel against YUV422's two, so raw looks cheaper on the wire and costs more everywhere else, because the host has to demosaic every frame before it can do anything useful.
YUV vs RAW resolves toward YUV when you want frames now and your host is busy with the application, which covers most embedded products. It resolves toward RAW when you run a custom vision pipeline and need to control the tuning a general-purpose ISP applies for human eyes. Our post on what a camera ISP does covers why that tuning can work against a model.
So why use YUV instead of RAW comes down to schedule and host budget, not image quality. On a busy host, why use YUV instead of RAW usually answers itself: an onboard ISP YUV path removes demosaicing from your application entirely.
YUV vs MJPEG: Artifacts, Latency and Bandwidth
YUV vs MJPEG is a different argument from YUV vs RAW. This one is about compression, not about where the processing happens.
MJPEG compresses every frame with lossy JPEG. The stream shrinks a lot, which is why a USB 2.0 module can carry 1080p at all, and the cost is block artifacts plus an encode stage in your path.
Uncompressed YUV has no encoder at all. A YUV422 frame is a fixed two bytes per pixel; the size never varies, and nothing is added to your latency budget. Raw Bayer is cheaper again at one byte per pixel, but it is the only one of the three that leaves your host to demosaic every frame.
For a YUV camera for machine vision, artifacts decide it. Compression damage lands on edges, and edges are what your algorithm measures, so a YUV camera for machine vision never sees features that were not in the scene. The same holds for a YUV camera for embedded systems doing any measurement task.
YUV Bandwidth and Frame Rate: The Calculation
Run the arithmetic before you choose a resolution, because YUV bandwidth is what decides whether your target frame rate is achievable.
Multiply width by height by two bytes by frame rate. That is your stream in bytes per second, and multiplying by eight gives bits.
A worked example. 1920 × 1080 at 30fps in YUV422 is 1920 × 1080 × 2 × 30, which is about 124 MB/s, or roughly 995 Mbps. Already over USB 2.0, before protocol overhead.
Now scale it. 4K at 3840 × 2160 at 30fps in YUV422 is about 498 MB/s, near 4 Gbps, which needs USB 3.2 Gen 1 or four MIPI lanes and leaves little headroom.
YUV frame rate is the lever most people forget. Bandwidth scales linearly with it, so halving frame rate halves the stream exactly. If 4K at 30fps does not fit your link, 4K at 15fps often does, which makes YUV frame rate the cheapest variable in the YUV bandwidth equation.
The same arithmetic explains the resolution ceiling on each interface. A MIPI YUV camera has lane count to trade against, so a four-lane MIPI YUV camera carries what a two-lane one cannot. A USB YUV camera has a fixed speed grade instead, and a USB YUV camera on USB 2.0 will not carry uncompressed 1080p at all. Our USB Type-C camera guide covers where those limits sit.
YUY2, UYVY and NV12: Which YUV Format Should You Use?
YUV422 sets the sampling ratio, not how the samples sit in memory, and that layout is what your driver cares about. YUY2 format, also written YUYV, is packed and interleaved, Y, U, Y, V along each row, and has the widest support in UVC cameras. UYVY format is the same data with the order swapped to U, Y, V, Y, identical in content, but feed one to a pipeline expecting the other, and you get the classic color-swapped image. NV12 format is 4:2:0 and planar, luma first, then interleaved chroma, which is why video encoders prefer it. So which YUV format should I use? It's normally YUY2 for a UVC YUV camera, on driver support alone, though confirm what your framework expects, because the conversion is trivial and forgetting it costs an afternoon. Color space conversion to RGB is a fixed matrix operation, cheap per frame on most hosts, and RGB vs YUV is a representation difference at 4:4:4 rather than a quality one, trading a little chroma resolution for a third less data at 4:2:2.
Does YUV Lose Image Quality?
Answer first: YUV 4:4:4 loses nothing at all. YUV422 discards half the horizontal chroma resolution, and in almost every real scene that is invisible.
The loss is real but narrow. It shows on saturated color edges with no brightness difference across them, which is rare outside test patterns and some graphics content.
What matters more for YUV image quality is what the ISP did before the conversion. Noise reduction, sharpening, and color correction all change the image far more than chroma subsampling does, which is the argument our ISP guide makes in detail.
A useful way to put it. If you can see the difference between 4:4:4 and 4:2:2 in your scene, you almost certainly need raw output and your own processing anyway. If you cannot, YUV422 is free bandwidth.
So does YUV lose image quality is a fair question with a boring answer: yes, in a way that is measurable and seldom matters.
Which Vadzo Modules Output YUV
Every Vadzo module with an onboard ISP outputs YUV422 across both USB and MIPI CSI-2. The consistency is deliberate; you can change the sensor without changing how your host receives frames.
The lineup is split into three tables below by resolution tier, because bandwidth is what usually decides your shortlist. Every module has its own row. Falcon modules are USB and Bolt modules are MIPI CSI-2, so where the same sensor appears on both, you can prototype on one and ship on the other without changing your output format.
High Resolution YUV Camera Modules: 8MP to 20MP
Module | Sensor | Resolution | Shutter | Buy Now |
Falcon-2020CRS | onsemi AR2020 | 20MP | Rolling | |
Bolt-2020CRS | onsemi AR2020 | 20MP | Rolling | |
Falcon-1335CRA | onsemi AR1335 | 13MP / 4K | Rolling | |
Bolt-1335CRS | onsemi AR1335 | 13MP / 4K | Rolling | |
Bolt-415CRS | Sony IMX415 | 8.46MP / 4K | Rolling | |
Falcon-830CRS | onsemi AR0830 | 8MP | Rolling | |
Bolt-822CRS | onsemi AR0822 | 8MP / 4K HDR | Rolling | |
Falcon-821CRS | onsemi AR0821 | 8MP / 4K | Rolling | |
Bolt-821CRS | onsemi AR0821 | 8MP / 4K | Rolling |
This tier is where the arithmetic bites. 4K at 30fps in YUV422 is close to 4 Gbps, so confirm your interface before you fix on a sensor.
5MP YUV Camera Modules
Module | Sensor | Resolution | Shutter | Buy Now |
Falcon-544CRS | onsemi AR0544 | 5MP | Rolling | |
Bolt-544CRS | onsemi AR0544 | 5MP | Rolling | |
Falcon-522CRS | onsemi AR0522 | 5MP | Rolling | |
Falcon-521CRS | onsemi AR0521 | 5MP | Rolling | |
Bolt-521CRS | onsemi AR0521 | 5MP | Rolling | |
Falcon-5640CRA | OmniVision OV5640 | 5MP | Rolling |
5MP is the tier most embedded products land on. It carries enough detail for inspection and document work while still fitting a single link at useful frame rates.
2MP and 1080p YUV Camera Modules
Module | Sensor | Resolution | Shutter | Interface | Buy Now |
Falcon-246CRS | onsemi AR0246 | 2.3MP HDR | Rolling | USB | |
Bolt-246CRS | onsemi AR0246 | 2.3MP HDR | Rolling | MIPI CSI-2 | |
Falcon-235CGS | onsemi AR0235 | 2.3MP | Global | USB | |
Bolt-235CGS | onsemi AR0235 | 2.3MP | Global | MIPI CSI-2 | |
Falcon-234CGS | onsemi AR0234 | 2MP / 1080p | Global | USB | |
Bolt-234CGS | onsemi AR0234 | 2MP / 1080p | Global | MIPI CSI-2 | |
Falcon-233CRS | onsemi AR0233 | 1080p HDR | Rolling | USB | |
Bolt-233CRS | onsemi AR0233 | 1080p HDR | Rolling | MIPI CSI-2 |
Both global shutter options sit in this tier, and so do two of the three HDR sensors. It is the tier for motion and for difficult lighting rather than for detail.
Global shutter is the narrowest filter. Only the AR0235 and AR0234 modules in the 2MP table are global shutter, so if anything moves during exposure, your shortlist is the Falcon-235CGS, Bolt-235CGS, Falcon-234CGS, and Bolt-234CGS. Everything else is a rolling shutter and will skew a moving subject.
Start from bandwidth, not resolution. Run the YUV422 arithmetic for your target frame rate first, then pick the table it lands you in. A 20MP module streaming YUV is a large amount of data, and the link often decides the sensor before the application does.
For an HDR scene, the Bolt-822CRS in the first table and the AR0246 and AR0233 modules in the third carry HDR while still delivering standard YUV422 output, so dynamic range costs you nothing in integration effort.
Frequently Asked Questions
What is a YUV camera?
A YUV camera is a camera module that outputs color video encoded as one luma channel and two chroma channels rather than three RGB channels. Asking what a YUV camera is really asks where the color processing happened, because a YUV output camera has already run demosaicing, white balance, and color correction in its onboard ISP. Your host receives frames it can display or process immediately, with no demosaicing to perform. The alternative is raw Bayer output, where the sensor mosaic goes to the host untouched. Every Vadzo module with an onboard ISP delivers YUV422 across both USB and MIPI CSI-2, so YUV camera modules in the Falcon and Bolt ranges present identically to your host.
What is YUV422 and why is it used?
YUV 4:2:2 samples brightness at full resolution and the two color channels at half horizontal resolution, which is where chroma subsampling gets its name. Answering what YUV 4:2:2 is in practical terms: it costs two bytes per pixel against three for full RGB, so you remove a third of the data before anything else happens. The reason it works is that human vision resolves brightness detail far better than color detail. YUV 4:2:0 saves more but loses vertical color resolution too, which shows in fine detail. Understanding YUV bandwidth follows from it directly: two bytes per pixel times resolution times YUV frame rate. Vadzo standardises on YUV422 across the whole ISP-processed range, so output format stays constant when you change the sensor.
Should I choose YUV or RAW output?
The YUV vs RAW decision is about where the work happens, not about quality, since both start from the same sensor. Choose uncompressed YUV when you want working video quickly, and your host is busy with the application, which describes most embedded products. Choose raw Bayer when you are running a custom vision pipeline or training a model, because standard ISP tuning is optimised for human eyes and can strip texture your model relies on. Raw is one byte per pixel on the wire, but costs host compute to demosaic, which is why an onboard ISP YUV path suits a YUV camera for embedded systems with a busy application. Asking why use YUV instead of RAW usually comes down to schedule. The YUV vs MJPEG question is separate, since MJPEG adds compression artifacts a YUV camera for machine vision cannot tolerate. Vadzo offers both, so you can evaluate a YUV camera module and a raw variant on the same sensor.
Does YUV lose image quality?
At 4:4:4, nothing is lost at all. At YUV422, you lose half the horizontal chroma resolution, and asking does YUV lose image quality gets the honest answer that it is measurable and seldom visible. The loss shows on saturated color edges with no brightness difference across them, which is rare outside test charts. What affects YUV image quality far more is the noise reduction and sharpening the ISP applies beforehand. If the difference is visible in your scene, you probably need raw output and your own color science, and the RGB vs YUV representation question is separate from quality entirely. Vadzo also supplies raw variants.
Which YUV format should I use?
For most designs, the answer to which YUV format should I use is YUY2, because it has the widest driver support and is what a UVC YUV camera normally presents. UYVY format carries identical data with the byte order swapped, and feeding one to a pipeline expecting the other produces the classic color-swapped image. NV12 format is 4:2:0 and planar, which suits video encoders rather than vision pipelines. Confirm what your framework expects before you write the capture code. Color handling is unaffected either way, since color space conversion to RGB is a cheap matrix operation. Vadzo’s Falcon USB YUV camera range and Bolt MIPI YUV camera range both deliver YUV422 in YUY2 format, so the layout stays consistent whichever interface you choose, and YUV cameras across the lineup behave the same to your driver.
