Where Do Fine Defects Go When You Shrink to 640 × 640?

EDGE AI

Shrink a 20 MP image to 640 px and a 90 μm defect is left at 0.35 px. Recovering it with native-resolution tiles takes 70 tiles and 560 ms.

On a setup that feeds PCB images captured at 5,472 × 3,648 px into a 640 × 640 input model, I calculated the downsampling loss, overlap, boundary handling and inference latency in turn.

About 12 min read

Detection models for edge devices are usually trained and deployed at a fixed input of around 640 × 640 px. PCB inspection cameras, on the other hand, output images in the 20 MP class. Bridge that gap with one line of resize, and a fine particle that covered 3 px in the original becomes a faint smudge of less than 1 px. Accuracy metrics look good, carried by the large defects, while only the fine defects drop out quietly and the escapes come back as defects in the customer process.

The surface comes before the calculation. Green solder mask is close to matte and scatters light fairly evenly, but solder joints and gold-plated pads reflect in one direction like a mirror, so their brightness differs several times over under the same lighting. That is why the setup assumes a diffuse dome light, and the numbers below take a near-matte surface such as solder mask as the reference. Detection on solder and plated surfaces cannot be guaranteed before a sample test.

Here are the assumptions. A 20 MP camera with 5,472 × 3,648 px and 2.4 μm pixels, fitted with a 35 mm lens, captures 164 mm × 109 mm in one shot, so one pixel covers about 30 μm. The smallest defects are 90 μm solder bridges and particles, the longest is a pad scratch 1,500 μm long, and the model takes a 640 × 640 input quantized to INT8¹, taking 8 ms per tile. The line takt is 400 ms. The control of the conveying mechanism that moves the boards needs a separate review.

Shrink to 640 px and a 90 μm defect becomes 0.35 px

Pixel resolution² is the FOV divided by the pixel count. Dividing 164 mm by 5,472 px gives 29.97 μm/px, and a 90 μm defect covers 3.0 px. Downsample³ the same image to 640 px wide and you get 164 mm ÷ 640 = 256 μm/px, which shrinks the same defect to 0.35 px. Downsampling usually averages several original pixels, so assuming area averaging, only the fraction the defect occupies within one pixel, (90 ÷ 256)² ≈ 0.12, survives as contrast. Size and contrast are cut together, a double loss.

So the question “down to how many μm does this model detect” has to be answered first in μm/px at the model input, before model architecture comes into it. By my standard a minimum defect needs at least 3 px at the model input to give the model a shape to learn, and filling 3 px at 256 μm/px takes a defect of 769 μm or more. Information that is not left in the input does not come back with retraining. It is the same reason software cannot cover a loss created by the optical setup.

A missing component of 1,000 μm, on the other hand, survives at 3.9 px even on the same downsampled path. This is where the case for splitting paths by defect size comes from. Defects larger than 769 μm, such as missing components or reversed polarity, can be seen on one downsampled image, and only the smaller ones need to go to native resolution.

Set the overlap by the longest defect

Tiled inference⁴ cuts the native-resolution image into model-input-sized pieces and runs inference several times instead of shrinking the image. Cut a plain grid with no overlap and a defect that straddles a boundary is split into halves across two tiles; a half defect loses its shape features and scores low in both tiles. Convolutional networks also weaken features near tile edges because of padding⁵, so judgments near an edge are less trustworthy than those in the middle.

So I set the overlap⁶ larger than the length of the longest defect in pixels. A 1,500 μm scratch is 50 px at 30 μm/px, so a 64 px overlap is enough, and the stride⁷ becomes 640 − 64 = 576 px. The tile count along one axis is (image width − tile width) ÷ stride, rounded up, plus 1. For a 5,472 × 3,648 px image that gives 9 × 6 = 54 tiles with no overlap, 10 × 7 = 70 tiles at 64 px and 11 × 7 = 77 tiles at 128 px.

In theory the tile count grows by 1 ÷ (1 − r)² for an overlap ratio r. At 64 px (r = 0.1) that is 1.23 times, yet the actual count goes from 54 to 70, 1.30 times. Tile counts are integers, so they jump like steps each time the image end forces one more round-up. Bringing the vertical direction down to 6 rows would take a stride of 602 px or more, an overlap of 38 px or less, which falls short of the 50 px scratch, so 70 tiles is the floor for this setup.

Count a boundary defect in one tile only

With overlap alone, a boundary defect can still be detected in two tiles at once. The cleanup I use is a center-ownership rule. The inner part of each tile, minus 32 px (half the overlap) from each edge, becomes that tile’s core, and each tile keeps only detections whose box center lies in its own core. With a uniform 576 px stride the cores divide the image without gaps, and a 50 px scratch whose center sits in a core needs only 25 px to its far end, so it shows whole within the 32 px margin.

