Deep learning defect inspection on large 8K line-scan images

An 8K line-scan camera hands your inspection software a frame of 15000×7200 px, and nearly every network wants an input close to 1024 px. That gap decides the whole pipeline: shrink the frame and a 0.5 mm defect disappears below 2 px; tile it and the same defect keeps all 25 of its pixels. This guide gives the tile size, overlap and merge rules for large line-scan images, a worked tile count for a 15000×7200 frame, the bandwidth and compute numbers behind them, and the cases where tiling is the wrong tool. The method holds for any line-scan frame; only the numbers move.

Why can't you feed the whole 15000×7200 frame to the network?

Downscaling is the trap: at a 300 mm web width the 15000 px line gives 20 μm per pixel, a 0.5 mm defect spans 25 px, and a 14.65× shrink to a 1024 px input leaves 1.7 px — under the 4-8 px a segmentation head needs to separate defect from texture.

Networks resize input to a fixed size, and a segmentation head predicts one label per output pixel. Pooling and stride discard detail first where there is least of it — exactly the 25 px a small defect owns. After the shrink those pixels are averaged into the background: the defect is not noisy, it is gone. If you downscale for anything, downscale for display, not for measurement; the antialiasing guide for downsampled and warped images covers the filter side of that mistake, and the pixel-per-defect sizing rule gives the general budget method. The fix is to keep native scale where the defects live: tile the frame, run the network at its trained scale, then stitch the results.

How large should each tile be?

Use 1024×1024 px as the default and enlarge only for big defects: a tile must contain the largest defect plus about half its size in surrounding context, and at 20 μm per pixel a 1024 px tile covers 20.5 mm of web.

1024 is where most segmentation models are built and batched, powers of two keep convolution shapes aligned, and 20.5 mm of web leaves room for a 0.5 mm pit and a 10 mm scratch together. Keep the largest defect below roughly two-thirds of the tile edge so context surrounds it on all sides, and grow the tile only when a defect class outgrows the window. A 2024 review across defect and medical-image datasets found that larger tiles and more overlap improve prediction — but each doubling of the tile edge multiplies activation memory by four, which is the subject of why small models still occupy large GPU memory. A 2048 px tile also runs about four times slower per tile, so grow for defect size, not for hope.

How much overlap do the tiles need?

Set 15-20% overlap as the default — 154-205 px on a 1024 px tile — so any defect smaller than the overlap itself appears complete in at least one tile; below about 10%, border defects survive only as two partial halves.

The mechanism is border damage, not per-tile accuracy. A convolutional network sees less context at tile edges and its predictions degrade in the outermost ring; the overlap-tile strategy published with U-Net formalizes this by feeding overlapping tiles and trusting each tile's interior. Published implementations run from 48 px of overlap upward, and one geometric fact does the design work: any defect smaller than the overlap width is fully contained in at least one tile, whatever its grid position. Overlap also creates duplicates — the same defect detected in neighboring tiles — and those duplicates are exactly what the merge step consumes. The worked example below shows the cost: about 43% more tiles than a plain grid.

How do you merge tile detections into one defect map?

Add each tile's origin offset to its detections, then run non-maximum suppression with an IoU threshold of 0.3-0.5, so a defect found in two overlapping tiles collapses to one box that carries the higher confidence.

Every tile knows its origin (tx, ty) in frame coordinates, so mapping back is an offset addition — do it before suppression, because suppression must compare boxes in one coordinate system. NMS is the final step of the standard detection recipe (propose windows, score them, suppress overlaps); tile merging changes only where the duplicates come from. Keep the threshold identical between validation and production, and lower it only if duplicates leak through. For segmentation output, paste each tile's predicted mask into a full-frame canvas at its origin and resolve overlapping pixels by the higher class score. Store one result record per frame with every tile origin, so a model update can rebuild history — the per-run inference output layout keeps that traceable.

How many tiles does one 15000×7200 frame make, and will inference keep up?

With 1024 px tiles and 20% overlap the stride is 800 px, giving 19 × 9 = 171 tiles against 120 without overlap — about 43% more compute — and at a 10 ms planning value per tile that is 1.71 s per frame.

The 10 ms figure is a planning input, not a promise — measure your model at the production batch size. The deadline is set by the web: a frame is 7200 px tall, which at 20 μm/px is 144 mm of travel, so at 300 mm/s the frame window is 144 ÷ 300 = 480 ms. Batched inference closes most of the gap between 1.71 s unbatched and that budget; if it still misses, crop tiles to the defect-prone bands, or run a lightweight coarse pass over the whole frame and tile only flagged regions. Frame edges bring a cousin problem: when the web advances a different distance than the frame assumes, lines repeat or drop — the frame-boundary overlap article covers that failure mode, and the line rate guide sets the timing.

