Stereoscopy.org Stereo Image Metadata 1.0

Status: Version 1.0 implementation specification

Namespace URI: https://stereoscopy.org/ns/stereo/1.0/

Preferred XMP prefix: stereo

1. Purpose

This specification provides a small public XMP vocabulary for declaring the views in a self-contained stereoscopic still image. It identifies how the views are stored, the eye perspective represented by each stored view, the preferred view for ordinary 2D display, and whether an individual viewpoint was synthesized.

It is deliberately a decoding and presentation declaration rather than an authenticity, provenance, or editing-history system. It does not declare AI use, software or model identity, ownership, or capture authenticity.

2. Design principles

3. Conformance language

The key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to be interpreted as described in BCP 14, RFC 2119 and RFC 8174, when and only when they appear in all capitals.

4. Data model

A declaration contains:

  1. one stereo:Format property;
  2. one ordered stereo:ViewSet array;
  3. one stereo:Perspective value for every view;
  4. an optional stereo:Primary=True on at most one view;
  5. an optional stereo:Synthesized=True on any synthesized view; and
  6. one stereo:AnaglyphComponent on every view when required by the selected format.

ViewSet is an XMP ordered array represented by rdf:Seq. Where a format has a physical or native view order, its entries appear in that order. A consumer MUST NOT assume that the first entry is the left-eye view. For a format such as anaglyph, whose views share one raster, the per-view properties identify how each logical view is represented.

Version 1.0 is designed for a two-eye stereo pair but consumers MUST process ViewSet as an array rather than hard-coding property names for a first and second view.

5. Properties

5.1 stereo:Format

Presence: REQUIRED

Type: open choice of Text

Format defines how ViewSet order maps to the stored asset.

Value ViewSet ordering
side-by-side leftmost raster region, then rightmost raster region
over-under top raster region, then bottom raster region
anaglyph views composited into one raster; each view names its encoded color component
google-vr ordinary/base JPEG image, then metadata-embedded companion image
apple-spatial native spatial image items in their native defined order
cipa-dc-006 native CIPA stereo views in their native defined order

The packed regions of side-by-side and over-under are equal-sized full-resolution views. No anamorphic stretching is implied.

An unregistered format MAY use an absolute HTTPS URI that publicly defines how ViewSet maps to a self-contained asset. Readers MUST NOT reject the XMP packet or image because a Format value is unknown.

5.2 stereo:ViewSet

Presence: REQUIRED

Type: ordered array of structured values (rdf:Seq)

Every entry represents one logical view encoded in the asset. Array order identifies storage position when the selected format defines one; fields inside the entry identify the logical properties of that view.

5.3 stereo:Perspective

Presence: REQUIRED on every view

Type: open choice of Text

Registered 1.0 values:

Value Meaning
left-eye A view intended for the viewer’s left eye
right-eye A view intended for the viewer’s right eye

Perspective does not identify a physical camera or a left/right/top/bottom storage position.

5.4 stereo:Primary

Presence: OPTIONAL on a view; True MUST occur on no more than one view

Type: Boolean

Primary=True recommends that view when a consumer needs to present only one conventional 2D image. It does not change storage order or eye identity.

When no primary is declared, a reader SHOULD choose the left-eye view. If no left-eye view can be identified, it SHOULD choose the first ViewSet entry.

Writers SHOULD omit Primary rather than write False on other views.

5.5 stereo:Synthesized

Presence: OPTIONAL on a view

Type: Boolean

Synthesized=True means that the viewpoint represented by this view was reconstructed or created rather than independently photographed. It does not identify a method. Geometric rendering, depth-based reconstruction, manual authoring, and other techniques can all satisfy this definition.

Cropping, alignment, color correction, retouching, stitching, and ordinary image editing do not by themselves make a viewpoint synthesized.

Writers SHOULD omit Synthesized rather than write False. Its absence means unspecified and MUST NOT be treated as proof of capture authenticity.

5.6 stereo:AnaglyphComponent