The trap is the last tile. With a 576 px stride across 5,472 px, the tenth tile runs off the image, so its start has to be pulled back to 4,832 px, which makes it overlap the ninth tile (starting at 4,608 px) by 416 px. If the core stays fixed at 32 px from each edge, the two cores overlap in this stretch and the same defect gets counted twice. So I recompute each core boundary at the midpoint of the overlap between neighboring tiles. The regular seams fall every 576 px, at 608 px, 1,184 px and so on, and only the last seam moves to 5,040 px, which leaves the ninth tile a 400 px core and the last tile 432 px.

Removing duplicates with NMS⁸ alone is weak against half defects. The two boxes cut at a boundary overlap only a little, so their IoU⁹ stays below 0.5, both survive, and one defect is counted as two. Filtering by ownership first and leaving class-wise NMS (IoU 0.5) to clean up only the remaining duplicates reduces counting errors.

70 tiles take 560 ms, past the 400 ms takt

An edge device cannot easily raise throughput with large batches the way a server does, so the tile count turns almost directly into latency. At 8 ms per tile, 70 tiles take 560 ms of sequential inference, which does not fit the 400 ms takt¹⁰. And that number does not yet include transfer or post-processing time.

The way out here is a two-stage structure. One inference on the whole image shrunk to 640 px (8 ms) covers defects larger than 769 μm, such as missing components, and solder bridges are inferred at native resolution only on the tiles that touch the pad areas in the CAD data. Assuming 40 % of the tiles touch a pad, that is 28 of the 70 tiles, 224 ms, for a total of 232 ms. Whether transfer, post-processing and the decision signal fit into the remaining 168 ms has to be checked separately with per-stage p99 values, and that breakdown is calculated in the latency budget article.

The price is clear too. Solder bridges form only between pads, but 90 μm particles also land on the board surface outside the pads. In the two-stage structure those areas are seen only at 256 μm/px, so their detection floor rises to 769 μm. In my case that number goes straight into the quality spec, and for a product that tolerates no fine particles outside the pads, I would revisit the compute unit or the camera layout before cutting tiles.

Conditions split by defect size

For each defect type, the minimum size, optical setup and algorithm parameters are lined up in one row. The optical setup is the same in all three rows; the difference lies in which path runs the inference.

Defect	① Minimum defect size	② Optical setup · WD	③ Algorithm parameters
Solder bridge · fine particle	90 μm = 3.0 px (30 μm/px), 0.35 px after 640 px downsampling	20 MP (5,472 × 3,648 px, 2.4 μm pixels), 35 mm lens, FOV 164 × 109 mm, diffuse dome light, WD 450 mm or more (object distance about 472 mm from the principal plane)	Native-resolution 640 × 640 tiles, 28 pad-area tiles × 8 ms = 224 ms
Pad scratch	Length 1,500 μm = 50 px	Same as above	Overlap 64 px (stride 576 px), core boundary = midpoint of the overlap, class-wise NMS IoU 0.5
Missing · skewed component	1,000 μm = 3.9 px (256 μm/px on the downsampled path)	Same as above	One pass on the whole image at 640 px, 8 ms
Whole line	Particle floor outside pads 769 μm (downsampled path)	Measure WD including the dome light height	Two-stage total 232 ms, full tiling of 70 tiles 560 ms, takt 400 ms

What the table shows is that defect size decides the inference path. With 769 μm, the 3 px floor, as the dividing line, the downsampled path takes the large defects and native-resolution tiles take the small ones, while the 64 px overlap covers the longest 50 px defect and holds the tile increase to 1.30 times. The calculation that full tiling at 560 ms exceeds the 400 ms takt is the direct reason for choosing the two-stage structure, and its price, the 769 μm floor outside the pads, belongs in the same table.

When one pass over the whole image is better

There are places where the opposite choice fits. If every target defect is larger than 769 μm, one inference on the whole image is fast and has no boundary problem. With plenty of compute headroom, running a model with a larger input once can be simpler than maintaining tile-merging logic, but compute grows close to the square of the input side, so a 1,280 × 1,280 input costs about 4 times a 640 input. Splitting the FOV from the start with a high-magnification lens or several cameras gets the resolution without software splitting, but the hardware cost and whether lenses and lights interfere within the WD¹¹ need a separate look.

On surfaces where specular and diffuse reflection mix, such as solder joints, defect contrast swings strongly with the lighting angle. Detection can split even on native-resolution tiles, so the numbers above should be read only for matte solder mask. Results on strongly reflective surfaces cannot be guaranteed before a sample test, and I check recall first on sample boards collected for that case alone.

Field Note

If I put a 640 px input model on a PCB line, I calculate how many pixels the minimum defect keeps after shrinking before I shrink anything. Defects that drop below 1 px go to the native-resolution tile path, and I keep the overlap generously above the longest defect length. I redraw the core boundaries from the start coordinate of the last tile, and I write the tile count and per-tile latency in the same table as the takt. I split the validation metrics by defect size band.

