Video Metadata Question: Use cases & requirements for recording camera attributes

[rjksmith]

The issue of camera attributes was raised during the breakout discussion in the Spatial Data on the Web meeting on 25 June 2019 at OGC TC in Leuven, and identified in the conclusions as an outstanding question which should be addressed.

Question: Is there a requirement to record camera attributes, which attributes should be recorded and what are those use cases?

[rjksmith]

I've been thinking about a WebVMT solution for a while. Here are my thoughts so far to get the discussion underway.

Requirements & Use Cases

Good practice should be to record camera attributes where possible and their omission should indicate that the values are unknown, though some assumptions may be permitted. Consideration should also be given to the limitations of resource-poor devices which may be capturing the source data.

Cameras can be classified as follows:

• Mobile - able to change location during capture;
• Pivoting - able to change orientation during capture.

Each classification can be considered in turn.

1. Immobile, non-pivoting cameras, e.g. webcam, should specify their orientation if known. This can be done in the file header and should not be repeated in the file body. Location and orientation attributes should be included in the device configuration if suitable sensors are not included in the device.

2. Immobile, pivoting cameras, e.g. security camera, should specify their orientation if known. This could be done in the file body with updates at key intervals, so instantaneous values can be calculated by interpolation. Location and orientation attributes should be included in the device configuration if suitable sensors are not included in the device, and there may be a requirement to record orientation relative to the pivot's 'front' direction.

3. Mobile, non-pivoting cameras, e.g. dashcam or body-worn video, most often face forwards relative to the direction of motion, which should be the default orientation when no camera attributes are included. Cameras which face in another direction, e.g. vehicle reversing camera, should provide correct orientation details, which may raise a requirement for a relative orientation in the file header, e.g. relative direction = 180, to assist capture by resource-poor devices.

4. Mobile, pivoting cameras, e.g. helicopters, drones and smartphones, can face in any direction relative to their direction of motion and should record their orientation if known, e.g. not all smartphones have gyros or compasses.

All cameras should have:

1. An identifier, as there may be multiple cameras involved.

2. The option to record orientation in two possible formats:

   1. World orientation - relative to north;
   2. Platform orientation - relative to the camera platform, e.g. front, back-left, etc. In this case, world orientation of the camera platform should also be included to allow parity with the former option.

Attributes

3GP video provides a good starting point for camera attributes, with the following:

Attribute	Description
Digital zoom	Digital magnification scaling factor
Optical zoom	Optical magnification scaling factor
Pan indication	True or magnetic (north)
Pan	Angle from north in the horizontal plane
Tilt	Angle from the horizontal plane in the camera direction
Rotation	Angle from vertical in the camera direction

This only allows for a world orientation approach, but could be extended to include the platform orientation option.

[ogcscotts]

@rjksmith Also take a look at the proposed GeoPose Standards Working Group being considered in OGC. A draft charter is available here:
https://portal.opengeospatial.org/files/?artifact_id=83801&version=1

The charter is currently under revision after discussion at the last TC Meeting.

Geopose is defined as a 6-degree of freedom position and orientation. If we can share an approach with OGC Moving Features, Geopose, and WebVMT, then we have some good consistency.

[rjksmith]

Migrated to W3C WebVMT Community Group issue. Thanks to all contributors for their input.