Occluded object bounding box labeling for training

Partly hidden parts create a labeling problem before they create a model problem. A box around visible evidence means something different from a box predicting the complete object behind an obstruction. Mixing those meanings makes training and evaluation inconsistent.

For inspection datasets, start by defining what the production decision needs to know. Then write a policy covering visible fragments, uncertain identities, image-edge truncation, and ignored regions. The procedure below gives you a repeatable annotation rule, worked coordinates, and validation checks before you expand the dataset.

Decide what the detector must report

Use visible-extent boxes when the task is to locate identifiable evidence of a part. The box encloses the visible portions belonging to that instance, without estimating its hidden outline. This is a practical starting point for presence detection and identifying parts in overlapping arrangements.

Use amodal boxes only when the required output is the estimated complete object extent, including hidden portions. That is a different prediction target. It needs suitable training labels, a defensible source for hidden geometry, and evaluation against the same definition.

Neither convention is universally correct. The failure is switching conventions between images, annotators, or evaluation sets.

Write the intended output as a sentence before drawing boxes:

A detector trained to find visible evidence does not establish that a hidden feature exists or passes inspection. Keep presence detection separate from completeness verification.

Define the visible box precisely

A visible-extent bounding box is the smallest axis-aligned rectangle enclosing all visible portions of one identifiable instance. It is not a segmentation mask, and it will often contain background or part of an occluder.

Suppose a bracket is visible on both sides of a cable. If those portions clearly belong to the same bracket, draw one box around their combined visible extent. Do not create separate instances for the fragments unless the task explicitly defines them as separate targets.

Likewise, do not remove the occluder from the box by shrinking it until a genuine target fragment falls outside. Boxes cannot describe holes or disconnected outlines. If those distinctions matter, consider the annotation geometry discussed in drawing segmentation label polygons.

Worked coordinate example

Assume an image is 1000 pixels wide and 800 pixels high. The visible target reaches continuous image-edge coordinates of x = 120 to 260 and y = 80 to 180. Its hidden body might extend farther, but that estimate is not part of this label.

For a normalized center-and-size representation:

The arithmetic is:

• Width: 260 − 120 = 140 pixels.
• Height: 180 − 80 = 100 pixels.
• Center: (190, 130) pixels.
• Normalized center: (190 / 1000, 130 / 800) = (0.190, 0.1625).
• Normalized size: (140 / 1000, 100 / 800) = (0.140, 0.125).

Confirm the annotation tool's coordinate convention before export. Integer pixel indices, continuous edge coordinates, and inclusive endpoints are not interchangeable without conversion.

Give each difficult case an explicit policy

A useful annotation document distinguishes uncertainty about position from uncertainty about identity. A small fragment can have a clear boundary while providing insufficient evidence to identify its class.

For overlapping objects of the same class, assign separate boxes only when the instances can be distinguished reliably. Do not invent instance boundaries where the image cannot support them.

Keep examples of accepted and rejected labels beside the policy. An illustrated edge-case sheet usually resolves disagreements faster than adding more abstract wording.

Do not confuse unlabeled targets with background

Leaving a visible target unlabeled is not automatically equivalent to ignoring it. In many detector training pipelines, an unlabeled target can contribute negative supervision, depending on the loss and target-assignment implementation.

An annotation tool may offer a difficult or ignore flag, but the exported dataset and training loader must preserve its meaning. A flag that disappears during conversion provides no protection.

Use one of these documented approaches:

• Include the instance when it satisfies your written eligibility rule.
• Use an ignore region or difficult-instance mechanism that the actual training and evaluation pipeline supports.
• Exclude the image when ambiguous content cannot be handled correctly.
• Use an approved crop that removes the ambiguous region, then review every remaining label.

Do not assume that a validity mask supported by one training system is supported by another. The guide to excluding ambiguous regions with a validity mask explains the distinction between marking uncertainty and treating it as a negative example.

Keep genuine empty scenes as negatives. They answer a different question from scenes containing uncertain fragments; see background images in object detection training.

Turn the policy into a repeatable labeling workflow

Use a small pilot batch before labeling the full collection. For example, choose 60 images spanning clear objects, overlapping objects, edge truncation, and ambiguous fragments. That is a workflow example, not a universal dataset requirement.

1. Write the eligibility rule. State which classes must be identifiable and what evidence qualifies an instance for labeling.
2. Define box geometry. Specify visible extent or amodal extent, coordinate conventions, and how disconnected portions are grouped.
3. Define uncertainty handling. Record the supported ignore mechanism or the conditions requiring image exclusion.
4. Label the pilot independently. Have separate annotators work from the same instructions without copying each other's boxes.
5. Review disagreements by category. Separate missed instances, class disagreements, fragment grouping, and boundary placement.
6. Revise the policy before scaling. Add representative examples and relabel affected pilot images.
7. Inspect the exported training input. Render the actual boxes read by the training loader, after resizing, cropping, and augmentation.

