In-camera JPEG compression: why machine vision cameras stay raw

Three hardware-triggered cameras running 30 frames per second each can drown a host that has to encode JPEG on the fly, so the tempting fix is to have the camera compress before it sends anything. Industrial cameras almost never do that. What follows is why they stay raw, what a JPEG payload would change in your data, and where the bandwidth should come from instead: the arithmetic for a three-camera budget, the fixes ranked by effort, and the one case where asking the camera maker for special JPEG firmware is worth a support ticket.

What a machine vision camera actually puts on the wire

Industrial area scan cameras stream uncompressed pixel data. The GenICam pixel formats printed on a data sheet — Mono8, BayerRG8, RGB8, YUV422 — are raw sensor values packed into bytes, with no encoder between the sensor and the network port. GigE Vision and USB3 Vision define how those bytes are packetized and delivered; they assume the camera sends what the sensor produced. Your acquisition library reassembles the packets into frames and hands you raw pixels. Compression, when it happens at all, happens after that: in your code, on your CPU or GPU, at your expense. That is why the host in a three-camera rig does all the JPEG work. The camera has no encoder to hand the job to.

What JPEG would change in the pixel values

JPEG is lossy by design. It cuts the image into 8 × 8 blocks, transforms each block into frequency coefficients, and quantizes them, so pixel values shift by several gray counts even at high quality. Two consequences matter for inspection. Measurements that read pixel values move: sub-pixel edge detection, gray-level thresholds and defect contrast all change, because JPEG trades exact values for file size. And bit depth caps at 8 bits: a 12-bit sensor's extra precision disappears from the JPEG file, along with the ability to re-threshold the scene later. For a record image a human reviews, that trade is often acceptable. For the stream that decides pass or fail, raw pixels are the only values you can defend — which is why the industry default has stayed raw.

Why in-camera JPEG is rare

The GigE Vision 2.0 standard added payload types for compressed image formats such as JPEG, but cameras implementing them are close to nonexistent in industrial catalogs: data sheets list Mono8 and Bayer formats, not JPEG. A small number of camera models can be re-flashed with a special JPEG firmware that the maker supplies for that specific model through its support channel. It is an exception you ask for, not a feature you select from a dropdown. If you want to try that route, put three questions to the camera maker's support before designing around it: does the firmware exist for your exact model, what pixel data does the JPEG stream carry (8-bit only?), and does your acquisition SDK accept that payload. The answer is usually no, which brings you back to the arithmetic below.

The bandwidth budget for three cameras at 30 fps

Worked example: a common 5 MP sensor (2448 × 2048) in Mono8, three cameras, each hardware-triggered at 30 fps.

• One frame: 2448 × 2048 × 1 B = 5,010,432 B ≈ 5.0 MB
• One camera: 5,010,432 B × 30 fps = 150.3 MB/s
• Three cameras: 3 × 150.3 MB/s = 451 MB/s, which is 3.6 Gb/s of payload

A 1 Gb/s Ethernet port carries 125 MB/s on paper and about 118 MB/s of usable GigE Vision payload once protocol overhead is paid. 451 ÷ 118 = 3.8, so this budget needs four 1 Gb/s ports — or one faster link, or less data. JPEG at a typical 10:1 would pull 451 MB/s down to about 45 MB/s, one port with room to spare. That ratio is exactly what makes in-camera compression attractive, and exactly what the camera refuses to do.

At 20 MP the same budget breaks a single GigE port by itself: 20,000,000 px × 30 fps × 1 B = 600 MB/s, five times one port's 118 MB/s. The MV-CS200-10GC is a 20 MP color camera on GigE with a C-mount, and this is the math that decides what it connects to.

Cut the budget where the pixels are made: ROI, binning, pixel format

Shrinking the frame at the camera scales the whole budget linearly, adds no hardware, and leaves the surviving pixels untouched.

• ROI. If the part plus handling margin covers a 1200 × 1000 window instead of the full frame: 1200 × 1000 × 1 B × 30 fps = 36 MB/s per camera, 108 MB/s for three. That fits one tuned 1 Gb/s port with 10 MB/s of headroom (118 − 108); add a second port if a fourth camera is coming. Cropping on the camera also cuts host-side copying — the mechanics are in Camera ROI cropping at the source.
• Binning. 2 × 2 binning merges pixels four at a time: 5 MP becomes 1.25 MP and the 150.3 MB/s camera drops to 37.6 MB/s. Resolution halves along each axis, so use it where the feature you inspect is large relative to the pixel.
• Pixel format. Mono8 and raw Bayer carry 1 byte per pixel; RGB8 carries 3 and YUV422 carries 2. Streaming color as RGB8 triples the bill for data the host usually converts anyway — keep the wire format in Bayer and debayer after capture only if the decision needs color.

