In OpenCV, how do you get each blob's area and centroid from a binary mask?

## The two APIs and what each is really for After thresholding and morphological clean-up you have a binary mask, and the next question is always the same: how many objects, how big, and where. OpenCV offers two paths. **Contours** (`cv2.findContours` + `cv2.moments` and friends) give you an ordered boundary curve, which unlocks shape: perimeter, convexity, polygon approximation, rotated bounding boxes, shape matching. If you need to know that something is a hexagon, you need contours. **Connected-component labeling** (`cv2.connectedComponentsWithStats`) gives you a label image plus a statistics table in a single pass. It answers count, pixel area, bounding box and centroid directly, and it hands back `labels`, an integer image you can compare against to build a per-blob mask instantly. If you need to know how many blobs there are and how big each is, this is the shorter and usually faster road. ## Moments in practice `cv2.moments(array, binaryImage=False)` accepts either a contour or a single-channel image and returns a dict of 24 values. The names follow a convention: `m00`, `m10`, `m01`, `m20`, ... are raw moments; `mu20`, `mu11`, `mu02`, ... are central moments (translation invariant); `nu20`, `nu11`, ... are normalized central moments (also scale invariant). The two you use daily: - `m00` is the area. For a contour, it equals `cv2.contourArea` of the same curve. - The centroid is `cx = m["m10"] / m["m00"]`, `cy = m["m01"] / m["m00"]`. Intuitively, a raw moment is a coordinate-weighted sum; dividing by the total weight gives the mean position. The mandatory guard is `m00 == 0`. It happens more often than people expect: a contour of a single pixel, a perfectly collinear run of pixels, or a degenerate curve produced by aggressive approximation. In Python that is a `ZeroDivisionError` in the middle of a frame loop, so filter contours by `cv2.contourArea` before measuring, or test `m00` explicitly. When you pass an *image* rather than a contour, `binaryImage=True` makes every non-zero pixel count as 1 instead of contributing its intensity - that is the flag to set for masks, and forgetting it on a 0/255 mask scales the moments by 255 (the centroid survives, the area does not). The higher moments are not decoration. `cv2.HuMoments(m)` derives seven values invariant to translation, scale and rotation, which `cv2.matchShapes` uses to compare two contours regardless of pose - the classical answer to "is this the same part." ## Connected components in practice ``` n, labels, stats, centroids = cv2.connectedComponentsWithStats(binary, connectivity=8) ``` `n` is the number of labels **including the background**, so the object count is `n - 1`. `labels` is an `int32` image where each pixel holds its component's label. `stats` has shape `(n, 5)`; use the named column constants rather than integers: `cv2.CC_STAT_LEFT`, `CC_STAT_TOP`, `CC_STAT_WIDTH`, `CC_STAT_HEIGHT`, `CC_STAT_AREA`. `centroids` has shape `(n, 2)` in float64, so centres are subpixel. **Row 0 is the background**, and it is the single most common bug on this API: iterate from 1, and if you sort blobs by area without dropping row 0 the background wins every time, because it is usually the largest region in the image. `connectivity` is 8 by default (diagonal neighbours join) or 4 (only orthogonal). This is a real decision, not a formality: two blobs touching only at a corner are one component under 8-connectivity and two under 4-connectivity. On thin diagonal structures, 4-connectivity fragments them. Building a mask for one blob is then a one-liner: `mask = (labels == i).astype(np.uint8) * 255`, which is far cheaper and more exact than redrawing a contour. ## Why the two areas disagree This distinction is worth stating precisely because it decides pass/fail in real inspection systems. `m00` and `cv2.contourArea` integrate the **polygon** traced by the contour, via Green's theorem. Consequences: the value includes any holes inside the shape, and because the polygon runs through boundary pixel centres it differs from a raw pixel count by roughly a half-pixel band around the perimeter - a few percent on small blobs. `stats[i, cv2.CC_STAT_AREA]` is a literal count of pixels carrying that label. Holes are excluded automatically, since hole pixels belong to a different component. So for a washer, the contour route reports the full disc and the labeling route reports the material. Neither is wrong; they answer different questions. If your spec says "surface area of material," take the pixel count. If it says "footprint," take the polygon. ## Bounding geometry `cv2.boundingRect(cnt)` returns `(x, y, w, h)`, an axis-aligned box - the same information as the four `CC_STAT_*` columns. `cv2.minAreaRect(cnt)` returns a **rotated** rectangle as `((cx, cy), (w, h), angle)`, which is what you want for elongated parts at arbitrary orientation; `cv2.boxPoints(rect)` converts it to four corner points for drawing. The ratio of `contourArea` to the min-area-rect area is a cheap, orientation-independent fill ratio for rejecting badly-shaped blobs. ## Choosing If the pipeline is count-measure-locate, reach for `connectedComponentsWithStats`: one call, exact pixel areas, no zero-area edge case, and a reusable label image. If the pipeline needs shape - polygon approximation, convexity, rotated boxes, shape matching, hole structure - use contours, and filter by area before you compute anything that divides.