You binarize an image, run the blob search, and get 521 blobs from a scene that holds one white circle. The algorithm is not broken and your parameters are not wrong: the file is. Saving a thresholded image as JPEG turns a field of 0s and 255s back into a field of near-zero and near-255 speckle. A blob search that treats any non-zero pixel as foreground dutifully labels every speck. This guide walks the failure in the order you meet it: proving the image is not binary, finding where the gray values entered, restoring a clean count with the right threshold and area filter, and keeping the capture path raw so it never happens again.
Why does one white circle come back as 521 blobs?
Because the image stopped being binary before the search ran: JPEG compression spread the black-white transition into thousands of mid-gray pixels. A search that counts every non-zero pixel as foreground labels each gray speck as its own blob.
A true binary image holds exactly two values, 0 and 255. Blob tools usually offer two entry points: one assumes the plane is already binary and treats every pixel above 0 as foreground; the other binarizes at a threshold you supply and then searches. Feed the first one a JPEG-saved plane and every compression artifact becomes an object. In one reproduction of this failure, a filled circle on a black background stored as .jpg returned 521 blobs from the non-zero search; the same file re-thresholded at 128 returned 1. JPEG codes the image block by block, so flat areas beside a sharp edge come back with values a few counts above zero. Each of those patches labels as a separate blob.
How to prove the image is no longer binary?
Build a histogram of the image, remove the bins at 0 and 255, and look at what is left: a genuinely binary image leaves nothing, while a JPEG-saved one shows a scatter of counts between 1 and 254.
That two-second test isolates the failure without touching the blob tool. Threshold your image in memory and check the histogram: empty apart from the two extremes. Save it as .jpg, reopen it, and repeat: the gap between 1 and 254 fills in. The file format did it, not the threshold and not the camera. Run the same histogram on the live stream when you want the check in production — the approach in live binary image preview for defect inspection keeps the threshold and the histogram visible while parts run, so speckle shows up the moment it appears.
Did the camera or the file format produce these gray values?
The file format did: an industrial camera hands your software the raw sensor values untouched. The gray speckle appears only after a frame is encoded to JPEG on disk or by a consumer capture pipeline.
JPEG was designed for photographs, where smooth gradients hide small value errors, and it trades exact pixel values for file size. On a two-value image that trade fails openly: halos around every edge, faint blocking across flat areas. It is the same reason machine vision cameras ship raw frames rather than in-camera JPEG, a decision covered in in-camera JPEG compression: why machine vision cameras stay raw. The practical rule for blob work: any file named .jpg, or anything coming out of a lossy encoder, is suspect the moment it feeds a threshold. Keep frames raw in memory and the question disappears.
Which threshold to set before the blob search?
Set 128 on the 0-255 scale: mid-gray kills every compression speck. Those specks sit a few counts off 0 or 255 while true foreground sits at the extreme, so the count collapses to the real objects.
Prefer the combined binarize-and-search form of your blob tool — the call that takes the image plane, a low level of 128 and a high level of 255 — so the cutoff is applied inside the search instead of assumed. The three available fixes rank like this:
| Fix | What it removes | What it keeps | Use it when |
|---|---|---|---|
| Re-threshold at 128 | Every speck within 127 counts of 0 or 255 | Solid foreground at the extremes | The file is already JPEG |
| Save lossless (PNG, BMP) | The source of the speckle | The exact values your threshold wrote | You control the saving code |
| Minimum area filter | Any blob under N pixels | Every blob over N pixels | Always, as the second line |
How to pick a minimum blob area in pixels?
Divide your smallest real defect's area by the area one pixel covers on the part, then halve the result for margin. That value in pixels is the minimum-area filter, and everything smaller is speckle or noise by definition.
Worked example, with the arithmetic shown. The LS-CMR-0166 is a 12 MP USB3 camera with a 4000 × 3000 resolution.
- Sensor format
- 1/1.7"
- Interface
- USB3
- Resolution
- 12 MP
- Shutter
- Rolling
Put an 80 mm × 60 mm field of view in front of it: one pixel then covers 80 mm ÷ 4000 px = 0.02 mm on the part, so a pixel spans 0.02 mm × 0.02 mm = 0.0004 mm². The smallest true defect you must keep is a 0.1 mm pinhole. Its area is π × (0.05 mm)² = 0.0079 mm², which comes to 0.0079 mm² ÷ 0.0004 mm² = 19.7 ≈ 20 pixels. Set the minimum area to 10 pixels, half the true defect, and the pinhole passes with margin while everything under about 0.07 mm across is rejected.
Because the area limits ride along in the same call as the search, the filter runs during labeling at no extra cost. Once the count is clean, measure blob area in a binary image by pixel counting turns the surviving blobs into calibrated areas.
Does 4- or 8-connected labeling change the blob count?
Yes: with 8-connected labeling, diagonal speck chains merge into single sprawling blobs, and with 4-connected labeling the same specks count separately. One speckled image can swing between hundreds of blobs and a few merged ones.
Choose connectivity for the geometry of your parts, never to hide noise: round markers and diagonal features need 8, strictly horizontal and vertical structures stay stable on 4. The failure modes of each choice are laid out in connectivity 4 or 8 in blob analysis for circular markers. If switching connectivity changes your count by hundreds, the image still carries speckle — go back to the threshold step.
Which file format should intermediate images use?
Use a lossless format, PNG, BMP or uncompressed TIFF, every time an image is saved between processing steps. These store and return every pixel value exactly, where JPEG changes values to save space.
PNG is usually the right pick: it compresses long runs of identical values hard, so a binary image costs little on disk while reopening byte-exact. If a downstream tool insists on JPEG, threshold again on load — a 128 cutoff restores a clean count even from a lossy file. When a correctly saved thresholded image looks black in a viewer, that is a display-mapping issue, not data loss; save a thresholded binary image without opening black covers the viewer-side fix.
What hardware keeps production blob counts clean?
Keep the analysis path raw end to end: a mono machine vision camera streaming lossless frames to your software, or a smart camera that runs the blob tool on the device, so no image file ever sits between capture and analysis.
The MV-CS200-10UM is a 20 MP mono camera with a USB3.0 interface, built for exactly that streaming role.
- Sensor format
- 1"
- Lens mount
- C-mount
- Interface
- USB3
- Resolution
- 16-25 MP
At the other end, the LS-SMC-0063 is a 1.6 MP smart camera with a 16 mm lens and its own white light source, running inspection on the device so only results cross the network.
- Interface
- GigE
- Resolution
- Up to 3 MP
Both routes come from the area scan cameras and smart cameras ranges; the camera finder filters by interface and resolution. Lighting holds the fix in place: steady, driven illumination keeps foreground and background near the extremes of the range, which is what makes a fixed 128 cutoff safe every shift.
Power, dim and strobe your lights
573 models · from $120.00What to check before blaming the algorithm?
Run this list in order and the fault shows in the first three steps almost every time: histogram, file extension, threshold, area filter, connectivity — five checks, two minutes, and only one of them needs a code change.
- Histogram with the bins at 0 and 255 removed — empty means the plane is truly binary.
- Extension of every file written between steps — .png, .bmp or .tif, never .jpg.
- Threshold inside the blob search — 128 on the 0-255 scale unless your two gray populations sit elsewhere.
- Minimum area in pixels — half the pixel count of your smallest real defect, 10 px in the worked example.
- Connectivity — 4 or 8, chosen for part geometry and confirmed on a speckle-free image.
These checks sit alongside the other image-handling routines on the systems topic page. When the count is clean and you want the capture side to match, start with the vision system configurator or send the part and defect sizes through the contact page and we will size the camera and lighting with you.
Questions
Why does JPEG damage an image that has only two gray values?
JPEG was built for photographs with smooth gradients: it transforms each 8 × 8 pixel block into frequency terms and drops the least visible ones to save space. On a two-value image the sharp black-white edge is exactly what those terms encode worst, so the decoder rebuilds halos next to every edge and faint blocking across flat areas. Higher quality settings reduce the speckle but never guarantee exact 0s and 255s, which is why lossless formats are the only safe intermediate.
Is a minimum blob area filter enough on its own?
No. An area filter removes small specks from the count, but the gray speckle still sits inside and around true blobs, so measured areas, centroids and bounding boxes shift with every save. Fix the cause first, re-threshold at 128 or save lossless, then keep the area filter as the second line against genuine noise such as dust and reflections. Most blob tools accept a minimum and maximum area directly in the search call, so the filter costs no extra pass.
What if my real features are dim, not bright white?
Threshold at the midpoint of your two gray populations, not at 128 by rule. If parts appear at gray 40 on a gray 15 background, any cutoff between those levels separates them, so 27 or 30 works while 128 would delete the parts entirely. A fixed 128 is the safe default only when foreground and background sit near the extremes of the 0-255 range, which is what a well-lit binary scene gives you.
Do PNG and BMP really keep a binary image exact?
Yes. Both are lossless: PNG stores runs of identical values and rebuilds them byte for byte, and BMP writes the pixels uncompressed. TIFF is also lossless as long as it is not carrying JPEG compression internally. File size differs, and PNG is usually far smaller on binary content, but every pixel reopens at exactly the value you thresholded, so a non-zero blob search behaves identically before and after saving.
Why does a clean image sometimes report two or three blobs?
Usually the object touches the image border: some tools split the overlap into separate edge fragments or count a frame artifact as its own blob. Most blob tools let you ignore blobs that touch the border, which is the right setting when parts can enter the frame partially. If border exclusion is off and your part crosses the edge, one physical part legitimately reports as one blob plus edge fragments.