When the inspection watches several separate windows, the same arithmetic per window is worked through in Multi ROI camera capture: the frame rate arithmetic.

Get more out of the network you already have

Jumbo frames raise the MTU from 1500 to 9000 bytes and cut the packet count per frame about sixfold (9000 ÷ 1500 = 6). Fewer packets mean fewer interrupts and less CPU per frame on the host, and usable throughput climbs toward the port's 118 MB/s ceiling.

Triggered bursts differ from continuous streams: at 30 fps continuous the average rate is what matters, and the camera's on-board buffer absorbs short bursts that overshoot the link, which is the subject of Camera burst capture faster than link bandwidth: use the buffer. If the host also falls behind on processing, Acquisition faster than processing: fix the frame rate gap shows how to measure where the time actually goes. Otherwise, the sane default is one full-rate camera per 1 Gb/s port, on a dedicated NIC or separate subnets so three cameras never queue behind one another.

Move to a link that fits the budget

Usable rates assume jumbo frames enabled and nothing else sharing the port; treat them as planning values for sizing.

5GBASE-T sits between GigE and 10GigE on ordinary structured cabling; the cable and distance limits are covered in 5GBASE-T camera interface: bandwidth, cables and distance. For 10GigE, the MV-CH250-25TC-F-NF pairs a 25 MP global-shutter sensor with a 10GigE link on an F-mount. A 25 MP Mono8 frame at 30 fps is 750 MB/s (25,000,000 px × 30 × 1 B), which only a 10GigE or CoaXPress link carries in the first place.

On USB3, a port runs at 5 Gb/s and real streams reach 350–400 MB/s of it. Three cameras at 150.3 MB/s each fit on two ports (451 ÷ 2 ≈ 226 MB/s per port, inside the ceiling). Host-side tuning matters too: USB3 camera low frame rate and latency: fix usbfs memory and exposure covers the Linux buffer setting that silently caps multi-camera USB3 rigs. The MV-CH120-11UC is a 12 MP global-shutter camera on USB3. At full 30 fps its Mono8 stream is 360 MB/s (12,000,000 px × 30 × 1 B) — the top of one port's usable range — so an ROI or a second port belongs in that plan.

CoaXPress replaces the network port with a frame grabber and moves about 1,250 MB/s per CXP-12 link, up to four links per camera; Frame grabber image acquisition for Camera Link and CoaXPress walks through how the grabber side acquires.

Inspect at the camera and send results, not frames

The largest bandwidth saving is the data you never transmit. A smart camera runs the inspection on a processor inside the camera body and outputs pass/fail, measurements and coordinates — kilobytes per trigger instead of megabytes. The route stops helping when every frame must be archived centrally or measured on the host; those stations stay on the raw-data links above. For trigger-and-decide stations, the LS-SMC-0017 runs an 8.8 MP global-shutter sensor with an x86 platform behind a C-mount, so a lens you already own can move onto the camera along with the decision. Browse the smart cameras and vision sensors category for the rest of the range.

When in-camera JPEG is genuinely the right answer

Three cases survive lossy compression. Archiving for human review: records stored for traceability compress well, but keep the raw frame for any part that fails, so the evidence stays exact. Training-data collection: many detection models train happily on JPEG-encoded frames, though captures that feed a measurement should stay raw. Host GPU encoding: when the workflow needs JPEG output and exact values for the inspection, encode after acquisition on a GPU — modern GPU encoders typically process hundreds of 5 MP frames per second, an order of magnitude past a single-threaded CPU loop. That host needs spare cores and a free PCIe slot; machines built for round-the-clock duty are listed under industrial mini PCs.

The true in-camera route stays as described above: a special JPEG firmware the camera maker supplies for specific models, requested through support. Ask before you architect around it, and plan around the raw stream if the answer is no.

Checks before you commit

1. Compute the budget for your own cameras: width × height × bytes per pixel × fps × number of cameras.
2. Compare it with the usable rates: 118 MB/s per 1 Gb/s port, 350–400 MB/s per USB3 port, 1,180 MB/s per 10GigE port.
3. Size the ROI from the part plus handling margin, and confirm the optics still cover the full tolerance band.
4. Set jumbo frames end to end — camera, NIC, every switch — before measuring throughput.
5. Give each 1 Gb/s camera its own port by default, and pace the triggers if bursts would exceed the link.
6. Stream Mono8 or Bayer rather than RGB8 unless color decides the inspection.
7. Archive JPEG, but store the raw frame for every rejected part.

If you are sizing a system from scratch, start from the sensors: the area scan cameras category, the camera finder or the camera configurator, which steps through sensor, interface and port count in order. More acquisition-side guides sit on the systems topic page.