Presence: REQUIRED on every view for Format=anaglyph; omitted for other registered 1.0 formats

Type: open choice of Text

Registered 1.0 values:

Value Meaning
red The view is carried by the red component
cyan The view is carried by the cyan component
green The view is carried by the green component
magenta The view is carried by the magenta component
amber The view is carried by the amber component
blue The view is carried by the blue component

The value describes the color component carrying that particular view. The complete anaglyph pair is determined by reading the components and perspectives of all entries together. This allows eye order and color combinations to vary without creating additional Format values.

AnaglyphComponent identifies a nominal encoded component, not a precise color matrix, transfer function, glasses manufacturer, or ghost-reduction algorithm.

6. Canonical example

This side-by-side image stores a captured left-eye source in its left half and a synthesized right-eye view in its right half. The captured view is recommended for 2D display.

<rdf:Description
    rdf:about=""
    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
    xmlns:stereo="https://stereoscopy.org/ns/stereo/1.0/"
    stereo:Format="side-by-side">
  <stereo:ViewSet>
    <rdf:Seq>
      <rdf:li rdf:parseType="Resource">
        <stereo:Perspective>left-eye</stereo:Perspective>
        <stereo:Primary>True</stereo:Primary>
      </rdf:li>
      <rdf:li rdf:parseType="Resource">
        <stereo:Perspective>right-eye</stereo:Perspective>
        <stereo:Synthesized>True</stereo:Synthesized>
      </rdf:li>
    </rdf:Seq>
  </stereo:ViewSet>
</rdf:Description>

7. Common mappings

Creation or export path Declaration
Sequential two-view capture left-eye primary, then right-eye
Simultaneous multi-camera capture left-eye then right-eye; the preferred camera’s view is primary
Captured view with a synthesized counterpart captured view primary, synthesized view second
Two selected source images left-eye primary, then right-eye
Parallel still export side-by-side, left-eye then right-eye
Cross-eyed still export side-by-side, right-eye then left-eye
Red-cyan export anaglyph; red component on its carried view and cyan component on its carried view

Alignment, cropping, color matching, and watermarking preserve view properties. Reordering stored views reorders the corresponding ViewSet entries. Primary and Synthesized stay attached to their logical views.

Animated and video outputs, individually saved source photographs, and ordinary non-stereo images do not use this still-image declaration.

8. Native formats

For google-vr, GPano/GImage and Extended XMP rules remain authoritative. The stereoscopy.org declaration SHOULD be placed in the standard XMP packet so it can be discovered without reading the embedded image payload.

For apple-spatial, the HEIC stereo pair group and Apple spatial metadata remain authoritative for image-item identity, calibration, baseline, disparity, and field of view. The declaration is supplementary and SHOULD be associated with the primary image item.

For cipa-dc-006, the native CIPA structures remain authoritative. A generic MPF container is not necessarily stereo and MUST NOT use this value unless it satisfies the stereo-specific DC-006 contract.

9. Embedding

The declaration is stored as XMP:

Writers MUST preserve unrelated XMP properties whenever the container and writing API permit metadata-preserving updates. Readers MUST ignore unknown properties.

10. Compatibility and evolution

The namespace https://stereoscopy.org/ns/stereo/1.0/ identifies the compatible 1.x vocabulary family and is permanent.

Registered value sets are open choices. A later 1.x publication MAY add a format, perspective, or anaglyph component value without changing this namespace when the existing data model is sufficient. Consumers MUST tolerate unknown values and SHOULD preserve unknown metadata when rewriting an asset.

Existing property meanings, storage mappings, and defaults MUST NOT change within the 1.x namespace. An incompatible semantic change requires a new major specification and namespace.

Deprecated terms remain documented and MUST NOT be silently reassigned.

11. Removed draft terms

The pre-release terms FirstView, PrimaryView, SourceView, StereoOrigin, ViewOrigin, Derivation, and AnaglyphFilter are not part of version 1.0. ViewSet ordering and per-view properties replace them.