A team searching for “instance segmentation models” usually arrives with a quiet assumption: outlining every defect at the pixel level must beat drawing a box around it. More detail, better inspection. That instinct is where most segmentation projects on a line start to go wrong. The naive view treats segmentation as a free upgrade — swap the detector for a mask model, get per-pixel outlines, done. In practice, the choice between classification, detection, and instance segmentation is not a question of output richness. It is dictated by your defect-class catalogue and by the decision threshold you can afford at line throughput. A mask that a bounding box could have matched, at a fraction of the annotation and inference cost, is not more accurate. It is more expensive. This piece is about knowing which side of that line a given defect sits on before you commit to a pilot. What instance segmentation actually produces Instance segmentation assigns every pixel in an image to a specific object instance. Where an object detector returns a rectangle and a class label (“scratch, 0.91 confidence”), an instance segmentation model returns the same label plus a pixel-accurate mask that traces the object’s real outline — and it separates two overlapping scratches into two distinct instances, which semantic segmentation cannot do. Mask R-CNN is the canonical architecture here: it extends the Faster R-CNN detection head with a parallel branch that predicts a binary mask per detected region of interest. More recent transformer-based approaches like Mask2Former and the promptable Segment Anything family (SAM, and lighter variants such as MobileSAM) reframe the problem, but the output contract is the same — instances, labels, and masks. If you want the detection-side of that lineage, our explainer on how an image detection model works in industrial inspection covers the box-only case that segmentation builds on. The important thing is what the mask buys you. A mask lets you measure area, coverage percentage, and irregular shape. A box only lets you measure position and a rectangular extent. That difference is the entire decision. How does instance segmentation differ from object detection and semantic segmentation on an inspection line? Three output granularities, three different jobs. Confusing them is the most common architecture error we see in early feasibility work on computer vision inspection systems. Output type What it returns Answers the question Typical inspection use Classification One label per image “Is this part defective?” Pass/fail gating with no localisation Object detection Box + label per object “Where is the defect, and what is it?” Counting defects, locating discrete features Semantic segmentation Class label per pixel (no instances) “Which regions are coating vs bare metal?” Continuous-region coverage where instances don’t matter Instance segmentation Mask + label per distinct object “How large and what shape is each defect, separately?” Area gating, shape-based defects, overlapping instances The trap is reaching for instance segmentation when semantic segmentation — or a plain detector — would answer the actual spec. If your defect metric is “percentage of surface covered by contamination” and the contamination is a single continuous region, semantic segmentation is cheaper and sufficient because you never need to separate one blob from another. Instance segmentation earns its keep only when you must distinguish and measure each object as a separate thing. When does a defect genuinely need a per-pixel mask? This is the question that decides the architecture, and it has a clean test. Ask what the specification gates on. A mask is justified when the pass/fail decision is area- or shape-based. Scratch area above a threshold. Coating coverage below a required percentage. Irregular contamination where a rectangle would wildly over- or under-count the affected surface. In these cases a bounding box systematically mismeasures — a thin diagonal scratch fills perhaps 5% of its own bounding rectangle, so gating on box area would flag conforming parts and pass defective ones. The mask is not a nicety here; it is the only output that maps to the spec. A box or a label is enough when the decision is presence, count, or location. A missing screw, a mislabelled component, a discrete dent counted against a per-part limit — none of these need the defect’s exact outline. Detection answers them at lower cost, and our walkthrough of image processing object detection on a production inspection line shows that pipeline end to end. The failure mode is paying for precision the line cannot use. A pixel-accurate mask on a defect the spec only counts is annotation and compute spent to produce a number nobody reads. What instance segmentation costs at line throughput The two costs that kill segmentation pilots are annotation effort up front and inference latency at run time. Mask annotation is dramatically heavier than box annotation. Drawing a bounding box is two clicks; tracing a pixel-accurate mask around an irregular contamination boundary can take, in our experience labelling industrial defect sets, on the order of five to ten times longer per instance (observed pattern across CV-inspection engagements — not a benchmarked rate, and it swings hard with defect morphology). That cost recurs every time the defect catalogue grows or the part geometry changes. On the inference side, a mask head adds work on top of detection. The magnitude depends entirely on the executor — model, resolution, batch size, and the GPU or edge accelerator plus its software stack. What matters for a line is not the average latency in a notebook but the sustained latency at your frame rate under production conditions. A model that clears the throughput budget on a warm workstation and misses it on the line’s actual industrial computer has failed the only test that counts. Techniques like TensorRT graph optimisation, FP16 inference, and running the mask head at a lower resolution than the detector all move the number, but they move it within the constraints of your hardware, not around them. A quick scoping rubric before you commit to a pilot Run these five checks before greenlighting an instance segmentation pipeline. If you cannot answer “yes” to the first, stop — a cheaper output granularity will do the job. Is the pass/fail decision area- or shape-based? If it is presence, count, or location, use detection or classification instead. Does a bounding box systematically mismeasure this defect? Thin, diagonal, or irregular geometries say yes; compact blob-shaped defects often say no. Do overlapping instances need to be separated? If two defects touching each other must be measured independently, semantic segmentation is out and you need instances. Can the imaging pipeline resolve the mask boundary? A mask is only as good as the edge the camera and lighting actually capture (see the next section). Does the mask model clear the throughput budget on the line’s real hardware? Measure sustained latency on the deployment executor, not a dev box. Why imaging, lighting, and fixturing matter even more for masks Per-pixel masks are only as reliable as the pixels feeding them. This is the same long-tail-variance problem that governs every industrial-CV model, but segmentation is less forgiving of it. A detector that draws a slightly loose box around a defect can still be correct about the pass/fail decision. A mask whose boundary drifts by a few pixels because of specular glare, inconsistent part positioning, or a shadow from uncontrolled ambient light directly corrupts the area measurement the spec depends on. Fixturing that lets a part rotate or shift between frames introduces boundary variance the model cannot recover. Lighting that produces different reflections on the same defect from part to part teaches the model that the defect boundary is ambiguous — because in your data, it is. We pay close attention to this in feasibility work because the model architecture is often not the bottleneck; the imaging setup is. Upgrading from a box detector to a mask model on top of an uncontrolled imaging pipeline usually makes the numbers worse, not better, because it exposes variance the box was quietly tolerating. This is also why masks carry the same operational burden as any deployed model: they need monitoring for boundary drift, distribution shift, and the slow degradation that comes when line conditions wander from the training set. The reliability and monitoring artefacts that keep any industrial-CV model trustworthy apply with extra force here, because a silently drifting mask boundary produces confident, precise, wrong measurements. How the defect-class catalogue decides output granularity The clean way to plan this is to treat the defect-class catalogue as the driver and the model architecture as the consequence. For each defect class, write down the metric the spec gates on. Coverage percentage and defect size gating pull toward masks. Presence, count, and location pull toward boxes or labels. A mixed catalogue often means a mixed pipeline — a detector for the count-and-locate classes, a mask model applied only to the area-gated classes — rather than one segmentation model forced to do everything. That mapping is exactly what a CV-inspection feasibility audit produces: a defect-class-by-defect-class view of what output each class needs and what that output costs at throughput. It is the reason granularity is a per-class question, not a project-wide one. If you want to see where segmentation fits alongside detection and metrics like precision-recall trade-offs, our piece on what mAP@50 means for defect detection covers how detection accuracy is scored on your own defect set. FAQ What should you know about instance segmentation models in practice? An instance segmentation model assigns every pixel to a specific object instance, returning a class label and a pixel-accurate mask for each detected object — and separating overlapping objects into distinct instances. In practice this means you can measure a defect’s real area and shape, not just its position, which architectures like Mask R-CNN, Mask2Former, and the Segment Anything family all produce in different ways. How does instance segmentation differ from object detection and semantic segmentation in an inspection context? Object detection returns a box and label (“where and what”); semantic segmentation labels every pixel by class but cannot tell two touching objects apart; instance segmentation adds per-object masks that separate instances. On a line, detection suits count-and-locate decisions, semantic segmentation suits continuous coverage where instances don’t matter, and instance segmentation is needed only when each object must be measured separately by area or shape. When does a manufacturing defect actually require a per-pixel mask rather than a bounding box or a label? A mask is justified when the pass/fail decision is area- or shape-based — scratch area, coating coverage percentage, irregular contamination — where a bounding box would systematically over- or under-count. If the decision is presence, count, or location, a box or a label is enough and cheaper. A thin diagonal scratch fills only a small fraction of its own bounding box, so gating on box area mismeasures it; that is the signal a mask is required. What does instance segmentation cost in annotation effort and inference latency at line throughput? Mask annotation is far heavier than box annotation — in our labelling experience on industrial defect sets, roughly five to ten times longer per instance, though it varies with defect morphology (observed pattern, not a benchmarked rate). At run time the mask head adds inference work on top of detection, and what matters is sustained latency at your frame rate on the line’s actual hardware, not average latency on a dev machine. How does the defect-class catalogue decide whether segmentation is the right output granularity? Treat the catalogue as the driver: for each defect class, write down the metric the spec gates on. Coverage percentage and size gating pull toward masks; presence, count, and location pull toward boxes or labels. A mixed catalogue usually means a mixed pipeline rather than one segmentation model forced to handle every class. Why does imaging, lighting, and fixturing quality matter even more for pixel-accurate masks? A mask is only as reliable as the boundary the camera actually captures. Specular glare, inconsistent part positioning, and uncontrolled ambient light shift the mask edge by pixels, which directly corrupts the area measurement the spec depends on — whereas a slightly loose box can still be correct about pass/fail. Upgrading to masks on top of an uncontrolled imaging pipeline often makes results worse by exposing variance the box was quietly tolerating. How should a team scope an instance segmentation pipeline before committing to a pilot? Work through the defect-class catalogue and confirm each mask-candidate class has an area- or shape-based decision, that a box would mismeasure it, that overlapping instances need separating, that the imaging can resolve the boundary, and that the mask model clears the throughput budget on the deployment hardware. If those checks fail, a cheaper output granularity is the right call — which is what a CV-inspection feasibility audit is designed to surface. One more question worth asking first The question was never “should we use instance segmentation.” It is “which defect classes in our catalogue gate on area or shape, and can the imaging feed a mask model reliably at line speed.” Answer that per class and the architecture falls out of it — often as a mixed pipeline, rarely as one mask model doing everything. The remaining uncertainty is almost always empirical: you cannot know whether the throughput budget holds or whether the imaging resolves the boundary until you measure both on the real line. Scoping that as a defect-class feasibility audit — mapping each class to the output it needs and the cost that output carries — is the step that keeps a team from buying precision the line cannot use. Our computer vision services work starts exactly there.