Field Checkpoints

Before going on the line, I check five numbers and one surface in the order below.

• Is a WD of 450 mm or more secured by measurement, including the dome light height and the camera opening position? (object distance about 472 mm from the principal plane)
• Have you checked the reflectance differences among solder mask, solder joints and gold-plated pads on sample boards?
• Does the minimum defect keep 3 px or more in μm/px at the model input? (the 640 px downsampled path is 256 μm/px)
• Is the overlap larger than the longest defect length in pixels, and have the core boundaries of the last tile been redrawn at the overlap midpoint?
• Does tile count × per-tile latency fit within the takt? (70 tiles × 8 ms = 560 ms, two-stage 232 ms)
• Are validation metrics tallied separately by defect size band? (an overall average hides missed fine defects)

Frequently Asked Questions

Does a model with a 1,280 × 1,280 input make tiling unnecessary?

At 1,280 px wide, 164 mm ÷ 1,280 = 128 μm/px, so a 90 μm defect is 0.70 px, still less than one pixel. Compute rises to about 4 times the 640 input. Seeing 90 μm over 3 px needs 30 μm/px, which calls for an input around 5,467 px wide, practically the native resolution.

Does overlap also remove the score drop near tile edges?

The 64 px overlap keeps defects from being cut, while the effect of padding spreads over a wider range in deeper layers. With the core rule, the centers of the remaining detections sit at least 32 px from the tile edge, but if scores near the edge still come out low, I re-cut the same images at a 128 px overlap (77 tiles) and measure the score difference. If the difference is small I stay at 64 px; if it is large, the first question is whether the latency of the 7 extra tiles fits in the takt.

Glossary

• [1] INT8 quantization 8-bit integer quantization
  A method that converts model weights and arithmetic to 8-bit integers to cut computation and memory. Inference gets faster on the same device, but accuracy can drop slightly, so the model is validated again after quantization. ↩
• [2] Pixel resolution μm/px
  The length on the object covered by one pixel. Dividing a 164 mm FOV by 5,472 px gives about 30 μm/px. ↩
• [3] Downsampling downsampling, resize
  Processing that reduces the pixel count of an image. Because several original pixels are averaged into one, small defects lose size and contrast together. ↩
• [4] Tiled inference tiled inference
  A method that cuts a large image into pieces of the model input size, runs inference on each piece and merges the results. ↩
• [5] Padding padding
  Filling virtual values outside the image so that a convolution keeps the same size at the image edge. The filled values carry no real image information, so features near the edge weaken. ↩
• [6] Overlap overlap
  The width by which neighboring tiles overlap. It is the margin that lets a boundary defect fall whole inside at least one tile. ↩
• [7] Stride tile stride
  The spacing between the start coordinates of neighboring tiles, equal to the tile width minus the overlap. A 640 px tile with a 64 px overlap has a 576 px stride. ↩
• [8] NMS non-maximum suppression
  Post-processing that keeps only the highest-scoring box among heavily overlapping detection boxes and deletes the rest. ↩
• [9] IoU intersection over union
  The overlapping area of two boxes divided by the area of their union. A value of 0.5 means half of the combined area overlaps. ↩
• [10] Takt takt time
  The time the line allows for processing one part. Inspection has to finish everything from capture to decision within it. ↩
• [11] WD working distance
  The distance from the front of the lens to the surface under inspection. The 472 mm object distance in the text is a thin-lens value measured from the lens principal plane; the distance from the lens front comes from the lens drawing. ↩

References

• Akyon, Altinuc, Temizel, Slicing Aided Hyper Inference and Fine-tuning for Small Object Detection, arXiv:2202.06934 (2022, DOI 10.1109/ICIP46576.2022.9897990). An open-source framework that adds slicing-based inference and fine-tuning to existing detectors for small object detection.
• Formulas: pixel resolution = FOV ÷ pixel count, defect size after shrinking (px) = defect size ÷ (FOV ÷ input width), area-averaged contrast ratio ≈ (defect size ÷ shrunk pixel size)², tiles per axis = ⌈(image width − tile width) ÷ stride⌉ + 1, stride = tile width − overlap, core boundary = midpoint of the overlap between neighboring tiles, sequential latency = tile count × per-tile latency, magnification m = sensor width ÷ FOV width, object distance = f × (1 + 1/m)
• Assumptions: 20 MP camera (5,472 × 3,648 px, 2.4 μm pixels), 35 mm lens, FOV 164 × 109 mm, minimum defect 90 μm, longest defect 1,500 μm, 640 × 640 INT8 model at 8 ms per tile, takt 400 ms, share of tiles touching a pad 40 %

Related reading — Why Edge AI Vision Fails on the Factory Floor · In the Age of Deep-Learning Inspection, What to Check Before Camera Spec · Why an Average Latency Inside the Deadline Is Not Safe