Occlusion and truncation

Two different ways an object is only partly visible, handled differently, and the reason engine-derived boxes differ from projected ones.

Occlusion#

One object hidden behind another.

In the identity buffer it needs no handling at all. The renderer had to decide which surface was in front in order to draw the frame, so the hidden pixels simply belong to the occluder. An object two-thirds behind a container contributes one-third of its pixels, and the box tightens by itself.

This is the concrete difference from projecting a 3D bounding box into the image: that approach produces a box around where the object would be, including the part behind the wall. A detector trained on those learns to predict boxes over things it cannot see.

Truncation#

An object cut off by the frame edge rather than by another object.

This is kept and flagged rather than dropped. A detector deployed on a real camera meets truncated objects constantly, and a training set that only contains whole ones has removed the case it most needs.

The report counts truncated instances per class, so a capture whose objects are mostly at the edges is visible as a number rather than a suspicion.

Visible pixels as a first-class value#

Every instance carries its pixel count. That single number supports several things that are otherwise guesswork:

• Filtering by visibility. Train only on objects above a threshold, or deliberately include the hard ones.
• Measuring occlusion. Pixel count against the object's unoccluded extent is an occlusion ratio.
• Explaining a failure. A model missing objects below a certain size is a checkable hypothesis rather than an impression.

What is not produced#