Your inspection hands you a bounding box for every part and a connected region underneath it, and both come with an area. They are not the same number, and on a rotated part they are not close: a 120 × 80 px part tipped to 45° reports a box area of about 20,000 px², while the part itself still covers 9,600 px². By the end of this page you can compute both values, predict the gap for any rotation angle from one formula, and decide which number each task in your cell should use — gating, sizing, coverage or picking.
What each area measures
A bounding box is the smallest axis-aligned rectangle that contains a region. Blob tools and detectors store it as a corner point plus a width and a height, all in pixels, so its area is simply w × h in px². Some libraries also emit a rotated minimum-area rectangle; every number in this guide concerns the axis-aligned default.
The object area is the pixel count of the connected component itself: every pixel that survived thresholding under the same label. Blob analysis reports it directly as the region's area feature, in the same px² units.
One inequality always holds: A_box ≥ A_obj. Equality means the part fills its box completely — an axis-aligned solid rectangle. Rotation, irregular outlines and holes all leave empty pixels inside the box, which makes box area an upper bound on the part, never a measurement of it.
The pixel counting behind that region area is the same operation as blob area in a binary image, so a pipeline that already counts blobs already holds the true number.
The rotation formula and the 45° worst case
When a rectangular part rotates by θ away from the image axes, its axis-aligned box grows even though the part does not. The geometry is one line each:
Three consequences fall straight out of the last line. Overstatement peaks at θ = 45°, where sin(2θ) peaks. A square part exactly doubles its box area there: 1 + (1 + 1)/2 = 2. And elongation raises the ceiling: a 5:1 strip reaches 1 + (5 + 0.2)/2 = 3.6×.
Near 0° the penalty is close to linear, at (w/h + h/w)·π/180 per degree: 3.5% per degree for a square, 3.8% for a 120 × 80 px part, 9.1% for a 5:1 strip. A fixture that holds a part within ±2° therefore leaves up to about 8% of known box-area bias on common shapes.
The rectangle result is the worst case for any part with that 0° box: a circle's box never grows, and compact shapes grow less. Irregular outlines make the box look worse still — divide the ratio by the fill factor, region area over box area at 0°. A bracket filling 70% of its 120 × 80 px box reads 2.08/0.7 ≈ 3.0× at 45°, not 2.08×.
For elongated parts, a rotated minimum-area rectangle hugs the outline and removes most of this error before you even reach for the pixel count.
Worked example: one part at five angles
Fix a 120 × 80 px solid rectangle — 9,600 px² of part — and rotate it. The pixel count barely moves: rasterization shifts pixels within about half the 400 px perimeter, so the count wobbles roughly ±2% (±200 px²) at any angle. The box area does not stay put. At 30°:
At 45° both sides become (120 + 80) × 0.707 = 141.4 px, so A_box = 141.4² ≈ 20,000 px² — +108%, the worst case for this shape.
| Part angle | Box w × h (px) | Box area (px²) | Pixel count (px²) | Box overstatement |
|---|---|---|---|---|
| 0° | 120 × 80 | 9,600 | ~9,600 | 0% |
| 5° | 126 × 90 | 11,400 | ~9,600 | +19% |
| 15° | 137 × 108 | 14,800 | ~9,600 | +54% |
| 30° | 144 × 129 | 18,600 | ~9,600 | +94% |
| 45° | 141 × 141 | 20,000 | ~9,600 | +108% |
Two decisions come out of the table. If the part can rotate more than a couple of degrees, box area is a presence and position signal, never a size measurement. If the fixture locks rotation to ±2°, sizing with the box carries a known bias of up to about 8% — acceptable for coarse gating, and removed entirely by counting the region.
When boxes double-count: nested and merged regions
Summed box areas fail in a specific way: a parent's box contains its children's boxes, so the shared space is counted two or three times. Take a bracket inspection that labels the bracket plus two inserts sitting inside it:
- Bracket: box 140 × 90 px = 12,600 px², region count 6,900 px²
- Each insert: box 30 × 30 px = 900 px², region count 350 px²
- Naive box total: 12,600 + 900 + 900 = 14,400 px²
- Region-count total: 6,900 + 350 + 350 = 7,600 px²
The box total runs 89% high, because both insert boxes live inside the bracket box. Pixel counts cannot double-count: each pixel carries exactly one label. Keep box containment for assigning inserts to the bracket, and take totals from region areas.
Merging is the mirror problem. When two parts touch, labeling returns one region and the pixel count silently covers both. The fill factor catches it — region area over box area, 6,900/12,600 = 0.55 for the bracket — and a jump in that ratio without a process change means merged parts or a shadow joined the part.
The same nesting trap appears outside vision, in layout work, where station occupied-area and bounding-volume calculations run into the same double counting.
Which area to use, task by task
| Task | Use | Why |
|---|---|---|
| Presence check, position, pick point | Box, its center and area | Stable under rotation; gating rarely needs true size |
| Pass/fail on part size | Region pixel count | Angle-independent; compare in px² or mm² |
| Coverage, dosing, defect size | Region pixel count, calibrated | Counts what the product actually covers |
| Gripper clearance, collision envelope | Box, or rotated box on long parts | The envelope, not the material, is what clears the gripper |
| Sorting elongated parts by size | Rotated min-area rectangle or region count | Axis-aligned box swings with angle |
| Tracker or PLC hand-off | Detector box for position, region count for size | Keep the two sources named in your data |
The rule behind the table: any number that meets a physical quantity — an area, a dose, a coverage percentage — comes from the region; any number that selects, gates or steers can come from the box. A detection network reports boxes in its input-image coordinates, and the network's input sizing changes those coordinates before any area math: object detector input dimensions covers height, width and padding. When one region must yield more than one number, counting lines per region with blob analysis shows how several features come off the same labeled region.
From pixels to square millimeters
Both areas leave the camera in px². To compare against a drawing dimension, multiply by the squared scale:
At s = 0.05 mm/px, each pixel covers 0.05 × 0.05 = 0.0025 mm², so the 9,600 px² part measures 9,600 × 0.0025 = 24 mm². The scale comes from the lens magnification — object-space pixel size — and shifts with every focus or lens swap, so calibrate at the running working distance. Measuring object size from a camera image walks the whole pixel-to-part chain.
The scale fixes units; pixel count fixes noise. The area count is uncertain by roughly half the boundary length in pixels, so a part spanning 60 px across sits at a few percent of area uncertainty, and the same part at 600 px across is tighter by an order of magnitude. That makes part coverage on the sensor a resolution decision, and the calculator turns the smallest feature you must resolve into the pixel count to buy:
Where the counting runs
A counting cell can hold this logic in three places. On the device, a smart camera runs threshold, labeling and both area features on board and hands a result to the PLC — the short loop you want for gating and rejection. Browse the smart cameras range for on-device inspection; a representative pick:
The MV-SC5060XM-08M-WBN is a 6 MP mono smart camera with an 8 mm M12-mount lens on a GigE port.
- Interface
- GigE
- Resolution
- 6-10 MP
- Sensor format
- 1/2.4"
- Shutter
- Rolling
For calibrated areas with records you can archive, count on a PC beside an area scan camera; the area scan cameras range reaches over 25 MP for fine boundaries. Mono sensors keep boundary pixels raw — no demosaicing step blurs the edge you are counting:
The MV-CS200-10UM pairs a 20 MP rolling-shutter mono sensor in 1" format with USB3 and a C-mount.
- Sensor format
- 1"
- Lens mount
- C-mount
- Interface
- USB3
- Resolution
- 16-25 MP
Cells past a couple of cameras add a vision controller: one box takes the camera links and drives the light channels. See the vision controllers category; a current example:
The MV-VC3301H-128G66 pairs an Intel Core i3 with 8 GB of memory, 5+ LAN ports and 4 built-in light channels.
- LAN ports
- 5+ LAN ports
- USB 3 ports
- 3-4 USB 3 ports
- Light outputs
- 4 built-in channels
- Memory
- 8 GB
Checks before you trust an area
Before an area number drives a reject, run these checks:
- Tune the threshold on a live binary image preview; the region count inherits every threshold error.
- Compare region count with part count after labeling. More regions means noise or broken parts; fewer means a merge.
- Log box area, region area and their ratio every part. The ratio is your fill factor — 0.55 for the bracket above — and a jump flags a merge, a shadow or a change in presentation.
- Recalibrate the mm/px scale after any lens, spacer or focus change, because area error grows with the square of the scale error.
- For rotating parts, commit: fixture-lock within ±2° and accept the ~8% known box bias, or measure size with the region count.
- When a detector network feeds the numbers, map its boxes back to full-resolution image coordinates first — the letterbox offset fix covers the common scaling trap.
The habit that pays: store both numbers per part, decide per task which one gates using the table above, and alarm on their ratio. Spec'ing the camera side is the usual next step — the camera configurator walks sensor, lens and trigger choices in order, the systems topic page collects the matching measurement guides, and application questions go through contact.
Questions
Can a bounding box area ever be smaller than the object area?
No. An axis-aligned box spans from the leftmost to the rightmost pixel and top to bottom, so w × h covers every object pixel plus the empty corners; it is always greater than or equal to the pixel count. If your two numbers disagree in that direction, they come from different sources: a detector box scaled on a resized input image next to a blob count on the full-resolution frame. Map both to the same image first.
How accurate is the pixel-to-mm² conversion?
Area goes with the square of the scale, so a 10% calibration error becomes a factor of 1.10² = 1.21 on every area. Calibrate from an artifact of known size at the working distance, aperture and spacer set you will run, and re-check after any lens or focus change. Using 0.05 mm/px when the true scale is 0.055 mm/px turns a true 24 mm² part into a reported 19.8 mm².
How many pixels does a part need for 1% area accuracy?
Budget boundary uncertainty at half the perimeter in pixels and keep it under 1% of the area. For a rectangular part with a 1.5:1 aspect ratio, the perimeter is five times the short side h, so the test reads 2.5h ≤ 0.01 × 1.5h², which solves to h ≥ 167 px. Size the part to roughly 250 × 170 px on the sensor and you hold 1% before threshold noise adds on.
Which area should a coverage or dosing check use?
The region pixel count. Coverage and fill checks compare how many pixels the product actually occupies; box corners would credit the product with area it does not cover. For the 120 × 80 px part at 45°, a box-based coverage read-out reports 20,000 px² against a 9,600 px² expectation and fails good parts; the pixel count reads about 9,600 px² at any angle and passes them.
Why do my detector boxes and my blob counts disagree?
Three usual causes. First, the detector ran on a resized input; its box coordinates map back through the letterbox offset, and skipping that step shifts both position and area. Second, the blob count depends on your threshold: a lower threshold adds boundary pixels and grows the region. Third, touching parts merge into one region, so one count stands in for two objects. Fix the mapping first, then the threshold, then the merge.