Video tradicional (mp4)
Regenera el fotograma completo
Tiempo de la operación ~128 s
Los 40 tiles se recalcularon, aunque solo uno estuviera dañado.
Investigación en curso · 2026
Un formato de video que guarda la estructura de la escena
Intermediate Video Project (IVP) guarda, junto a los píxeles de cada fotograma, la identidad, la forma y la posición de cada elemento de la escena, y de qué depende cada uno. Sobre esa estructura se probó corregir un elemento sin volver a generar el fotograma completo.
Lo que existe es un formato de datos y un editor de referencia que lo ejercita. No hay producto terminado, ni aplicación instalable, ni resultados de calidad de producción: los datos de prueba son videos de pocos segundos a 320x180, elegidos para que el pipeline se pueda leer entero.
17
experimentos independientes
19
hipótesis de diseño evaluadas
221
tests automatizados, 201 sin GPU
2
motores de render intercambiables
Qué cambia con este formato
El video deja de ser una foto del resultado
Un video tradicional (mp4, mov) es un flujo de píxeles comprimido: no sabe qué hay dentro de cada fotograma, solo cómo se ve. Si algo sale mal en una sola parte, hay que regenerar todo o editarlo a mano, fotograma por fotograma.
IVP cambia el punto de partida: en vez de guardar el resultado final, guarda la información
con la que se construyó cada elemento. Es el mismo cambio de perspectiva que ya existe en
otras disciplinas: un archivo .blend no es un .png, y un plano arquitectónico no es una foto del edificio terminado.
Toca las capas para separarlas.
Pasa el mouse sobre las capas para separarlas.
01
Corrección por elemento
Se editó la taza y la mesa, el fondo y el resto de la escena quedaron sin cambios.
02
Corrección por tile
Cuando el error era más chico que el objeto, se recalculó únicamente el tile afectado.
03
Recompilación de lo que cambió
El editor recalcula solo lo que depende del cambio, con la misma lógica que la compilación incremental de un compilador.
Medición principal
Reparar un tile frente a regenerar el fotograma
Se dañó un tile de un fotograma y se cronometraron las dos formas de arreglarlo: volver a generar el fotograma entero con el modelo, o recalcular únicamente el tile afectado. El experimento partió el fotograma en 40 tiles.
Formato IVP
Recalcula solo el tile dañado
Tiempo de la operación 2.2 ms
Se recalculó el tile 19. Los otros 39 quedaron idénticos, verificados por hash.
Condiciones de esta medición
Las dos cifras se tomaron sobre el mismo fotograma de 320×180 dividido en 40 tiles, con Stable Diffusion 1.5 sobre una GPU local. La reparación no invoca al modelo: reutiliza el resultado ya calculado para los 39 tiles restantes, y ahí está la diferencia de tiempo. El cociente entre ambas, unas 56 900 veces, depende por completo de este montaje - con otro modelo, otra resolución o más tiles cambia. Se reporta la comparación, no el cociente como propiedad del formato.
Fotogramas de la corrida
Las operaciones, antes y después
Cada pestaña parte de una escena y le pide un cambio. Arrastra el control para superponer el resultado sobre su escena base y ver qué parte de la imagen se modificó. Las dos últimas repiten las mismas operaciones sobre una escena de lámpara.
Cambiar el color de la taza
La taza quedó verde. El pedestal, el fondo y la sombra proyectada no cambiaron: al comparar por hash, los tiles que no contienen la taza son idénticos a los de la escena base.
Añadir una segunda taza
La taza celeste apareció en primer plano y la roja quedó intacta. El tiempo de la operación fue el mismo que regenerar la escena completa: aquí se preservan los píxeles, pero todavía no se ahorra cómputo.
Eliminar la taza
La taza se quitó de la escena. Donde estaba el cuerpo quedaron franjas horizontales de color, y sobre el pedestal se mantuvo una sombra elíptica. Esto es lo que devolvió esta corrida sobre esta escena; la pestaña de la lámpara muestra la misma operación sobre otra.
Añadir una segunda lámpara
La segunda lámpara apareció a la derecha y el resto de la escena se mantuvo: la lámpara grande, los objetos naranjas y la superficie quedaron como estaban.
Eliminar la lámpara
La lámpara se quitó de la escena. Quedaron la superficie y el resplandor sobre la pared del fondo.
Fotogramas de 320x180 generados con Stable Diffusion 1.5 sobre una GPU local. Dentro de cada operación, el antes y el después salen de la misma escena, así que se pueden comparar píxel a píxel. Se muestran sin recortar ni retocar.
Salidas del formato
Un proyecto, PNG o MP4
Un proyecto IVP describe la escena, no la imagen. De esa descripción se exporta un fotograma suelto en PNG o una secuencia completa en MP4, y el motor de render se puede cambiar sin tocar los datos. Las dos salidas de abajo se produjeron con motores distintos.
PNG
Motor con Stable Diffusion 1.5 - Resolución
- 320x180
- Contenido
- Un fotograma
Un fotograma suelto de la escena. Es la salida que se usó para medir la reparación por tile, porque permite comparar dos versiones píxel a píxel.
MP4
Motor geométrico determinista- Fotogramas
- 30 a 10 fps
- Peso del archivo
- 2.8 KB
Un cuadrado rojo sobre fondo azul que pasa a verde a lo largo de 30 fotogramas. Este motor no invoca al modelo de difusión: dibuja figuras planas de forma determinista, y por eso el archivo pesa 2.8 KB y la corrida no necesita GPU.
Las dos salidas provienen de experimentos distintos, así que no muestran la misma escena. Lo que comparten es el formato de proyecto que las describe.
Con medición
Resultados medidos
Cada uno de estos seis resultados viene de una corrida del proyecto, con su experimento, su código y sus tests. Todos se obtuvieron sobre escenas pequeñas a 320×180, que es el alcance de las pruebas hechas hasta ahora.
56,915×
más rápido
Corregir un fragmento, no regenerar el fotograma
Reparar un tile dañado tomó 2.2 milisegundos, frente a los ~128 segundos de regenerar ese mismo fotograma con Stable Diffusion 1.5 en GPU local. El video deja de ser un bloque monolítico y pasa a ser piezas independientes.
verificado byte a byte
El ciclo completo corre con IA real
Una instrucción en español ("cambia el color de la taza") edita el proyecto, el proyecto se renderiza con Stable Diffusion 1.5, se exporta a un mp4 y luego se corrije un elemento sin tocar el resto. Verificado con hash byte a byte, no a ojo.
video a datos
El video se puede leer de vuelta
Se tomó un mp4 ya generado y se reconstruyeron las especificaciones originales a partir de él. El ciclo se cierra en ambas direcciones.
86%
menos peso
El formato pesa menos que el video
Para una escena simple, el formato de datos pesa 86% menos que el video equivalente. La ventaja crece con más elementos en la escena, no con más resolución.
2
invocaciones en vez de 20
Determinismo: 2 invocaciones en vez de 20
Un video de 20 fotogramas con 2 tramos de color distinto solo necesitó 2 llamadas al modelo: la misma especificación con la misma semilla produce siempre la misma imagen. Una corrida real bajó de ~49 minutos a 4.6 minutos.
3
niveles navegables
Un objeto se edita por partes
Jerarquía navegable de tres niveles (objeto, parte, textura): editar el asa de una taza sin tocar el cuerpo, en vez de tratar el objeto como un bloque.
Estado real
Qué existe hoy y qué no
IVP es un proyecto de investigación de Artificial Peaks S.A.S. B.I.C. Los datos de prueba son pequeños a propósito: videos de pocos segundos a 320×180, un tamaño que permite leer el pipeline completo y verificar cada paso a mano.
Lo que ya está construido
- El formato IVP y un editor de referencia que lo usa.
- 17 experimentos independientes, cada uno con su código y sus tests.
- 19 hipótesis de diseño evaluadas: 17 demostradas, 2 abiertas a propósito.
- 221 tests automatizados (201 corren siempre; 20 requieren GPU real).
- Dos motores de render intercambiables: uno geométrico determinista y uno con Stable Diffusion 1.5 en GPU local, sin cambiar el contrato de datos.
Lo que todavía no incluye
- Interfaz gráfica.
- API pública.
- Autenticación.
- Comprensión de lenguaje natural libre: el vocabulario de instrucciones es acotado, no un LLM completo.
Sin medición todavía
Resultados que no podemos afirmar
Los cinco puntos que siguen quedaron identificados durante el trabajo, sin medición que los respalde. Cada uno indica qué falta para poder afirmarlo.
- 01
Añadir un elemento todavía cuesta lo mismo
Con IA real, añadir un elemento sigue costando lo mismo que regenerar la escena completa: no hay ahorro de tiempo todavía, aunque sí de preservación de píxeles. Ya se identificó la causa (el modelo generaba a una resolución mayor de la necesaria) y se construyó la solución (pedir un lienzo más chico, con una mejora teórica de 3.16× menos cómputo).
Pendiente: La medición real en GPU todavía no se hizo.
- 02
El "aprendizaje" spec a imagen es una prueba mínima
Un clasificador k-NN (no un modelo de difusión entrenado) demuestra que la relación entre la especificación y la imagen es aprendible en principio.
Pendiente: No existe todavía un modelo entrenado sobre IVP.
- 03
La edición por lenguaje natural es acotada
El sistema entiende instrucciones de un patrón conocido, con un vocabulario delimitado.
Pendiente: No es un LLM libre: no acepta cualquier forma de pedir las cosas.
- 04
Dos hipótesis quedan abiertas a propósito
Cómo traducir mejor una intención humana al "idioma" que mejor entienden los modelos de imagen y video; y si se puede cerrar un ciclo automático que verifique reconstruyendo los datos completos, no solo con un sí/no si una generación salió como se pidió.
Pendiente: Documentadas como preguntas abiertas, no como promesas.
- 05
No todo salió bien a la primera
Al editar una imagen generada, "eliminar un objeto" dejó rayas de color visibles antes de corregirlo, y "añadir un objeto" produjo una imagen irreconocible hasta que se ajustó dónde se ubicaba.
Pendiente: Ambos se corrigieron y quedaron documentados, incluyendo el intento fallido.
Construir encima
Trabajo sin hacer
El núcleo se mantiene mínimo a propósito. Lo que sigue son ocho frentes que quedaron sin tocar, listados para quien quiera tomarlos. Artificial Peaks no se compromete a ninguno ni tiene fecha para ellos.
-
Medir en GPU real el ahorro del lienzo mínimo Medición pendiente
Al añadir un elemento, el modelo genera a una resolución mayor que la necesaria. Se construyó la corrección (pedir un lienzo más chico) y el cálculo da 3.16× menos cómputo, pero ese número sigue siendo teórico: falta cronometrarlo en GPU.
-
Un visualizador o inspector del proyecto
Árbol de elementos, línea de tiempo con keyframes y vista previa, sin tener que exportar a video para ver el resultado.
-
Un modo conversacional de edición
En vez de una instrucción por línea, una sesión donde se refina el video paso a paso y el sistema mantiene el contexto.
-
Adaptadores hacia herramientas establecidas
Blender, After Effects, DaVinci Resolve o Figma, traduciendo datos en ambas direcciones.
-
Renderizadores alternativos conectables
WebGL, Blender headless, render ASCII para terminal o APIs cloud: el contrato de render es el mismo sin importar la tecnología detrás.
-
Entrenar un modelo real sobre el formato
Ir más allá del clasificador simple ya probado y entrenar sobre datos en formato IVP.
-
Un corrector automático de generación con IA
Hoy solo se verifica con un sí/no. Falta reconstruir los datos completos desde la imagen generada y compararlos contra lo que se pidió.
-
Versionado tipo control de código
El formato es JSON legible y ordenado de forma predecible, así que se podría hacer diff entre dos versiones de un mismo proyecto.
Reproducir
Cómo verificar estos resultados
El pipeline se corre desde la terminal. Las salidas de las corridas que se reportan en esta
página están en examples/ del repositorio, así que se pueden revisar sin instalar nada.
ivp-format - bash
# menos de un minuto, sin GPU
$ make install
$ make ci
✓ lint · types · 201 tests
# un experimento puntual
$ make run-exp-CAPSTONE
→ output/capstone.mp4 ▋
- 1
git clone https://github.com/artificialpeaks/ivp-format.git
Clonar el repositorio.
- 2
make install
Crea el entorno e instala las dependencias.
- 3
make ci
Corre lint, chequeo de tipos y tests. Toma menos de un minuto y no requiere GPU.
- 4
make run-exp-XX
Corre un experimento puntual y muestra un resultado real. Por ejemplo, make run-exp-CAPSTONE genera un video con IA (requiere GPU y más tiempo).
Repositorio público
Código bajo licencia Apache 2.0. El contenido generado con modelos de terceros (Stable Diffusion 1.5, sobre todo) se rige por la licencia de cada modelo.
Tres lecturas
Para quién es esto
Investigación
Investigadores y curiosos técnicos
Quieren revisar el formato y decidir si les sirve de base. Encuentran cada resultado con sus condiciones de medición, y las dos hipótesis que quedaron abiertas.
Ver los resultados medidosComunidad
Quien quiera usarlo o mejorarlo
Gente que puede clonar el proyecto, correrlo y decidir si quiere contribuir. El core es mínimo a propósito: hay bastante terreno abierto para construir encima.
Cómo correrloGeneral
Quien solo quiere entender qué es
Sin conocimiento técnico: qué problema aborda el formato y cómo se ve funcionando. La comparación entre recalcular un tile y regenerar el fotograma se entiende sin jerga.
Ver la comparaciónPreguntas sobre el proyecto
Si algo de este informe no queda claro, si encuentras un error en una medición o si quieres usar el formato, escríbenos.