Machine vision vs computer vision vs image processing

Machine vision, computer vision and image processing get used as if they were three products on a shelf. They are not: one is a control loop, one is an interpretation method, and one is a toolbox that both of the others consume. The distinction matters when you buy, because it decides where the pass/fail decision runs, which interface must carry the pixels, and how much compute the station needs. This guide gives each term in one sentence, a table that places your task, a worked pixel and bandwidth calculation, and the decision for the common cases.

The three terms in one line each

Image processing changes or measures pixels: denoising, contrast, filtering, thresholding, geometric correction. It produces better input and decides nothing on its own.

Machine vision is the production-loop discipline: calibrated camera, lens and lighting, a fixed trigger, fixed criteria, and an output wired into the process — pass/fail, a reject pulse, or coordinates for a robot.

Computer vision is interpretation: recognizing, classifying and segmenting scenes that are not fixed, usually with models learned from labeled examples.

The buyer's decision hides in that table. A fixed part with enumerable criteria is a machine vision build. An open scene that must be interpreted is a computer vision build. Both run on the same cameras, and both start with image processing.

Machine vision: a calibrated loop that acts

Machine vision earns its keep where timing and repeatability are the product. The camera fires on a trigger, the strobe freezes the part, the tool compares the frame against criteria set once at commissioning, and the result leaves as a discrete output to the PLC within one machine cycle. Nothing in that chain interprets the scene; it detects exactly what it was configured to detect.

The hardware is a matched set. An area scan camera supplies the pixels, a machine vision lens sets the field of view and the resolution on the part, and a strobed light makes the feature measurable — the lighting selection by inspection task guide walks that choice. A smart camera folds sensor, lens mount, light driver and decision logic into one housing, which is why simple checks need no PC at all.

Timing is a spec, not a hope. A 100 µs strobe freezes a part moving at 0.3 m/s to 30 µm of motion blur, well under the 41 µm pixel footprint in the worked example below. For making the whole chain hold its tolerance shift after shift, the stable 2D vision inspection guide is the reference build.

On-board decisions start here: the MV-SC5060XM-08M-WBN carries a 6 MP mono sensor, an 8 mm lens and a GigE port in one housing.

Computer vision: interpretation when the scene is not fixed

Computer vision answers what the rule-based loop cannot: which class does this surface belong to, is this deformable part oriented correctly, is this defect one of a family nobody fully enumerated. It handles fixtureless scenes and natural appearance variation, and it improves as labeled examples accumulate. The cost moves from commissioning engineering to data collection, training and validation before the first part ships.

In production the realistic pattern is hybrid. Rules keep the timing-critical checks — code grade, presence, dimensions — while a learned model takes the classes that resist rules, such as surface defects on castings, welds or food. You can add that layer to cameras already on the line: the AI surface defect retrofit guide shows the path, and the rule-based versus AI comparison helps you decide whether the task needs it at all.

Budget it honestly: plan on hundreds of labeled images per defect class, a retraining pass whenever product or presentation changes, and PC- or GPU-class compute for inference. None of that changes the optics. The camera, lens and light from the machine vision stack serve unchanged.

Image processing: the toolbox both consume

Image processing makes pixels measurable. Flat-field correction removes illumination falloff, thresholding and morphology isolate the feature, undistortion removes lens curvature before you measure, and resizing or binning shrinks the data before it reaches compute. It makes no verdict; a thresholded pixel map is not a pass/fail result until something rules on it.

That is why it is not a third alternative but the first stage inside the other two. A machine vision tool chains it: preprocess, extract, decide. Computer vision consumes it too — 1D barcode preprocessing against rotation, blur and glare is image processing feeding a decode, and undistorting before a dimensional check is the same idea applied to measurement. The machine vision glossary of lens terms keeps the vocabulary straight.

It is also where the easy savings live. Halving each image dimension cuts the pixel count by four, and the page on configuring image resizing in LabVIEW machine vision shows the mechanics. Every pixel removed before processing is bandwidth and compute you never pay for.

Same camera, different build: where the hardware diverges

Point any modern area-scan camera at a presented part and both builds work; the sensor, lens and light do not care what software rules on the frames. The divergence sits in three places.

Where the decision runs. Machine vision favors the edge: a smart camera or a vision controller decides at the line and ships a result. Computer vision favors the PC: it streams full frames upstream and rules there.

Which link carries the pixels. An embedded decision ships bytes; a PC-side build streams every frame, and that budget is arithmetic rather than luck. The page on processing time versus image size covers the failure mode when it is ignored.

How exact the timing is. A trigger-strobe-decide loop lands inside a deterministic window. Learned inference on a shared PC is softer real time, which is why timing-critical rejects stay rule-based even in hybrid lines.

When the PC does the ruling, give it pixels to spare. The MV-CS200-10UM is a 20 MP mono camera on USB3.

Worked example: a 150 mm panel inspected at 30 fps

