Skip to content

Introduction & Core Architecture ​

Object Interactive Media (OIM) is an open, metadata-first media architecture designed to bridge the gap between static graphic assets and modern, interactive web applications.

For decades, the web has relied on "baked" raster media formats (JPEG, PNG, WebP) and linear video containers (MP4, WebM). In these traditional formats, graphic elements, localized copy, interactive buttons, and branding are permanently flattened into pixels. While universally compatible, baked media introduces profound architectural bottlenecks for contemporary software systems.

OIM re-engineers digital media from the container level up by cleanly decoupling immutable visual assets from declarative metadata.


The Metadata-First Philosophy ​

In traditional web delivery, a marketing banner or product card translated into 12 languages requires generating, storing, delivering, and caching 12 distinct bitmap files. If a copywriter fixes a typographical error, megabytes of image data must be invalidated across Content Delivery Networks (CDNs) and re-downloaded by clients.

text
TRADITIONAL BAKED MEDIA:
┌────────────────────────────────────────────────────────┐
│  Flattened Raster Image (5 MB)                        │
│  [ Background Pixels + Non-Selectable Text + Baked UI ]│
└────────────────────────────────────────────────────────┘
❌ Inaccessible to screen readers (WCAG failure)
❌ Zero SEO indexing of embedded text
❌ Asset explosion: 10 languages × 3 ratios = 30 files
❌ Non-responsive: text scales down into illegible pixels

OIM METADATA-FIRST MEDIA:
┌────────────────────────────────────────────────────────┐
│  Standard Container (.png / .mp4)                      │
│  ├── Layer +1:  Dynamic Slots (JSON DOM, live)         │
│  ├── Layer 0:   Separator (symbolic, stores nothing)   │
│  └── Layer −1:  Baked Pixels (fixed in the image)      │
└────────────────────────────────────────────────────────┘
✅ 100% accessible HTML5/SVG DOM elements
✅ Instant client-side locale switching (single file)
✅ Responsive typography via Container Query Width (cqw)
✅ Fully themeable via Dynamic Colors semantic tokens

Core Principles of OIM ​

  1. Native Container Backward Compatibility: An .oim file is a valid, standard PNG image containing a standard zTXt chunk named OIM_Data. Any legacy viewer, image viewer, or messaging app renders the baked base image without error.
  2. Accessible by Default: All dynamic text, callout badges, and links rendered by <oim-player> exist as real DOM nodes inside a Shadow DOM tree. Text is selectable, readable by assistive screen readers, and indexed by search engine crawlers.
  3. Responsive Typography: Instead of fixed pixel sizes that shrink into unreadable micro-text on mobile devices, OIM text styles utilize Container Query Width units (cqw). Typography scales smoothly relative to the container element.
  4. Single Source of Truth: A single .oim file bundles multilingual translation dictionaries (content: { en: "...", es: "...", de: "..." }), eliminating asset duplication.

The 3-Layer Separation Architecture ​

The core foundation of OIM is its strict three-layer separation model:

text
┌─────────────────────────────────────────────────────────────────────────┐
│ LAYER +1: DYNAMIC SLOTS (LIVE, COMPOSED BY THE PLAYER)                  │
│ • Localized text dictionaries ({ en: "Buy", es: "Comprar" })            │
│ • Buttons, zones and vector shapes (geo, svg, draw, mask)               │
│ • WAAPI keyframe animations (t, o, s, r, x, y, b, e)                    │
│ • Filters and masks the author left live (resolved at runtime)          │
│ • 2.5D parallax and interactive triggers (hover / active)               │
│ • Semantic theme tokens (var(--oim-color-primary))                      │
├─────────────────────────────────────────────────────────────────────────┤
│ LAYER 0: SEPARATOR (SYMBOLIC, STORES NOTHING)                           │
│ • The line between what became pixels and what stays live               │
├─────────────────────────────────────────────────────────────────────────┤
│ LAYER −1: BAKED (THE PIXELS)                                            │
│ • PNG pixels (IDAT) or video frames (MP4/WebM), decoded natively        │
│ • Whatever the author fixed in the image: backgrounds, photos, shapes,  │
│  and any filters or masks baked in                                      │
│ • Sealed via SHA-256 image_hash                                         │
└─────────────────────────────────────────────────────────────────────────┘

Layer −1 · Baked ​

The pixels of the PNG (or the video frames for OVM). It holds whatever the author chooses to fix in the image in the editor (Fix in image), of any layer type: backgrounds, photographs, shapes, and also filters and masks if the author bakes them. It may contain baked typography if the author fixed text in the image. Any ordinary image viewer shows it.

  • Zero Overhead: Because the baked image is stored as standard PNG pixel streams (IDAT) or standard video tracks, modern browsers decode it directly through hardware-accelerated media decoders. It requires zero JavaScript memory allocation or canvas pixel blitting.
  • Cryptographic Hash Binding: Every .oim document embeds an image_hash property containing the SHA-256 hash of the baked image data. This hash is included in the canonical serialization signed by the author's private key via ECDSA P-256. If a malicious actor alters a single pixel of the baked image, the SHA-256 verification fails instantly.

Layer 0 · Separator ​

Symbolic only: it stores nothing. It is the line between what became pixels (Layer −1) and what stays live (Layer +1).

Layer +1 · Dynamic ​

Layer +1 is the presentation and interaction plane executed by the web player, composed on top of the baked image:

  • Slot Primitives: Supports 13 structural and visual primitives: text, image, lottie, zone, geo, draw, filter, container, group, component, mask, svg, and pattern.
  • State Machine: Each slot can declare hover and active states with customizable transition durations, transformations (scale, rotation, opacity), and actions (show, hide, toggle, setText).
  • Web Animations API (WAAPI): Timeline-driven animations compiled into efficient keyframe arrays (keyframes: [{ t: 0, s: 1 }, { t: 0.5, s: 1.2 }]) sampled at 20 FPS or interpolated via cubic-bezier timing functions.
  • Spatial Tracking: In video media (.ovm), slots bind to moving visual targets across time using 60 FPS temporal quad-bounding-box interpolation (tracking_data).
  • Filters and masks left live: CSS backdrop filters (brightness, contrast, saturation, hue rotation, blur), SVG filter graphs (mask feathering, duotone color matrices), and shader_fx directives (blur, film grain, CRT curvature). Filter slots (type: "filter") and cutout masks are resolved at runtime by computeLayerComposition(), ensuring zero raster degradation.

Filters and masks are not a layer of their own: each one is either baked (−1) or dynamic (+1), and the author decides per layer. A project option can bake every visible layer for a complete thumbnail, at the cost of the text appearing twice (in the pixels and drawn by the player).


Technical Specifications Summary ​

FeatureSpecificationStandard Reference
Container Format (Image)PNG (Portable Network Graphics)ISO/IEC 15948:2004
Container ChunkzTXt Chunk (OIM_Data)PNG Specification 1.2
Compression AlgorithmRaw Deflate (wbits = -15) + Base64RFC 1951
Decompression Safeguard10 MB Maximum Decompressed Buffer LimitZip Bomb Defense
Digital SignatureNIST P-256 (secp256r1) + SHA-256FIPS 186-4, IEEE P1363
Signature EncodingRaw 64-byte (r, s) Big-Endian Base64IEEE P1363
Responsive UnitsContainer Query Width (cqw)CSS Containment Level 3
Dynamic Colors8 Semantic Roles via CSS Custom PropertiesMaterial You Token Model
Web Components<oim-player>, <ovm-player>W3C Custom Elements v1