Which 8K line-scan camera delivers the pixels the defect budget needs?

Size pixels per defect first and the interface second: at 20 μm per pixel a 0.5 mm defect spans 25 px, comfortably segmentable, while an 8192 px line at 20 kHz in Mono8 moves 163.84 MB/s — past GigE's roughly 110 MB/s usable ceiling.

GigE carries about 110 MB/s of payload on a 1 Gbit/s link, 2.5GigE about 280 MB/s, 10GigE about 1,100 MB/s. An 8K Mono8 line at 20 kHz (8192 × 20000 = 163.84 MB/s) therefore needs 2.5GigE or faster; a 16K line at the same rate needs 10GigE or a Camera Link or XoFLink class link. Halve the rate to 10 kHz and the 8K line drops to 82 MB/s, where GigE copes. The along-web pixel pitch is a different number again — web speed ÷ line rate — and the encoder ticks-per-pixel guide shows how to match it to the optical pitch.

Match the camera to the pixel budget from the downscale math above. For a single 8K line at high rate, the LS-LCM-0099 pairs 8K resolution with 10GigE on an M72 mount:

When the budget needs 16K on finer pixels, the MV-CL166-91F2C runs 16K on a 5 μm pixel with an 82 mm image circle over XoFLink:

Keeping an installed 4K base is also viable: the MV-CL042-91GC-V2 gives 4K on a 7 μm pixel over GigE:

To convert a defect budget back into a required pixel count, open the resolution calculator:

Filter line length and interface in the line scan cameras category, or work through the camera configurator.

Which compute runs tiled inference on the line?

Split the roles: a vision controller acquires lines, drives lights and pre-processes tiles, a GPU-class machine runs the network, and training happens offline on a multi-GPU server — sized by tile count times per-tile time, never by sensor resolution alone.

Memory is an activation problem, not a storage one: a full frame of 171 tiles is about 538 MB of pixels (171 × 3 MB), which any machine holds, while the constraint is GPU memory during a batch — the same scaling that makes 2048 px tiles four times hungrier than 1024 px tiles. Keep acquisition and inference asynchronous so the encoder never waits for the GPU; the load-sizing logic matches the case where several cameras share one machine — see when multiple line-scan cameras stop acquiring. For model placement and the CPU/GPU split, the deep learning setup checks walk the decision, why GPUs beat CPUs for training covers the offline side, and the PatchCore edge-fit example sizes a full model end to end.

Where one box must also run classical checks, drive lights and serve several GigE cameras, the VC5000-series MV-VC5525-256G70-NN pairs a 12th-generation Core i5 with 32 GB of memory, PoE camera ports, eight light channels and PCIe expansion for an inference card. The vision controllers category lists the series. When tiled inference is the whole job, the dual-card MV-VAC5724 brings PoE camera ports, eight built-in light channels and 5+ LAN ports:

For offline training on shared tiles, the quad-GPU AI training server exposes 2 LAN ports and 3-4 USB 3 ports:

When is tiling the wrong answer?

Skip tiling when the smallest defect you must flag is large: a 25 mm stain spans 1250 px at 20 μm per pixel and still 85 px after a 14.65× downscale, so a single whole-frame pass finds it at 1/171 of the tiled compute.

Two alternatives cover the remaining cases. The cascade: run a lightweight network over the whole downscaled frame to propose candidate regions, then native-scale tiles only where it flagged — cascaded detectors such as MTCNN are built exactly this way, and a clean web pays one small pass instead of 171 tiles. The coarse answer: when the decision is pass-or-reject and exact geometry is secondary, a downscaled whole-frame classifier is legitimate. What never works is downscaling and then promising fine defect geometry — those pixels no longer exist. Decision rule: compute the smallest defect in pixels after any downscale. Above about 20 px, whole-frame or cascade; below 4-8 px, tile at native scale; in between, test both on your validation set.

What do you check before the line runs?

Freeze nothing until three numbers are measured on the target machine: per-tile latency at production batch size, full-frame time against the web deadline, and the count of validation defects that touch a tile border.

• Measure per-tile time on the inference machine, at the production batch size — batching changes per-tile time more than any other setting.
• Multiply tile count by measured time and compare with the deadline (frame height ÷ web speed); keep about 20% headroom for burst loads.
• Re-run the validation set with tiling enabled and count defects whose box crosses a tile edge; any defect found only as two halves means the overlap is too small.
• Check that every stored detection carries its tile origin, so frame coordinates survive a model update.
• Prove the reject path with seeded defects before trusting live statistics; the commissioning guide for AI vision defect inspection walks acceptance step by step.

If your frame size, defect list or web speed differs from the examples, the tile math above still holds — send the three inputs through the contact page and we will run the numbers with you. The surrounding pipeline — triggering, buffering, load sizing — starts from the systems topic hub.