The case: panels 150 mm wide on a continuous line, inspected at 30 frames per second, smallest defect a 0.15 mm scratch. The inputs and where each comes from:

• Field of view: 150 mm part width plus 10% positioning margin = 165 mm. The margin is your fixture tolerance; 10% is a workable default.
• Smallest feature: 0.15 mm scratch, from the inspection spec.
• Sampling rule: 3 px across the smallest feature, the standard machine-vision rule of thumb. Below about 2 px a feature sinks into threshold noise.
• Sensor class: 12 MP, 4000 × 3000 px, 8-bit mono. Both cameras below print exactly this output.
• Link budgets: about 110 MB/s usable on GigE, about 400 MB/s on USB3 — the 1 Gb/s and 5 Gb/s line rates minus protocol overhead.

The rule in words: object-space pixel size must be at least three times finer than the smallest feature, and the resulting frame stream must fit the interface with headroom.

The arithmetic:

1. Required pixel size: 0.15 mm ÷ 3 px = 0.05 mm/px.
2. Required pixels across the field: 165 mm ÷ 0.05 mm/px = 3,300 px, so a 4,000 px sensor clears it.
3. Actual pixel size: 165 mm ÷ 4,000 px = 0.041 mm/px, and the smallest reliably sampled feature is 3 × 0.041 = 0.124 mm ≈ 0.12 mm. Threshold: if the defect spec tightens below 0.12 mm at this field, this sensor class breaks the 3 px rule and you move up a resolution class.
4. Lens: a 1/1.7" sensor is about 7.4 mm wide, so magnification is 7.4 mm ÷ 165 mm = 0.045. A 25 mm lens then sits at WD = 25 mm × (1 + 0.045) ÷ 0.045 ≈ 581 mm; a 16 mm lens lands near 372 mm. Same method as the object-space pixel size guide, with focal length from the lens focal length calculator.
5. Frame size: 4,000 × 3,000 px × 1 byte = 12 MB per frame.
6. Stream at 30 fps: 12 MB × 30 = 360 MB/s. GigE carries 110 MB/s ÷ 12 MB ≈ 9 fps at this frame size, and USB3 carries the 360 MB/s stream with about 10% headroom.

The decision: 12 MP clears the 0.15 mm spec with real margin (the true limit is 0.12 mm), and 360 MB/s rules GigE out and USB3 in — above about 110 MB/s of stream, leave GigE; above about 400 MB/s, leave USB3 for 10GigE or CoaXPress. So the PC-side build runs a USB3 12 MP camera. If the line slows and 9 fps decides, the GigE model on the same sensor closes the loop at the edge and the PC disappears.

The calculator behind steps 1 to 3:

The USB3 camera for the PC-side build:

The GigE camera when the edge decides at 9 fps:

Which build for which task

Five questions pick the build. The first three point at the machine vision edge; the last two push toward computer vision on a PC.

1. Is the presentation fixed — fixture, stopper, consistent orientation?
2. Are the criteria enumerable: presence, dimension window, code grade, label position?
3. Must the reject leave the line inside one machine cycle?
4. Does appearance vary naturally — castings, welds, food, textile?
5. Can you collect labeled images for the classes that resist rules?

Fixed presentation, enumerable criteria and a hard cycle time: build machine vision — smart camera or area-scan camera, matched lens, strobed light, results straight to the PLC. Natural variability or un-enumerable defect classes: build computer vision on a PC — the same optics, a faster link, a staged rollout where rules keep the timing-critical checks. Most live lines end up hybrid, and the camera does not change; only where the frames go does.

Where each term stops helping

Machine vision will not interpret what it was not configured to detect. A new defect family is invisible until someone adds the check, and a part or presentation change means recalibration. Computer vision does not remove the engineering: without representative labeled images it generalizes badly, and its timing on a shared PC is soft. Image processing decides nothing, and over-filtering erases exactly the faint defects you bought the camera to find — sharpen and denoise with the defect's own contrast in view.

Those are boundaries, not objections. They tell you which discipline owns the decision.

Checks before you order

Run five numbers, all arithmetic on your own task spec:

• Pixel size: FOV ÷ pixels across, then confirm smallest feature ÷ pixel size ≥ 3.
• Stream: pixels per frame × bytes per pixel × fps, against about 110 MB/s on GigE or about 400 MB/s on USB3.
• Lens coverage: image circle at or above the sensor diagonal, and a resolution class that matches the sensor — the lens finder filters both.
• Shutter: global shutter or a strobe for moving parts; rolling shutter only for stopped or strobed presentation.
• Margin: size the field with about 10% positioning margin, and prefer 4 px per feature over 3 when contrast is low.

With the numbers set, the camera configurator pairs sensor and interface, and the applications topic page collects more worked builds. If the decision is still open, send the part, the smallest feature and the line speed through the contact page and we will size the build with you.