High-resolution cameras

When high resolution is the right answer (and when it is not)

The case for a high-resolution camera is built from two numbers: the field of view you must cover and the smallest feature you must reliably resolve. Divide one by the other, allow roughly three to five pixels across that smallest feature, and you have a target pixel count per axis. When that target lands beyond what a standard 5-12 MP sensor can deliver, you are genuinely in high-resolution territory. Typical drivers are large parts inspected whole at fine detail (electronics assemblies, full PCBs, display panels), metrology where sub-pixel edge fitting demands dense sampling, and semiconductor or wafer work where the feature size is simply tiny.

Before committing, test the cheaper alternatives honestly. If the part can be split into zones inspected in sequence on a stage, a smaller sensor with multiple acquisitions may cost far less in optics and processing. If the object moves continuously and is long or cylindrical, a line-scan camera often delivers effective resolution that no area sensor can match across a web. A high-resolution area-scan camera is the right answer specifically when you need the whole field at once, frozen in a single exposure, at a detail level a smaller sensor cannot reach. Choosing it for any other reason usually means paying the high-resolution tax — in lenses, bandwidth and compute — without the benefit.

• Size it from the application: (field of view / smallest detail) x ~3-5 px per feature = required pixels per axis.
• Genuine drivers: large part inspected whole at fine detail, metrology edge-fitting, semiconductor and display feature sizes.
• Check the alternatives first: a stage with a smaller sensor, or line scan for continuous/long material, may be far cheaper.
• Reserve large-format area scan for when you truly need the full field, in one exposure, at detail a smaller sensor cannot reach.

The optics challenge: image circle, MTF and pixel pitch

This is where high-resolution projects most often fail. A large sensor demands a lens that covers its full diagonal — its image circle — without darkening or softening at the corners. Many familiar C-mount lenses are specified for sensors up to around 1 inch; a 20-25 MP or larger sensor frequently needs a larger format and a correspondingly larger mount (F-mount, M42, M58 or similar) just to be covered at all. Mount a sensor whose diagonal exceeds the lens image circle and you get vignetting and a blurred, low-contrast border that no software can recover. Confirm image-circle coverage before anything else.

Coverage is necessary but not sufficient. A large sensor at high pixel count has very small pixels, often in the low single-digit micron range, and the lens has to resolve detail at that pitch — across the entire frame, corner to corner, at the working aperture you intend to use. This is an MTF (modulation transfer function) question, not a megapixel-rating question: the lens must deliver adequate contrast at the spatial frequency your pixel pitch implies (roughly line pairs per millimetre equal to 1000 / (2 x pixel pitch in microns)). A sensor that out-resolves its lens simply spreads each real detail over several pixels — you store more data but see no more. Diffraction sets a hard ceiling too: stopping a lens down to gain depth of field eventually blurs fine detail (the diffraction spot grows past the pixel), so high-resolution systems often run at moderate apertures and recover depth of field through fixturing instead.

For metrology, telecentric lenses remove the perspective error that makes a part appear to change size with distance, but large-format telecentric optics are bulky and expensive because the front element must be at least as large as the field of view. Plan optics and budget together: at this resolution the lens can cost as much as the camera, and a cheap lens on an excellent sensor is the single most common way to waste the investment.

• Image circle first: the lens must cover the full sensor diagonal, or you get corner vignetting and blur.
• Large sensors usually need a larger mount than C-mount (F-mount, M42, M58) to be covered at all.
• Judge the lens on MTF at your pixel pitch, corner to corner, at the working aperture — not on its megapixel label.
• Mind diffraction: stopping down for depth of field eventually softens fine detail past the pixel.
• Telecentric optics for gauging, but expect large-format telecentric lenses to be bulky and costly.

Bandwidth and interface: moving the data without dropping frames

A high pixel count multiplies the data rate fast. A single 25 MP frame is around 25 MB at 8-bit, doubling near 50 MB at the 10-12 bit depths metrology often needs, and at even modest frame rates the resulting stream overwhelms ordinary interfaces. This is why the category is built around CoaXPress and 10GigE rather than standard GigE or USB3. The interface choice is dictated by the product of resolution, frame rate and bit depth, and it should be sized comfortably above your peak rate — running a link near its ceiling is how high-resolution systems acquire intermittent dropped frames that are miserable to debug on a line.