A universal minimum visibility percentage is usually a weak substitute for this process. A small exposed identification feature may be decisive, while a much larger plain surface may remain ambiguous.

If you use a minimum box size, treat it as a measured dataset rule rather than a general detection law. Review objects near that boundary and verify that the rule matches production needs.

Check whether the visible evidence has enough pixels

Annotation cannot restore detail that acquisition never captured. When occlusion leaves only a small distinguishing feature, check its sampling before changing the labeling convention.

For a flat target near the calibrated object plane, a simple horizontal estimate is:

Suppose the horizontal field of view is 200 mm, and an exposed distinguishing feature is 4 mm wide. An engineering trial target of 24 pixels across that feature requires:

The 24-pixel target is an example to test, not a guaranteed detection threshold. Blur, contrast, pose, and model resizing can still remove useful information.

Repeat the calculation at the model's effective input scale. If a 2400-pixel-wide image is reduced to 1200 pixels, a feature originally spanning 48 pixels spans about 24 pixels afterward. Cropping and letterboxing require their own coordinate checks.

Validate the policy against the inspection decision

Split training and evaluation data by physical part, capture sequence, or production batch where practical. Near-identical neighboring frames in both sets can make performance look better than deployment conditions justify.

Build evaluation groups for clear objects, moderate occlusion, severe occlusion, image-edge truncation, and crowded scenes. If the true unobscured shape is unknown, use documented qualitative groups rather than inventing precise visibility percentages.

Measure both detection performance and the final inspection outcome:

• Recall for eligible visible instances.
• False detections per image or per inspection cycle.
• Class confusion on partially hidden targets.
• Duplicate detections around disconnected fragments.
• Box localization under the selected annotation convention.
• Cases where detection is mistaken for proof of completeness.

For example, detecting 90 of 100 eligible instances gives recall of 90 / 100 = 90%. Twelve false detections across 1000 inspected images gives 12 / 1000 = 0.012 false detections per image. Report both, rather than a single headline score.

State whether ignored instances are excluded from evaluation and how predictions overlapping ignored regions are handled. Otherwise, two reports can disagree despite using the same images.

When misses and extra detections need further separation, use the guide to interpreting a detection background confusion matrix. For visual audits, saving annotated inspection images helps preserve the image, prediction, and decision together.

Choose acquisition hardware without assuming model support

Choose hardware after defining the inspection output and visible-detail requirement. A different camera does not resolve contradictory labels, but a better view may expose features that were previously hidden.

For host-based acquisition, compare area scan cameras in the camera finder. Check image detail, shutter behavior, triggering, and compatibility with your acquisition software against the actual application.

One catalog option to review is the LS-CMR-0166 area scan camera. Confirm its suitability against the acquisition requirements rather than treating it as a validated solution for a particular detector.

For on-device inspection, compare smart cameras and vision sensors. Before selecting that architecture, confirm supported inspection tools, model formats, preprocessing, memory limits, and result interfaces through the documented product workflow.

The LS-SMC-0063 smart camera is another catalog option to assess. Its inclusion here does not establish compatibility with a custom training framework or an ignore-label mechanism.

Start the camera configuration workflow once the required view and acquisition architecture are defined.

Know when visible-extent boxes are the wrong answer

Visible boxes are insufficient when the decision requires the complete hidden outline, an accurate grasp location derived from hidden geometry, or proof that an obscured feature is acceptable. Those tasks require additional evidence or a different output definition.

Possible alternatives include changing the viewpoint, presenting the part differently, adding another view, or using a task-specific geometric model. Any inferred hidden geometry should remain distinguishable from direct observation.

If occlusion makes the inspection impossible, define an explicit insufficient-visibility outcome. A missing detection should not silently become an acceptable part, especially when the required feature was never visible.

Before expanding the dataset, check:

• Every labeled instance follows the same visible or amodal convention.
• Disconnected fragments are grouped consistently.
• Ambiguous targets are not silently converted into background.
• Exported ignore information reaches training and evaluation correctly.
• Resizing preserves enough detail for the smallest required evidence.
• Evaluation includes realistic overlap and truncation cases.
• The production decision handles insufficient visibility explicitly.

Next, pilot the policy on representative inspection images before committing to full annotation. Use the camera finder to compare acquisition options, or contact the applications team with the field of view, smallest exposed feature, and representative occlusion cases.