Industrial cameras

What makes a camera "industrial"

Industrial machine-vision cameras are built around a different set of priorities than consumer or broadcast cameras. They expose raw, uncompressed image data; they accept hardware triggers so a capture can be locked to a sensor, encoder or PLC signal; and they speak standardised protocols (GenICam over GigE Vision, USB3 Vision, CoaXPress or Camera Link) so any compliant software can drive them. The housing, connectors and mounting are designed for fixed installation on a machine, often with industrial temperature ratings and lockable cabling, rather than for handheld use.

Just as important is what they leave out. There is usually no autofocus, no auto-exposure guessing and no in-camera image "enhancement", because a vision system needs deterministic, repeatable images, not pretty ones. The lens is a separate, deliberately chosen optic; the lighting is engineered for contrast; and exposure and gain are set and locked. Treat the camera as one link in an imaging chain (lens, lighting, interface, processing) rather than a self-contained device, and the selection process becomes far clearer.

Across this catalogue the camera brands are Basler, iRAYPLE and Omron/Sentech (STC), with Datalogic/Datasensing strongest in code readers and vision sensors. All of them offer multiple sensor formats and interfaces, so the right starting point is the requirement, not the badge: define what the system must see and how fast, then let that shortlist the models.

The sub-types, and what each one is for

The most fundamental split is area scan versus line scan. An area-scan (matrix) camera captures a complete 2D frame in one exposure and suits discrete parts that can be presented and triggered one at a time; it is the default for the large majority of inspections. A line-scan camera images one pixel-row at a time and builds the picture as the material moves past, which is the right tool for continuous web, strip and foil, for rotating or cylindrical surfaces that must be unwrapped, and for very wide products that need uniform high resolution across the full width.

Within the area-scan world, two further families are called out because they push specific axes. High-resolution cameras prioritise pixel count and fine pixel pitch to resolve small features over a large field of view; they demand matching optics and a high-bandwidth interface, and they are sized from the field of view and the smallest defect rather than chosen for headline megapixels. High-speed cameras prioritise frame rate, freezing fast motion and keeping up with rapid sorting or production lines; they typically pair a global shutter with strobed lighting and a fast interface such as CoaXPress.

Beyond conventional 2D imaging sit the specialist families. 3D cameras capture height or shape (via laser triangulation, stereo or time-of-flight) for volume, flatness, bead and assembly checks that a flat image cannot make. SWIR and UV cameras image outside the visible band to reveal what visible light hides, moisture and fill levels under packaging, sub-surface features, or coatings and contamination that only fluoresce or absorb in the UV. Embedded and board-level cameras are stripped-down modules for OEMs and engineering teams building vision directly into their own machines, where size, cost and integration matter more than a finished enclosure.

• Area scan: discrete, triggered parts; the default 2D camera for presence, gauging, OCR/OCV and surface checks.
• Line scan: continuous web, strip, cylindrical or very wide material; needs encoder sync and intense line lighting.
• High resolution: fine detail over a large field of view; size from FOV and smallest defect, match the lens to the pixel pitch.
• High speed: fast frame rates to freeze motion and keep line pace; usually global shutter plus strobe and a fast interface.
• 3D: height/shape data for volume, flatness, coplanarity and assembly verification a 2D image cannot provide.
• SWIR/UV: imaging beyond visible light for fill level, moisture, sub-surface or fluorescence/contamination checks.
• Embedded/board-level: OEM integration where size, cost and a custom enclosure drive the choice.

How to navigate to the right sub-type

A reliable route through this category is to answer four questions in order, working from the application down rather than from the spec sheet up. First, what is the geometry and motion of the part? Discrete items you can trigger point to area scan; continuous, rotating or very wide material points to line scan; features that depend on height or shape point to 3D. Second, what is the field of view and the smallest feature you must detect reliably? Dividing the FOV by the detail size, then allowing roughly 3 to 5 pixels across that smallest feature, tells you whether a standard sensor suffices or whether you are in high-resolution territory.

Third, how fast must the camera deliver images without dropping frames, and is anything moving during exposure? Throughput pushes you toward high-speed sensors and faster interfaces, while motion during exposure makes a global shutter effectively mandatory. Fourth, does visible light actually reveal the feature? If contrast is impossible in the visible band, that is the signal to consider UV or SWIR rather than fighting it with more pixels or brighter visible lighting. Only after these four answers does interface, GigE Vision, USB3 Vision or CoaXPress, fall out naturally from the resulting data rate and cable run.

Use the subcategory grid on this page as the destinations for that decision: the four questions route you to area scan, line scan, high resolution, high speed, 3D, SWIR/UV or embedded, and the deeper guides linked below carry the detail for each fork. If your application sits on a boundary, a part that is fast and high-resolution, or a wide web that also needs 3D, it is worth resolving deliberately rather than defaulting to a familiar sub-type.

• Geometry and motion first: discrete and triggered -> area scan; continuous/rotating/wide -> line scan; shape-dependent -> 3D.
• Then detail: (FOV / smallest feature) x 3-5 px tells you if you need a high-resolution sensor.
• Then speed and motion: high frame rate -> high-speed cameras; motion during exposure -> global shutter.
• Then waveband: if visible light cannot create contrast, consider UV or SWIR.
• Interface (GigE/USB3/CoaXPress) is an output of data rate and cable run, not a starting point.

Remember the rest of the imaging chain

Whichever sub-type you land on, the camera alone does not determine image quality. The lens must cover the chosen sensor format, hit the working distance and magnification your field of view requires, and resolve detail finer than the pixel pitch, otherwise extra megapixels are simply wasted. For dimensional gauging, a telecentric lens removes the perspective error a standard entocentric lens introduces. Lighting frequently decides whether a defect is visible at all: the geometry (ring, dome, backlight, coaxial, dark-field or line) is chosen to maximise contrast on the specific feature, and it must be bright and stable enough for the short exposures that speed and motion demand.

The interface and processing close the loop. Resolution multiplied by frame rate and bit depth sets the data rate, which selects GigE Vision (moderate rate, long reach, PoE), USB3 Vision (higher rate, short cable, single camera) or CoaXPress (multi-GB/s with a frame grabber for high-speed and line-scan work). Size the link above your peak rate, not at it, and confirm the host has the CPU or GPU headroom to process every frame within the cycle time. Where the inspection itself is hard, subtle cosmetic defects or decisions that resist rule-based logic, a deep-learning layer such as Rosepetal can sit on top of correctly specified hardware, and AIS Vision can validate or integrate the complete chain when you want the whole station signed off rather than just a camera shipped.