{"slug": "line-scan-camera-defect-detection-with-roboflow", "title": "Line Scan Camera Defect Detection with Roboflow", "summary": "Roboflow published a guide for building a line scan camera defect detection system, walking through the three interdependent choices of camera, compute and Workflow blocks that turn high-resolution images into defect detections on moving production lines. The guide specifies that a 4,096-pixel camera covering a 400 mm web resolves about 0.1 mm per pixel, and that at 2 m/s material speed with 0.1 mm pixels the line rate must reach 20,000 lines per second to keep pixels square. It notes that the same Gpixel GL3504 sensor delivers 29 kHz over GigE, 65 kHz over 2.5GigE and 84 kHz over 5GigE at 4k, and that color versions roughly halve line rate, with Basler 4k color models running at 14 kHz on GigE and 42 kHz on 5GigE.", "body_md": "Build a line scan inspection system with Roboflow to detect defects on moving production lines. Select cameras and compute for your inspection requirements, then use Roboflow Workflows to process high-resolution images and validate results on your own materials.\n\nA line scan inspection system requires three choices that constrain each other: the camera, the compute that runs inference, and the Workflow blocks that turn a high resolution image into defect detections. If you select the camera without considering compute, you can end up with a line that produces more image data than an edge device can inspect.\n\nThis guide covers the choices in the order they depend on each other. Your smallest defect sets the camera resolution. The camera and the Workflow settings together set how many tiles per second need inference. That number sets the compute. For the short answer, start with the recommended combinations below.\n\nHow line scan cameras work\n\nA line scan camera captures one row of pixels at a time similar to a flatbed scanner. As material moves past the sensor on a conveyer or rotary table, the rows stack into a continuous image. An area scan, by contrast, captures a full rectangular frame in one exposure similar to a point and shoot camera.\n\nThat makes line scan the standard choice for continuous surfaces and moving production lines: steel sheet, fabric rolls, printed labels, and coated films. The production process has no natural frame boundaries, and neither does the image. Since the line scan camera only captures a single row of pixels, a single exposure can capture more precise detail with less motion blur.\n\nLine scan\n\nArea scan\n\nCapture\n\nOne line at a time, built up by motion\n\nOne 2D frame per exposure\n\nImage shape\n\nFixed width, length set by how long you scan\n\nFixed width and height\n\nBest for\n\nContinuous webs, wide surfaces, rotating parts\n\nDiscrete parts, assemblies, static scenes\n\nMotion\n\nRequired; line capture is synced to material travel\n\nFrozen with short exposure or strobes\n\nLighting\n\nA narrow, bright, uniform line\n\nEven light across the whole field\n\nSetup effort\n\nHigher: encoder, sync, and alignment\n\nLower: point, trigger, shoot\n\nStep 1: Select the camera\n\nStart from the defect, not the camera catalog. Four specs decide whether a camera can see your smallest defect at your line speed, and the interface decides how many of those lines reach the compute.\n\nFour specs that determine image quality\n\nPixels per line. Divide the field of view by the number of pixels per line to get resolution across the material. A 4,096-pixel camera covering a 400 mm web resolves about 0.1 mm per pixel.\n\nLine rate. Lines captured per second. To keep pixels square, line rate must equal material speed divided by pixel size. At 2 m/s and 0.1 mm per pixel, that is 20,000 lines per second.\n\nEncoder triggering. An encoder on the conveyor triggers one line per fixed distance of travel. Without it, any speed change stretches or squashes the image, and your defects with it.\n\nLine lighting. Exposures are short (50 microseconds at 20 kHz), so the light must be intense and uniform along the scan line. Lighting angle decides whether a scratch shows up at all.\n\nCurrent 2k, 4k, and 8k cameras\n\nVendors sell resolution in steps: 2k (2,048 pixels per line), 4k (4,096), and 8k (8,192). Basler's current range is the racer 2 family, and LUCID's is the Triton line scan range, which gained an 8k model at VISION 2026. Three patterns stand out in the table below:\n\nThe same sensor gives different line rates on different interfaces. The Basler 2k and 4k models and the LUCID Triton2 all use the Gpixel GL3504. At 4k it delivers 29 kHz over GigE, 65 kHz over 2.5GigE, and 84 kHz over 5GigE. The sensor did not change; the cable did.\n\nColor costs about half the line rate. Color versions of the Basler 4k models run at 14 kHz (GigE) and 42 kHz (5GigE, CXP-12). The color Triton2 runs at 33 kHz, and Basler's 8k color model runs at 80 kHz.\n\nAt 8k, the interface choice matters most. Basler's 8k needs CoaXPress and a frame grabber. LUCID's reaches 8k over standard 10GigE at a lower line rate. Basler also offers 16k at up to 120 kHz.\n\nPublished maximum line rates for the mono versions, as of November 2026:\n\nEvery line the camera captures has to travel down the cable, so the data rate is pixels per line × bits per pixel × line rate. The interface puts a ceiling on that product: raise one factor, and another has to come down.\n\nThe Basler 4k GigE camera shows it clearly. Its sensor can run at 84 kHz, but 4,096 pixels × 8 bits × 29,000 lines per second is 950 Mbit/s, which fills a 1 Gbit/s link. So Basler rates the camera at 29 kHz. It rates the 2k version on the same link at 58 kHz: half the pixels, twice the lines, the same 950 Mbit/s. Each interface sets a different ceiling:\n\nInterface\n\nApproximate ceiling\n\nWhat it carries\n\nGigE\n\n1 Gbit/s\n\n4k mono at 29 kHz, or 2k at 58 kHz\n\n2.5GigE\n\n2.5 Gbit/s\n\n4k mono at 65 kHz\n\n5GigE\n\n5 Gbit/s\n\n4k mono at 84 kHz (now sensor-limited, about 2.8 Gbit/s)\n\n10GigE\n\n10 Gbit/s\n\n8k mono at 55 kHz (about 3.6 Gbit/s)\n\nCXP-12\n\n12.5 Gbit/s per link, up to 25 Gbit/s on racer 2 L\n\n8k mono at 240 kHz (about 15.7 Gbit/s at 8 bits)\n\nPixel format is the factor people forget\n\nPixel format sets the bits per pixel, so it moves the line rate ceiling directly. For a 4k camera on GigE, with roughly 950 Mbit/s to spend, every extra bit costs lines per second:\n\nIn the table below, the Mono8 row is Basler's published figure. The other rows divide the same budget by the bits per pixel, and they match Basler's published 14 kHz for the 4k color GigE model.\n\nPixel format\n\nBits per pixel on the wire\n\nMaximum line rate\n\nMaximum web speed at 0.1 mm per pixel\n\nMono8\n\n8\n\n29 kHz\n\n2.9 m/s\n\nMono12 packed\n\n12\n\nabout 19 kHz\n\n1.9 m/s\n\nMono10 or Mono12 unpacked\n\n16\n\nabout 14.5 kHz\n\n1.45 m/s\n\nYCbCr422 (color)\n\n16\n\nabout 14.5 kHz\n\n1.45 m/s\n\nRGB8 (color)\n\n24\n\nabout 9.7 kHz\n\n0.97 m/s\n\nFour rules for specifying a camera\n\nUse Mono8 unless you have a reason not to. Detection models take 8-bit images. Sending 12-bit data halves your line rate on a saturated link, and the model never sees the extra bits.\n\nPick resolution from the defect, not the catalog. Work out the pixel size you need for your smallest defect, then the pixels per line to cover the web. Going from 4k to 8k halves the line rate on the same link and roughly doubles the tiles to run: 9 across at 4k, 17 at 8k.\n\nCheck which limit you are hitting. On GigE, the cable is the limit. On 5GigE and faster links, the sensor often is, and a faster interface gains nothing.\n\nRead the footnotes. Published rates assume single-line readout, minimum exposure, jumbo packets, and a dedicated link. LUCID's 8k drops from 55 to 33 kHz in two-line mode. A narrower region of interest raises the ceiling again.\n\nStep 2: Choose the Workflow blocks\n\nThe camera decides how much image data arrives. The Workflow decides how it gets inspected. Detection models expect a small, roughly square input, so the blocks you choose have to bridge the gap between a strip thousands of pixels long and a model that sees a few hundred pixels at a time.\n\nWhy resizing fails\n\nDetection models take a fixed, roughly square input a few hundred pixels per side. A line scan strip can be thousands of pixels wide and far longer. If you resize a 4,096x20,000 strip to 640 pixels on its long side, a 30-pixel scratch becomes about one pixel. The model cannot find what is no longer there.\n\nThe answer is to keep every pixel and cut the image instead. Each of the following steps fixes a problem that the previous step creates:\n\nTile. Slice the strip into model-sized tiles and run inference on each. Every defect keeps its full resolution. The new problem: a cut line can split a defect between two tiles, so the model sees two fragments instead of one defect.\n\nOverlap. Make neighboring tiles share a margin. A defect on a boundary now appears whole in at least one tile, provided the defect is smaller than the margin. The new problem: the model detects anything inside the margin twice.\n\nStitch. Shift each tile's boxes back into strip coordinates, then run non-maximum suppression (NMS). Where two boxes overlap beyond a threshold, NMS keeps the more confident one.\n\nOverlap protects only defects that are smaller than the overlap. A long scratch that crosses several tiles still comes back as several boxes, one per tile. If your defects are long, use a larger overlap, larger tiles, or a merge-based filter instead of NMS, as described in Choose the settings.\n\nThe blocks you need\n\nThe pipeline is three blocks in Roboflow Workflows, plus two visualization blocks to draw the result.\n\nImage Slicer\n\nImage Slicer cuts the strip into overlapping tiles. Set the slice width and height to 640 and both overlap ratios to 0.25.\n\nWith these settings, each tile shares 160 pixels with its neighbor, and the slicer advances 480 pixels per tile. Any defect narrower than 160 pixels appears whole in at least one tile.\n\nObject Detection Model\n\nConnect the model block to the slicer's output, not to the original image. The model runs once per tile and returns a separate set of predictions for each. The model treats each tile as an ordinary image.\n\nTrain the model on tiles, not strips: it only ever sees single tiles, so it needs to work well at tile scale and production resolution. The screenshots in this section use a Pill Detection project as the example: 496 images of individual tablets and capsules, with a model that reached 99.5% mAP on the validation set. Figure 8 places those tablets and capsules on a conveyor strip, the way a line scan camera sees a pharmaceutical packaging line.\n\nDetections Stitch\n\nDetections Stitch takes the per-tile predictions plus the original strip as a reference. It shifts every box from tile coordinates to strip coordinates, then filters duplicates. Set the overlap filtering strategy to NMS and the IoU threshold to 0.5.\n\nVisualization\n\nFinally, Bounding Box Visualization and Label Visualization draw the merged detections on the full strip. The Workflow returns both the annotated image and the prediction list.\n\nChoose the settings\n\nSetting\n\nStarting value\n\nHow to choose it for your line\n\nTile size\n\n640x640\n\nPick the size at which defects appear at the same pixel scale as in your training images\n\nOverlap\n\n0.25 (160 px)\n\nAt least the pixel size of the largest defect you need returned as a single box\n\nFiltering strategy\n\nNMS\n\nNMS for compact defects; non-max merging for long defects that span tiles\n\nIoU threshold\n\n0.5\n\nLower it if duplicates survive; raise it if nearby distinct defects get merged\n\nValidate the combination\n\nRun strips from your own camera through the Workflow. One call slices the strip, detects on every tile, and returns a single set of boxes in strip coordinates.\n\nCheck the output for three things:\n\nCoverage. Detections appear along the whole strip, not only in one region.\n\nBoundaries. Defects that sit across a tile edge come back as one complete box, not two halves.\n\nDuplicates. Defects inside an overlap zone have one box, not two stacked ones.\n\nStep 3: Choose the compute\n\nEvery tile is one model call, so tiles per second is the load the device has to carry. With 640-pixel tiles at 0.25 overlap and square frames:\n\nCamera and link\n\nLine rate\n\nSquare frames per second\n\nTiles per frame\n\nTiles per second\n\n2k Mono8 on GigE\n\n58 kHz\n\n28.3\n\n16\n\nabout 450\n\n4k Mono8 on GigE\n\n29 kHz\n\n7.1\n\n81\n\nabout 570\n\n4k Mono8 on 5GigE\n\n84 kHz\n\n20.5\n\n81\n\nabout 1,660\n\n8k Mono8 on 10GigE\n\n55 kHz\n\n6.7\n\n289\n\nabout 1,940\n\nRoboflow OS runs on Jetson AGX Orin 64 GB and Jetson Thor T5000 128 GB. Thor connects over QSFP28 (4 × 25GbE) but has no Power over Ethernet (PoE) ports, so the cameras draw power from a PoE switch.\n\nCheck the device against the load\n\nEvery tile is a full model run, so these loads are demanding for a single edge device. Before you commit to hardware, run your Workflow on the device with tiles from your own line and measure how many tiles per second it sustains, including slicing and stitching. Compare that figure to the load for your camera.\n\nIf the device falls short, you have four levers:\n\nBigger tiles or less overlap. Fewer tiles per frame means fewer model runs. Check that defects still appear at the scale the model was trained on, and that the overlap still covers your largest defect.\n\nA narrower region of interest or a slower line. Inspect only the part of the web that matters, or lower the line rate by running the material more slowly.\n\nA smaller or faster model. Use a smaller model size, or export it to TensorRT at reduced precision, then confirm accuracy on your boundary test set.\n\nMore devices. Split the cameras, or divide the web into lanes, across several devices.\n\nPlan for a continuous line\n\nA production line differs from a single test strip in four ways. Plan for each before you deploy.\n\nThe strip never ends. A camera does not hand you one finished image. Your acquisition software cuts the stream into frames of a fixed number of lines. Overlap consecutive frames the same way you overlap tiles. Otherwise, a frame boundary splits defects, and nothing stitches them back together.\n\nScale has to match training. A model trained on tiles where a scratch is 40 pixels long struggles when production tiles show it at 120 pixels. Train on tiles cut from real strips at production resolution, and slice at that same size.\n\nTile count drives throughput. At 640-pixel tiles with 25% overlap, a 4,096-pixel-wide strip needs 9 tiles across. A 4,096x4,096 frame is 81 inferences. Check that against your line speed, and reduce overlap or increase tile size if you need headroom.\n\nBoundaries need their own test. Aggregate metrics hide edge failures. Build a test set of defects that fall on tile and frame boundaries, and compare the output against a reference inspection.\n\nBuild your line scan inspection system\n\nThe right combination starts from the defect. Choose the pixel size that resolves it, the camera and link that deliver that resolution at your line speed, the tile and overlap settings that keep defects whole, and an edge device that keeps up with the resulting tiles per second. The Workflow itself stays the same three blocks.\n\nTo adapt it, swap in strips from your own camera and a model trained on your materials, then tune tile size and overlap against defects you already know about.", "url": "https://wpnews.pro/news/line-scan-camera-defect-detection-with-roboflow", "canonical_source": "https://roboflow.com/blog/line-scan-cameras", "published_at": "2026-11-13 11:26:00+00:00", "updated_at": "2026-11-13 16:54:08.682175+00:00", "lang": "en", "topics": ["computer-vision", "ai-tools", "machine-learning"], "entities": ["Roboflow", "Basler", "LUCID", "Gpixel", "GL3504", "Triton", "racer 2", "VISION 2026"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/line-scan-camera-defect-detection-with-roboflow", "markdown": "https://wpnews.pro/news/line-scan-camera-defect-detection-with-roboflow.md", "text": "https://wpnews.pro/news/line-scan-camera-defect-detection-with-roboflow.txt", "jsonld": "https://wpnews.pro/news/line-scan-camera-defect-detection-with-roboflow.jsonld"}}