CoaXPress (CXP-12, and multi-link configurations) delivers multiple gigabytes per second over coax and is the workhorse for the fastest, largest sensors, at the cost of a frame grabber in the host and the slot, cabling and cooling that implies. 10GigE (NBASE-T / 10GBASE-T) reaches similar usable throughput over standard Ethernet with longer cable runs and no grabber, trading some host-side complexity for simpler, more distributed cabling — attractive when the camera sits far from the PC or when several cameras feed one network. Both are well represented in the catalog across Basler, iRAYPLE and Omron/Sentech (STC); let the required bandwidth and cabling topology drive the choice rather than the badge. Whichever you pick, verify the host can actually sustain the rate: PCIe lane allocation, NIC capability, CPU and storage all have to keep up with the camera, or the bottleneck simply moves downstream.

• Estimate the load: resolution x bit depth x frame rate. A 25 MP frame is ~25 MB at 8-bit, ~50 MB at 12-bit, before frame rate.
• CoaXPress (CXP-12, multi-link): highest throughput, needs a frame grabber — for the fastest, largest sensors.
• 10GigE / NBASE-T: comparable usable bandwidth over standard Ethernet, longer runs, no grabber.
• Size the link above peak data rate, and confirm the host (PCIe lanes, NIC, CPU, storage) can sustain it.

Lighting uniformity across a large field

Illumination problems that are invisible at low resolution become glaring across a large, finely-sampled field. A big sensor covers more physical area, so any falloff, hotspot or gradient in the lighting is spread across millions of pixels and shows up as a shading pattern that masks low-contrast defects and shifts measured edge positions. The larger the field of view, the harder it is to light it evenly, and the more the lens's own corner falloff (natural vignetting, which worsens with field angle) adds to the problem.

Treat uniformity as a first-class requirement, not an afterthought. Favour lighting geometries that flood the whole field evenly — large diffuse or dome sources, properly sized backlights for silhouette and dimensional work, sometimes tunnel or coaxial arrangements for flat specular parts — and size the illuminated area generously beyond the field of view so you are using the flat centre of the light, not its falling edge. Short exposures, which large high-resolution sensors often need to freeze motion or hit a cycle time, demand a lot of light, so plan for strong, stable, ideally strobed sources synchronised to the trigger. Where residual non-uniformity remains, flat-field (shading) correction calibrated against a uniform reference can normalise the response, but it is a correction layer on top of good optics and lighting, never a substitute for them.

Single high-res vs multi-camera, and the processing cost

When one sensor cannot cover the field at the detail you need, the real decision is between one larger sensor and several smaller ones tiled across the field. A single high-resolution camera keeps the system mechanically and softwarely simple — one acquisition, one image, one calibration — but pushes the difficulty into the optics (a lens that covers and resolves a large format) and into a heavy per-frame data and processing load. A multi-camera array uses cheaper, more available sensors and lenses and spreads the bandwidth across links, but adds the engineering of mounting and aligning several cameras, synchronising their triggers, and stitching or registering the images into a coherent result. For very wide fields, multiple cameras (or line scan) are often the only practical route; for a compact field that simply needs dense sampling, one large sensor is usually cleaner.

Whichever path you take, budget for what happens after acquisition, because it is routinely underestimated. Large images are expensive to move, store and process: every algorithm runs over far more pixels, so inspection cycle times, memory footprint and CPU or GPU load all scale with resolution. A 50 MP frame is not five times the work of a 10 MP frame in isolation — host transfer, decoding, and any deep-learning inference can scale faster than linearly depending on the pipeline. If a deep-learning stage such as Rosepetal sits downstream, factor the inference cost of full-resolution images explicitly; tiling, region-of-interest cropping or running detection at reduced scale and confirming at full scale are common tactics to keep cycle time in budget. The honest comparison is total cost of ownership — camera plus optics plus grabber or NIC plus the compute to process every frame in time — not the price of the camera alone.

• Single large sensor: simplest pipeline and calibration; hardest optics and heaviest per-frame load.
• Multi-camera array: cheaper sensors/lenses and split bandwidth; adds alignment, sync and image-stitching work.
• Very wide field favours multiple cameras or line scan; compact field needing dense detail favours one large sensor.
• Budget the processing: transfer, memory, CPU/GPU and any AI inference all scale with pixel count — size compute to cycle time.