Hay un momento en todo vuelo de dron sobre patrimonio en el que te das cuenta de que la toma perfecta está justo ahí, al alcance de tu mano, y que no la puedes hacer. No porque el dron no llegue, ni porque las condiciones climáticas no lo permitan, sino porque es la normativa la que dice que no. Y tiene todo el sentido del mundo que así sea.
Este artículo documenta cómo, partiendo de un vuelo legal y responsable en el entorno del Teatro Romano de Itálica (Santiponce, Sevilla), he utilizado fotogrametría e IA generativa para crear secuencias renderizadas en 4K que complementan las tomas reales, para dar una visión más completa del entorno, respetando la normativa de uso de drones. El vídeo es el siguiente:
Y casi más interesante que el vídeo en sí es el proceso para realizarlo.
El marco legal: por qué no puedes hacer lo que quieras con un dron
Antes de hablar de tecnología, hay que hablar de burocracia. Y no como queja, sino como contexto imprescindible. Volar un dron en España, especialmente sobre patrimonio histórico en zona urbana, implica un marco regulatorio con varias capas:
- AESA (Agencia Estatal de Seguridad Aérea): Define las categorías de vuelo (abierta, específica, certificada), las limitaciones de altura (120m máximo), distancia a personas, y las zonas restringidas. Un dron como el que yo utilizo, el DJI Mini 3 Pro, al pesar menos de 250g, permite operar en categoría abierta subcategoría A1, pero con restricciones sobre sobrevuelo de personas no participantes.
- Ministerio del Interior: Cualquier vuelo en zona urbana requiere comunicación previa. No es un permiso como tal, es una notificación, pero hay que hacerla, y hay que hacerla bien.
- Patrimonio Cultural: Volar sobre un BIC (Bien de Interés Cultural) como el Teatro Romano de Itálica añade otra capa. No es lo mismo sobrevolar una zona urbana que hacer un vuelo rasante sobre las gradas de un teatro romano del siglo I.
- Ordenanzas municipales: Porque siempre hay una ordenanza municipal.
El resultado práctico es que puedes hacer un vuelo orbital a 40-60 metros de altura con cierta comodidad, pero las tomas bajas sobre la estructura, los pasantes rasantes sobre las gradas, o los cenitales ascendentes desde la propia orchestra son, como mínimo, complicados de justificar ante las autoridades. Y con razón: estamos hablando de un yacimiento arqueológico protegido.
Validación de conformidad: la telemetría como garantía
Hay algo que rara vez se menciona en los tutoriales de drones y que en la práctica marca la diferencia entre un vuelo profesional y uno amateur: la capacidad de demostrar que tu vuelo se ajustó al plan comunicado.
Cuando notificas un vuelo al Ministerio del Interior, incluyes un plan con la zona de operación, altitudes previstas y horario. Lo que no suele hacerse — y debería — es validar a posteriori que el metraje que vas a publicar corresponde efectivamente a ese plan. Los archivos SRT del DJI son un registro involuntario pero extraordinariamente detallado: coordenadas GPS, altitud relativa y absoluta, 30 veces por segundo durante todo el vuelo.
Con Claude Code escribí un validador que cruza la telemetría SRT contra el polígono del plan de vuelo. Para cada frame de cada vídeo, calcula si la posición GPS está dentro de la zona autorizada y si la altitud respeta los límites comunicados. El resultado es un informe por toma:
- Conforme: toda la telemetría dentro de la envolvente del plan.
- Parcialmente conforme: el grueso del vuelo dentro del plan, con desviaciones puntuales (una ráfaga de viento que desplaza el dron tres metros fuera del polígono durante un segundo, por ejemplo).
- No conforme: segmentos fuera de la zona autorizada.
Los segmentos no conformes se descartan del flujo de trabajo. Esto no es solo una precaución legal, es un principio ético: si el metraje no corresponde a un vuelo autorizado, no se utiliza. Punto. Los casos parcialmente conformes se revisan manualmente: un desplazamiento puntual por viento no es lo mismo que una excursión deliberada fuera de zona.
Este paso de validación, que se ejecuta en segundos, convierte la telemetría del dron de un dato pasivo en una herramienta de compliance activa. Y, de paso, filtra automáticamente los fotogramas válidos para la fotogrametría posterior: solo entran en el flujo de trabajo de OpenDroneMap los fotogramas tomados dentro de la zona autorizada.
El problema creativo: las tomas que faltan
Con las restricciones claras y la telemetría validada, hice mi vuelo en Itálica un 31 de marzo, al amanecer, buscando la hora dorada en la que la luz baña el entorno en unos tonos fabulosos. Usé el DJI Mini 3 Pro, con configuración de vídeo a 4K, 30fps y D-Cinelike; realicé varias pasadas orbitales desde la zona notificada, y un par de ascensos. Obtuve un material sólido, pero al revisar el metraje en DaVinci Resolve, la historia que quería contar tenía huecos evidentes:
- Un cenital ascendente desde la orchestra, revelando progresivamente la forma semicircular del graderío. La toma que tienes en la cabeza antes de llegar al sitio, pero que no haces porque implica volar desde dentro del recinto arqueológico.
- Un vuelo pasante a baja altura cruzando el teatro. La más cinematográfica de todas, y la más incompatible con un vuelo responsable en el entorno de un BIC.
- Una espiral envolvente con varias vueltas completas. La hice parcialmente, pero una ráfaga de viento arruinó la suavidad del movimiento en la segunda vuelta.
La pregunta era: ¿era posible generar estas tomas sin volver a volar?
La respuesta: fotogrametría + renderizado 3D asistido por IA
La idea es conceptualmente sencilla: si tengo suficiente metraje del teatro desde distintos ángulos, puedo reconstruir un modelo 3D texturizado del yacimiento y luego mover una cámara virtual por donde quiera, sin restricciones de espacio aéreo. La ejecución, como siempre, es donde se complican las cosas.
Paso 1: Extracción de fotogramas con telemetría (Claude Code)
Los vídeos del DJI Mini 3 Pro vienen acompañados de archivos SRT con telemetría frame a frame: GPS, altitud, ISO, velocidad de obturación, exposición. Información valiosísima que normalmente se ignora.
Con Claude Code escribí un script Python (prepare_odm.py) que extrae fotogramas del vídeo a intervalos regulares y les inyecta la información GPS en los metadatos EXIF de cada imagen. El resultado que obtuve con mi metraje fue el de 768 fotogramas JPEG geolocalizados, listos para fotogrametría.
La clave aquí es que el SRT del DJI tiene resolución de ~33ms, así que cada fotograma extraído tiene coordenadas precisas; no es una aproximación: sabemos exactamente dónde estaba el dron y hacia dónde miraba en cada fotograma.
Paso 2: Reconstrucción 3D con OpenDroneMap
Los 768 fotogramas se procesaron en WebODM (la interfaz web de OpenDroneMap) a través de su API REST. Esto es algo que ya tenía montado en mi proyecto de fotogrametría con app Android, y en el que la API de ODM está ya configurada. La API es uno de esos recursos que, una vez que los descubres, no entiendes cómo habías podido vivir sin ellos.
Una vez procesada la secuencia en ODM, éste generó los siguientes objetos:
- Nube de puntos densa del yacimiento
- Modelo de malla texturizado (OBJ + 103 texturas PNG)
- Ortofoto georreferenciada
El modelo texturizado es lo que nos interesa: 172.000 caras con textura fotorrealista derivada directamente del metraje original. No es un modelo paramétrico idealizado, sino que es la realidad capturada desde el aire, con sus imperfecciones, sus hierbas creciendo entre las piedras, y la luz del amanecer sevillano.
Paso 3: Corrección de color — el problema de D-Cinelike
Aquí hay que detenerse un poco, porque este paso es más importante de lo que parece a primera vista y tiene implicaciones en todo el ciclo de procesamiento.
Qué es D-Cinelike y por qué se graba así
D-Cinelike es un perfil de color logarítmico que DJI incluye en sus drones. Frente al perfil «Normal», que produce una imagen lista para ver (con colores saturados y contraste alto), D-Cinelike captura la imagen de manera deliberadamente plana: baja saturación, bajo contraste, sombras levantadas y luces altas comprimidas.
La pregunta es: ¿por qué querría alguien grabar vídeo que parece desvaído y grisáceo? Pues por la misma razón por la que un fotógrafo profesional dispara en RAW en vez de en JPEG: el rango dinámico. D-Cinelike preserva más información en sombras y altas luces que el perfil Normal, a costa de requerir un procesado posterior (lo que en cine se llama color grading). En una escena como Itálica al amanecer, con sombras duras en las gradas y cielo brillante al fondo, la diferencia entre perder o retener detalle en esos extremos puede ser de dos o tres stops.
El problema es que ese procesado posterior tiene que realizarse. Si usas los fotogramas D-Cinelike directamente — como textura de un modelo 3D, por ejemplo — el resultado es un modelo fotogramétrico con aspecto enfermizo: colores apagados, contraste inexistente, como si le hubieras puesto un filtro de niebla a las ruinas romanas.
La corrección automática para fotogrametría
Para las 103 texturas PNG que ODM generó, Claude Code aplicó una corrección de color programática usando numpy y PIL. No es un auto-enhance genérico — es una curva diseñada específicamente para invertir las características de D-Cinelike para las secuencias específicas que realicé:
- Gamma 0.92: compensa la curva logarítmica del perfil, devolviendo la respuesta tonal a algo más cercano a la percepción lineal.
- Contraste ×1.25: restituye la separación tonal que D-Cinelike aplana deliberadamente.
- Balance RGB: R+8%, G+2%, B-6%. D-Cinelike tiende a un cast ligeramente frío, especialmente al amanecer. Este ajuste devuelve calidez sin pasarse.
- Elevación de sombras +3%: recupera detalle en las zonas oscuras de las gradas sin quemar las altas luces.
- Saturación ×1.38: el número que más sorprende. D-Cinelike desatura agresivamente; un factor de 1.38 puede parecer excesivo, pero el resultado es una saturación natural, no exagerada.
Esta corrección se aplicó directamente a las texturas PNG del modelo dentro del flujo de procesado. El resultado es un modelo 3D con colores realistas que coinciden razonablemente con lo que el ojo humano vería en el teatro romano de Itálica a esa hora de la mañana.
La generación de un LUT para DaVinci Resolve
Pero la corrección de las texturas es solo la mitad del problema. Los vídeos originales del dron también están en D-Cinelike, y hay que corregirlos en DaVinci Resolve para el montaje final. Y aquí es donde entra un concepto clave: el LUT.
Un LUT (Look-Up Table) es, en esencia, una tabla de traducción de colores. Para cada combinación posible de RGB de entrada, define qué RGB de salida debe producir. Es el equivalente digital de un filtro fotográfico, pero con precisión matemática: no es «más cálido» o «más contrastado» en abstracto, sino «el píxel (128, 120, 135) se convierte exactamente en (142, 118, 122)».
DaVinci Resolve trabaja nativamente con LUTs en formato .cube — un archivo de texto que define una rejilla 3D de correspondencias de color. Lo elegante del asunto es que la misma curva de corrección que se aplicó a las texturas del modelo se puede exportar como un LUT .cube y cargarlo en DaVinci como corrección base para todo el metraje.
Claude Code generó un LUT de 33 puntos (33×33×33 = 35.937 muestras en el espacio RGB) que codifica exactamente la misma transformación: gamma, contraste, balance RGB, saturación. El resultado es que el metraje original del dron y las secuencias renderizadas desde el modelo 3D comparten la misma base de color. No son idénticos — el renderizado EEVEE y el sensor CMOS del dron responden de manera diferente a la luz —, pero parten del mismo punto de referencia cromático, lo que simplifica enormemente el matching posterior en DaVinci.
La alternativa habitual — descargar un LUT genérico «D-Cinelike to Rec.709» de internet y rezar para que funcione — es una lotería. Cada escena tiene su luz, su rango dinámico, su balance de blancos. Un LUT generado a partir del propio metraje, con parámetros ajustados a las condiciones reales de captura, es siempre mejor que uno genérico. Y generarlo es cuestión de segundos.
Y este punto es muy relevante: a los puristas de DaVinci no les gusta hacer uso de LUTs porque les parece un recurso fácil para vagos (por lo que comentábamos antes, un LUT genérico difícilmente se adaptará a tus condiciones concretas), y prefieren hacer uso de edición de colorimetría avanzada mediante la generación de una serie de nodos en la pestaña de edición de color de DaVinci. Un proceso que requiere un buen rato de ajustes y validaciones para obtener un buen resultado, y eso contando con que tú mismo tengas un buen trasfondo técnico para saber exactamente lo que estás haciendo. Sin embargo, afrontarlo de la manera en la que lo hice con Claude Code produce resultados perfectos en lo dicho, apenas segundos.
Paso 4: Importación y preparación en Blender (MCP)
Aquí es donde entra uno de los elementos tecnológicos más interesantes del proceso: el MCP (Model Context Protocol) de Blender. Un servidor MCP permite que Claude Code controle Blender programáticamente — ejecutar código Python en Blender, hacer capturas del viewport, gestionar la escena, todo desde la línea de comandos.
¿Por qué es esto relevante? Porque la importación del modelo ODM en Blender no es trivial. El modelo viene en coordenadas UTM con un offset de cientos de miles de metros, las texturas ya corregidas desde D-Cinelike, y hay que recortar la malla para quedarse solo con el teatro, eliminando los edificios del pueblo colindante.
A través del MCP, Claude Code pudo:
- Importar el OBJ con la orientación correcta de ejes (UTM usa Y-forward, Z-up)
- Analizar la densidad de vértices para localizar la orchestra (la zona más plana y baja del modelo)
- Recortar la malla con un radio circular centrado en el teatro
- Centrar el modelo en el origen de Blender
- Configurar iluminación, cielo y cámara para los renders
Todo esto realizado de manera iterativa, con capturas de viewport para verificar cada paso. El MCP convierte a Blender en una herramienta programable dentro del flujo de trabajo de IA, con lo que hace que no se necesite tocar la interfaz gráfica para nada.
Paso 5: Creación de tomas virtuales en 4K
Con el modelo limpio en Blender, crear las tomas que faltaban fue cuestión de definir trayectorias de cámara:
- El cenital ascendente arranca a 7.4 metros sobre la orchestra. La cámara mira recto hacia abajo y asciende hasta 46 metros, revelando progresivamente las gradas semicirculares. Para alinear la cávea con el encuadre, hubo que ajustar la rotación de la cámara en incrementos de 5° hasta clavar los 112.5° exactos. El resultado fue un ascenso suave, que desvela la magnificencia del teatro en todo su esplendor.
- El vuelo pasante describe una línea recta SW→NE a 60 metros de altitud constante, que muestra en un primer término la parte superior de las gradas del teatro, posteriormente el foso, el escenario y la fachada escénica. Tras probar varias orientaciones, la que mejor funcionó fue la cámara mirando hacia atrás durante el pasante, de tal manera que se ve el teatro acercarse, pasar bajo tus pies, y alejarse.
- La espiral envolvente hace dos vueltas completas con radio creciente (45→85 metros) y ascenso gradual. Se aplicó una función smoothstep para suavizar el arranque y la frenada, algo que con el dron real es casi imposible de conseguir, especialmente con viento.
- Y, por último, el sweep lateral, un vuelo guiado por trazo libre: Este último render nace de una idea simple: ¿y si pudiera dibujar directamente sobre el modelo la trayectoria que quiero que siga la cámara? Blender lo permite con su herramienta de anotación. Tracé una línea azul sobre la vista cenital del modelo, marcando un arco amplio que parte del suroeste, bordea el teatro por su flanco noroeste y termina al noreste. Claude Code interpretó ese trazo a partir de un screenshot del viewport, extrajo la dirección y curvatura, y lo tradujo en una curva Bézier de cinco puntos de control con altitud variable (37-40 metros sobre la orquesta). La cámara recorre esa curva en 15 segundos, apuntando en todo momento al centro de la orchestra mediante un constraint Track To, lo que produce un movimiento envolvente muy natural, como si el dron rodeara el monumento manteniendo siempre el punto de interés centrado en el encuadre. El resultado es un plano que ningún vuelo real del día capturó: un sweep lateral suave que revela progresivamente la cavea, la orchestra y la scaenae frons desde un ángulo que habría requerido una planificación de vuelo específica. Es precisamente aquí donde el gemelo digital demuestra su valor — no como sustituto del metraje real, sino como complemento que permite explorar perspectivas que no se contemplaron en campo.
Todos los renders se generaron a 3840×2160 a 29.97fps con EEVEE, exactamente el mismo formato que los vídeos originales del DJI, lo que permite mezclarlos en la timeline de DaVinci Resolve sin conversión de formato.
Paso 6: Montaje final en DaVinci Resolve
En DaVinci Resolve, las secuencias renderizadas se integran con el metraje real. Ambos parten de la misma corrección de color: el LUT D-Cinelike generado se aplica al metraje original, y las texturas del modelo ya llevan la corrección equivalente; así que la continuidad cromática es razonable desde el primer momento. No es perfecta (el renderizado EEVEE no tiene la misma respuesta lumínica que el sensor del dron), pero con un grade fino en DaVinci y transiciones bien elegidas, el resultado es convincente.
La cadena tecnológica completa
Si tuviera que resumir el flujo de procesamiento en una línea, sería algo como lo que sigue:
DJI Mini 3 Pro → Claude Code (validación telemetría + extracción frames + corrección color + LUT) → OpenDroneMap API (modelo 3D) → Blender MCP (escena + render 4K) → DaVinci Resolve (montaje con LUT)
Cada eslabón es interesante por sí solo, pero lo realmente potente es la integración: Claude Code actúa como pegamento entre todos los sistemas. Valida la conformidad del vuelo, parsea los SRT del DJI, genera la corrección de color y el LUT, llama a la API de ODM, controla Blender vía MCP, y genera los comandos ffmpeg para el ensamblaje final. Un único agente orquestando herramientas que, individualmente, no saben nada las unas de las otras.
Reflexión: complementar, no falsificar
Hay una línea que conviene no cruzar: estas secuencias renderizadas complementan el metraje real, no lo sustituyen. El modelo 3D proviene del propio vuelo, por lo que no es un modelo inventado ni una IA imaginando cómo sería el teatro: es la misma realidad capturada, pero vista desde ángulos que no pudimos grabar.
Y hay otra línea igual de importante: la del cumplimiento normativo. La tecnología que permite generar tomas virtuales no es excusa para volar donde no se debe, confiando en que «ya lo arreglo en postprocesado». Es exactamente lo contrario: vuelas dentro del marco legal, validas que así ha sido, y usas la tecnología para ir más allá de lo que ese marco permite capturar. El orden importa.
La tecnología no elimina la necesidad de volar bien y de volar legal. Lo que hace es ampliar lo que puedes contar con el material que ya tienes. Y a veces, las mejores tomas son las que haces sin despegar. 
