Cameras

Where the camera stands and what it looks at decides your dataset's coverage. Everything else is downstream of that, and it is the part people spend the least time on.

Placement modes#

Combined with a look-at policy, these produce the camera policy recorded in the capture. The reference capture used camera_zones_look_at_target: sampled inside camera zones, aimed at the target zone.

When a fixed camera is right#

It is tempting to treat fixed as the boring option. For a large class of real problems it is the correct one.

A camera bolted to a wall or a mast sees exactly one viewpoint for its entire service life. Training it on varied viewpoints spends model capacity on a variation that will never occur. For that deployment, the thing to vary is everything else: lighting, weather, time of day, occupancy, and what is in the scene.

Coverage is a property you author#

The distributions on a finished dataset are the shape of the zones you drew. That sounds obvious and is routinely forgotten: a dataset whose camera pitch spans only 13° to 43° spans that range because the camera zones were placed at those heights, not because of anything about the scene.

Check the distance and view-angle distributions in the report before generating at volume. Discovering that every frame is from 80 metres is much cheaper at frame 40 than at frame 40,000.

What gets recorded#

Per frame: position, quaternion, Euler angles, look-at point, field of view, the zone the placement came from, the policy, and the viewpoint validation result. Positions are in metres, in a named coordinate frame.

Both rotation representations are written deliberately. The quaternion is for maths; the Euler angles are for working out why a frame looks wrong.