Skip to content

Introducción y Arquitectura Nuclear ​

Object Interactive Media (OIM) es una arquitectura de medios abierta, centrada en metadatos (metadata-first), diseñada para transformar gráficos estáticos en medios web interactivos, accesibles y dinámicos.

Durante décadas, la web ha dependido de formatos rasterizados estáticos (JPEG, PNG, WebP) y contenedores de vídeo lineales (MP4, WebM). En estos formatos tradicionales, el diseño gráfico, los textos traducidos, los botones de acción y la identidad de marca quedan irreversiblemente "quemados" (baked) en una matriz plana de píxeles. Aunque son universalmente compatibles, los medios quemados introducen graves cuellos de botella en el desarrollo web contemporáneo.

OIM rediseña los medios digitales desde el nivel del contenedor desacoplando los píxeles visuales inmutables de los metadatos declarativos.


La Filosofía de Medios con Metadatos (Metadata-First) ​

En el modelo tradicional, un banner publicitario o tarjeta de producto traducida a 12 idiomas exige generar, almacenar, distribuir y cachear 12 archivos de imagen independientes. Si un redactor detecta una errata, es necesario invalidar megabytes de caché en las redes de distribución de contenido (CDN) y forzar a los clientes a descargar el archivo nuevamente.

text
MEDIO TRADICIONAL PLANO (BAKED):
┌────────────────────────────────────────────────────────┐
│  Imagen Rasterizada Aplanada (5 MB)                    │
│  [ Píxeles de Fondo + Texto No Seleccionable + Botón ] │
└────────────────────────────────────────────────────────┘
❌ Inaccesible para lectores de pantalla (falla WCAG)
❌ Cero indexación SEO de textos incrustados
❌ Explosión de archivos: 10 idiomas × 3 formatos = 30 archivos
❌ No responsivo: el texto se reduce a micro-píxeles ilegibles

MEDIO DECLARATIVO OIM:
┌────────────────────────────────────────────────────────┐
│  Contenedor Estándar (.png / .mp4)                     │
│  ├── Capa +1:   Slots Dinámicos (JSON DOM, vivos)      │
│  ├── Capa 0:    Separador (simbólico, no almacena nada)│
│  └── Capa −1:   Píxeles horneados (en la imagen)       │
└────────────────────────────────────────────────────────┘
✅ Elementos DOM HTML5/SVG 100% accesibles
✅ Cambio de idioma instantáneo en el cliente (un solo archivo)
✅ Tipografía responsiva mediante Container Query Width (cqw)
✅ Adaptación temática total con tokens de Colores Dinámicos

Principios Fundamentales de OIM ​

  1. Compatibilidad Retroactiva con Contenedores Nativos: Un archivo .oim es un archivo PNG estrictamente estándar que contiene un chunk estándar zTXt con la clave OIM_Data. Cualquier visor heredado, navegador antiguo o aplicación de mensajería muestra la imagen base con total fidelidad sin requerir software especial.
  2. Accesibilidad Nativa: Todos los textos dinámicos, etiquetas y enlaces renderizados por <oim-player> existen como nodos reales en el DOM dentro de un Shadow DOM encapsulado. El texto puede seleccionarse, copiarse, ser interpretado por lectores de pantalla y ser indexado por motores de búsqueda.
  3. Tipografía Responsiva: En lugar de tamaños fijos en píxeles que se vuelven ilegibles en pantallas móviles, los estilos tipográficos de OIM utilizan unidades de contenedor (cqw - Container Query Width). La tipografía escala de forma fluida y proporcional al ancho del visor.
  4. Fuente Única de Verdad: Un único archivo .oim empaqueta diccionarios multilingües completos (content: { en: "...", es: "...", de: "..." }), eliminando la proliferación innecesaria de recursos.

La Arquitectura de Separación en 3 Capas ​

El núcleo técnico de OIM se fundamenta en un modelo estricto de tres capas de renderizado y seguridad:

text
┌─────────────────────────────────────────────────────────────────────────┐
│ CAPA +1 · DINÁMICA (SLOTS VIVOS, COMPUESTOS POR EL PLAYER)              │
│ • Diccionarios multilingües ({ en: "Buy", es: "Comprar" })              │
│ • Botones, zonas y figuras vectoriales (geo, svg, draw, mask)           │
│ • Animaciones WAAPI por keyframes (t, o, s, r, x, y, b, e)              │
│ • Filtros y máscaras que el autor dejó vivos (resueltos en ejecución)   │
│ • Paralaje 2.5D y disparadores interactivos (hover / active)            │
│ • Tokens de color semánticos (var(--oim-color-primary))                 │
├─────────────────────────────────────────────────────────────────────────┤
│ CAPA 0 · SEPARADOR (SIMBÓLICA, NO ALMACENA NADA)                        │
│ • La línea entre lo que se convirtió en píxeles y lo que sigue vivo     │
├─────────────────────────────────────────────────────────────────────────┤
│ CAPA −1 · HORNEADA (LOS PÍXELES)                                        │
│ • Píxeles PNG (IDAT) o fotogramas de vídeo (MP4/WebM)                   │
│ • Lo que el autor fijó en la imagen: fondos, fotos, formas,             │
│  y filtros o máscaras horneados si los hay                              │
│ • Sellada mediante SHA-256 (image_hash)                                 │
└─────────────────────────────────────────────────────────────────────────┘

Capa −1 · Horneada ​

Los píxeles del PNG (o los fotogramas del vídeo en OVM). Contiene lo que el autor decide fijar en la imagen desde el editor («Fijar en la imagen»), de cualquier tipo de capa: fondos, fotografías, formas y también filtros y máscaras si el autor los hornea. Puede incluir tipografía horneada si el autor fijó texto en la imagen. Cualquier visor de imágenes la muestra.

  • Cero sobrecarga de rendimiento: Al almacenarse en flujos estándar (IDAT de PNG o pistas de vídeo), los navegadores la decodifican directamente con aceleración por hardware, sin asignar memoria en JavaScript ni copiar en canvas.
  • Vínculo criptográfico por hash: Cada documento .oim incluye la propiedad image_hash, con el hash SHA-256 de los bytes de la imagen horneada. Forma parte de la serialización canónica firmada con ECDSA P-256 por el autor o el backend. Si un atacante altera un solo píxel de la imagen horneada, la validación del hash falla de inmediato.

Capa 0 · Separador ​

Solo simbólica: no almacena nada. Es la línea entre lo que se convirtió en píxeles (Capa −1) y lo que sigue vivo (Capa +1).

Capa +1 · Dinámica ​

La Capa +1 es el plano interactivo y visual ejecutado por el reproductor web, compuesto sobre la imagen horneada:

  • Primitivas de Slot: Admite 13 tipos de capas estructurales y visuales: text, image, lottie, zone, geo, draw, filter, container, group, component, mask, svg y pattern.
  • Máquina de Estados: Cada slot puede declarar estados hover y active con duraciones de transición personalizadas, transformaciones (scale, rotation, opacity) y acciones (show, hide, toggle, setText).
  • Web Animations API (WAAPI): Animaciones de línea de tiempo compiladas en arrays optimizados de keyframes (keyframes: [{ t: 0, s: 1 }, { t: 0.5, s: 1.2 }]) muestreados a 20 FPS o interpolados mediante funciones cúbicas de Bézier.
  • Tracking Espaciotemporal: En vídeo interactivo (.ovm), los slots se anclan a objetos en movimiento mediante interpolación continua de cuadriláteros a 60 FPS (tracking_data).
  • Filtros y máscaras vivos: Filtros backdrop CSS (brillo, contraste, saturación, rotación de tono y desenfoque), grafos de filtros SVG (calado de máscaras, matrices de color bitono) y directivas shader_fx (desenfoque, grano analógico, curvatura CRT). Las capas de filtro (type: "filter") y las máscaras de troquel se resuelven en tiempo de ejecución con computeLayerComposition(), garantizando cero degradación de la imagen.

Los filtros y las máscaras no son una capa propia: cada uno está horneado (−1) o es dinámico (+1), y el autor decide por capa. Una opción del proyecto puede hornear todas las capas visibles para obtener una miniatura completa, a costa de que el texto aparezca dos veces (en los píxeles y dibujado por el player).


Resumen de Especificaciones Técnicas ​

CaracterísticaEspecificaciónReferencia Estándar
Formato de Contenedor (Imagen)PNG (Portable Network Graphics)ISO/IEC 15948:2004
Chunk de MetadatosChunk zTXt (OIM_Data)Especificación PNG 1.2
Algoritmo de CompresiónDeflate Raw (wbits = -15) + Base64RFC 1951
Protección contra DescompresiónLímite Estricto de 10 MBDefensa contra Zip Bombs
Firma CriptográficaNIST P-256 (secp256r1) + SHA-256FIPS 186-4, IEEE P1363
Formato de Firma64 bytes raw (r, s) Big-Endian Base64IEEE P1363
Unidades ResponsivasContainer Query Width (cqw)CSS Containment Level 3
Colores Dinámicos8 Roles Semánticos vía Variables CSSModelo de Tokens Material You
Componentes Web<oim-player>, <ovm-player>W3C Custom Elements v1