Transferencia de Movimiento de Cámara: IC-LoRA Cameraman v2 + LTX 2.3

Hace poco me propuse algo que parecía complicado: tomar el movimiento de cámara de un vídeo y aplicarlo a otro completamente distinto sin tocar el contenido original. Resulta que existe una herramienta específica para esto en ComfyUI llamada IC-LoRA Cameraman v2, diseñada exactamente para transferir únicamente cómo se mueve la cámara (paneo, empuje, ángulo, tracking) de un vídeo de referencia a un vídeo nuevo generado con IA. Pasé dos días probándola de verdad, generé tres vídeos diferentes, me encontré un bug de RAM del sistema que casi me tira todo por la borda, y aquí está lo que aprendí sobre esta técnica de camera control en LTX video.

Con la evolución de LTX 2.3, la transferencia de movimiento de cámara ha dado un salto cualitativo. Este artículo documenta una prueba real del workflow IC-LoRA Cameraman v2, incluyendo configuración, ajustes y solución de problemas encontrados durante la generación.

De un vistazo: IC-LoRA Cameraman v2 en ComfyUI

Qué es IC-LoRA Cameraman v2 y cómo funciona

IC-LoRA Cameraman v2 es un LoRA (adaptador de bajo rango) creado por Cseti, disponible en HuggingFace bajo el repositorio Cseti/LTX2.3-22B_IC-LoRA-Cameraman_v2. El checkpoint que usé es el del paso 14000. La idea es simple en teoría pero efectiva en práctica: funciona con LTX Video 2.3 mediante un sistema de condicionamiento en contexto (in-context conditioning) que permite transferir patrones de movimiento de cámara sin tocar el contenido visual.

Lo que diferencia este approach de ControlNet clásico o motion-transfer tradicional es que IC-LoRA no necesita una arquitectura de control separada. Funciona directamente dentro del modelo LTX 2.3 como un ajuste fino muy específico: le enseña al modelo a reconocer y reproducir movimientos de cámara cuando se le proporciona un vídeo de referencia, pero sin que eso afecte al contenido de la escena generada. Dicho de otro modo, el IC-LoRA Cameraman en ComfyUI aísla completamente el patrón de movimiento del contenido visual.

👉 Lo clave: IC-LoRA Cameraman v2 es un LoRA especializado que transfiere solo el movimiento de cámara dentro de LTX 2.3, sin alterar el contenido de la imagen inicial ni requerir arquitecturas de control externas.

Aclaración importante: el pipeline completo vs. la prueba real

Existe un vídeo en YouTube del canal Benji’s AI Playground titulado “LTX 2.3 New Camera Control Using IC-LoRA + Krea 2 + Boogu Edit Mix Models” que describe un pipeline mucho más elaborado para escenas complejas. Ese flujo incluye:

1. Generar elementos por separado con Krea 2 (personaje, fondo, etc.)
2. Componerlos con Boogu Image 0.1 Edit
3. Una segunda pasada de Krea 2 para recuperar textura
4. Finalmente, LTX 2.3 + IC-LoRA para la transferencia de cámara

El workflow de ese vídeo es exclusivo para suscriptores Patreon, así que no pude reproducirlo tal cual. En mi prueba real, usé el workflow oficial y gratuito que el propio Cseti publica en HuggingFace (Cseti/ComfyUI-Workflows, ruta ltx/2.3/ic-lora-cameraman-v2/), y no incluí Boogu Image 0.1 Edit en ningún momento.

¿Por qué? Porque la escena de prueba era un plano único sin necesidad de composición de elementos. El fotograma inicial se generó en un único paso directo de texto-a-imagen con Krea 2 Turbo. Aquí está la verdad: Boogu Edit es útil para escenas complejas donde necesitas separar y recomponer elementos, pero el IC-LoRA funciona igual de bien con imágenes generadas de forma simple, porque lo único que hace es transferir el movimiento de cámara, sea cual sea el origen del fotograma inicial.

👉 Lo importante: No necesitas el pipeline completo de Krea 2 + Boogu Edit para usar IC-LoRA Cameraman. El workflow oficial de Cseti es suficiente para planos únicos o imágenes simples; Boogu Edit solo es necesario si necesitas componer múltiples elementos.

El workflow: configuración real y adaptaciones necesarias

El workflow oficial de Cseti (workflow.json) es imagen-a-vídeo: una imagen de referencia define el fotograma inicial, y un vídeo de referencia alimenta el guiado del IC-LoRA. También funciona en modo texto-a-vídeo si dejas la imagen inicial vacía.

Lo adapté como workflow_adapted.json con estos cambios:

• UNETLoader → UnetLoaderGGUF: cambié el nodo para apuntar a ltx-2.3-22b-dev-Q6_K.gguf en lugar de descargar el fp8_scaled completo de 22GB
• Nodos de optimización en bypass: desactivé LTX2MemoryEfficientSageAttentionPatch y PathchSageAttentionKJ porque la librería sageattention no estaba instalada. Son solo para velocidad, no afectan calidad ni resultados del camera control

Los modelos que tuve que descargar nuevos fueron:

También instalé tres custom nodes nuevos: comfyui-int-and-float, ComfyUI_Fill-Nodes y RES4LYF. El workflow depende además de ComfyUI-LTXVideo, ComfyUI-KJNodes, ComfyUI-VideoHelperSuite y rgthree-comfy, que ya tenía de pruebas anteriores.

💡 Consejo: Si no quieres descargar los ~22GB del transformer fp8_scaled completo, busca si ya existe una variante GGUF cuantizada (como el Q6_K que usé aquí) antes de lanzarte a la descarga grande. El bypass de los nodos de SageAttention es igual de válido si esa librería no está instalada en tu entorno: solo pierdes algo de velocidad, no calidad.

Los tres intentos reales: de lo sintético a lo funcional

Primer intento: vídeo de referencia sintético

Comencé con un vídeo de referencia generado con ffmpeg zoompan: una panorámica lateral simple sobre una imagen de un coche descapotable rojo vintage en un cañón del desierto al atardecer (generada con Krea 2 Turbo). El prompt para el vídeo final fue completamente distinto: una escena de café con cruasán en una mesa de cafetería junto a una ventana.

Resultado: la técnica de transferencia de movimiento de cámara funcionó. El movimiento de cámara se transfirió de forma coherente y visible. El contenido era totalmente distinto entre referencia y resultado, exactamente lo que se esperaba. Pero como el vídeo de referencia era sintético, no fue un caso de uso realista.

Primer intento: arriba, la panorámica sintética sobre el coche descapotable (referencia); abajo, el resultado sobre la escena de café generada, con contenido completamente distinto pero el mismo movimiento de cámara.

Segundo intento: vídeo de referencia real, movimiento sutil

Pasé a usar un vídeo real grabado por mí: movimiento sutil de paneo e inclinación sobre un micrófono y un bote de bolígrafos en un escritorio. La transferencia funcionó técnicamente, pero el resultado (resultado_camara_real.mp4) quedó poco vistoso como demo porque el movimiento de referencia era demasiado sutil. Esto me enseñó una lección importante: un movimiento de cámara discreto da un resultado técnicamente correcto pero poco demostrable.

Segundo intento: el movimiento se transfiere (compáralo tú mismo arriba/abajo), pero es tan sutil que apenas se aprecia como demo — la razón por la que se grabó un tercer vídeo con movimiento más marcado.

Tercer intento: movimiento de cámara real y marcado (el que funciona)

Grabé un segundo vídeo de referencia real con movimiento mucho más deliberado: empuje de cámara (dolly-in) combinado con panorámica, pasando de plano general a primer plano, sobre el mismo micrófono y bolígrafos.

Para este test generé una imagen inicial nueva con un prompt diseñado a propósito:

“Una GPU RTX con ventiladores ARGB en tonos morado y cian, sobre un escritorio de noche, teclado mecánico desenfocado en primer plano, cables RGB visibles”

Se generó con Krea 2 Turbo (8 pasos, cfg 1, sampler euler, scheduler simple, denoise 1, seed 987654321), en un único paso texto-a-imagen sin edición ni composición posterior. El prompt fue deliberado para dar buena separación de planos y encajar con la temática de ComfyLab.

Resultado: resultado_camara_real_v2.mp4, el vídeo que funciona de verdad. El movimiento de cámara (empuje + panorámica) se transfiere con claridad y coherencia. Comparé fotogramas frame a frame y el seguimiento del movimiento de referencia es evidente.

Vídeo demo real del tercer intento: empuje de cámara + panorámica transferidos sobre la escena de la GPU RTX con escritorio de noche. Resolución 960x1084, 24 fps, ~5.04 segundos.

👉 Lo que aprendí: La transferencia de movimiento de cámara funciona mejor con movimientos deliberados y visibles. Los movimientos sutiles son técnicamente correctos pero menos demostrables visualmente.

Ajustes clave del autor original: qué cambiar para mejores resultados

El README oficial del workflow de Cseti incluye recomendaciones específicas. Usé estos valores tal cual y me funcionaron — no probé variarlos uno a uno (una sola resolución, un solo valor de image strength), así que lo que sigue es lo que el autor recomienda y lo que yo apliqué, no una verificación independiente punto por punto:

Resolución: según el autor, cuanta más resolución, más se sigue el movimiento de referencia. No bajar de 960x512 en la primera pasada. Mi vídeo final fue 960x1084, y el resultado siguió el movimiento con claridad — pero no probé resoluciones más bajas para comparar, así que no puedo confirmar la relación con datos propios.

Image strength del conditioning: usar valores entre 0.5 y 0.7. Este parámetro equilibra la fidelidad al fotograma inicial frente a cuánto se transfiere la cámara de referencia. Valores más bajos (dentro de ese rango) = más movimiento respecto a la imagen inicial, según indica el propio autor — menos fidelidad al fotograma de partida deja más margen para que el movimiento de referencia se imponga.

El prompt de texto importa: afecta directamente al movimiento de cámara resultante. Si el vídeo no sigue el movimiento de referencia esperado, el autor recomienda: dejar el prompt vacío, cambiar de seed, o describir el movimiento de cámara al menos a nivel general en el prompt.

⚠️ Importante: El workflow oficial solo expone este único parámetro de “image strength” para equilibrar fidelidad al fotograma inicial y movimiento transferido — no hay un control separado de “cantidad de movimiento”. Si el resultado no sigue bien la cámara de referencia, la primera palanca a tocar es este valor, no busques un parámetro que no existe en el grafo.

El bug real: OOM de RAM del sistema, no VRAM

Durante las pruebas de este workflow, ComfyUI se cayó por completo sin traceback justo al decodificar el VAE final de vídeo+audio. El sistema estaba usando aproximadamente 27GB de 31GB de RAM total. La GPU tenía margen de VRAM de sobra, así que el problema no estaba ahí.

Causa: RAM del sistema agotada durante la decodificación de vídeo y audio simultáneamente.

Solución: cerré un navegador con muchas pestañas abiertas. Liberé suficiente RAM para que la generación completa terminara sin problemas. Tardó 12 minutos en total.

Lección práctica: en workflows LTX 2.3 + IC-LoRA que decodifican vídeo y audio juntos, vigilar la RAM del sistema es tan importante como vigilar la VRAM. Un proceso puede caerse por RAM incluso con GPU sobrada.

Descarga del workflow y especificaciones del vídeo final

Especificaciones técnicas del vídeo final (verificadas con ffprobe):

Requisitos mínimos para ejecutar: GPU con 24GB de VRAM, margen amplio de RAM libre del sistema (el bug real de OOM ocurrió con ~27GB de 31GB ya en uso, así que cuanta más RAM libre antes de lanzar la decodificación final, mejor), y ComfyUI con los custom nodes mencionados instalados.

Preguntas frecuentes

¿Qué hace exactamente el IC-LoRA Cameraman v2 en ComfyUI?

Transfiere únicamente el movimiento de cámara (paneo, empuje, ángulo, tracking) de un vídeo de referencia a un vídeo nuevo generado con contenido completamente distinto. No copia el contenido del vídeo de referencia, solo cómo se mueve la cámara. Esto fue confirmado en las tres pruebas reales con contenido de referencia y resultado totalmente distintos entre sí.

¿Hace falta Boogu Image 0.1 Edit o Krea 2 para usar este workflow?

No necesariamente. El vídeo de YouTube que inspiró la técnica describe un pipeline más elaborado (Krea 2 + Boogu Image 0.1 Edit + Krea 2 de nuevo) para componer escenas con varios elementos separados, pero en una prueba real con un plano único no hizo falta ese paso de composición: basta con generar el fotograma inicial en un solo paso de texto-a-imagen y aplicar el IC-LoRA Cameraman sobre él. El LoRA solo se encarga de la cámara, no de cómo se generó el fotograma.

¿Dónde consigo el workflow de IC-LoRA Cameraman v2 si el del vídeo de YouTube es de pago?

El propio autor del LoRA (Cseti) publica un workflow oficial y gratuito en HuggingFace, en el dataset Cseti/ComfyUI-Workflows, ruta ltx/2.3/ic-lora-cameraman-v2/. No hace falta reconstruir el grafo de un vídeo de Patreon: ese workflow oficial es el que se usó para las pruebas de este artículo.

¿Por qué se me cae ComfyUI sin error al decodificar el vídeo final en workflows de LTX 2.3?

Puede ser un OOM de RAM del sistema, no de VRAM de la GPU. Ocurrió justo al decodificar el VAE final de vídeo+audio, con el sistema en unos 27GB de 31GB de RAM usada, sin ningún traceback. Cerrar aplicaciones que consuman mucha RAM (en este caso, un navegador con muchas pestañas) liberó memoria suficiente para completar la generación sin problema.

¿Qué resolución e image strength recomienda el autor del IC-LoRA Cameraman v2?

Según las notas del propio autor, no bajar de 960x512 en la primera pasada: cuanta más resolución, más fielmente se sigue el movimiento de cámara de referencia. Para el image strength del conditioning, recomienda un valor entre 0.5 y 0.7 si se busca más movimiento transferido. Si el resultado no sigue el movimiento de referencia, sugiere probar con el prompt vacío, cambiar de seed, o describir el movimiento de cámara a alto nivel en el propio prompt.

Conclusión: una técnica que funciona de verdad

Después de tres intentos reales, está claro que IC-LoRA Cameraman v2 funciona de forma consistente. El movimiento de cámara se transfiere independientemente del contenido, tanto con vídeo de referencia sintético como real, tanto con movimiento sutil como marcado. La lección principal es que un movimiento de referencia deliberado y visible da mejores resultados demostrativos.

El workflow gratuito y oficial del autor es una alternativa perfectamente viable a intentar reconstruir workflows de pago de YouTube. Y el bug de RAM del sistema es un recordatorio real de que estos workflows de vídeo+audio conjuntos pueden agotar RAM antes que VRAM.

🏆 Nuestra recomendación

Si buscas transferencia de movimiento de cámara en ComfyUI sin complicarte con pipelines de pago → usa el workflow oficial de Cseti disponible en HuggingFace. Si necesitas composición de múltiples elementos (personaje + fondo) → entonces sí integra Boogu Image 0.1 Edit en el pipeline. Deja bastante RAM libre en el sistema antes de lanzar la decodificación final, no solo VRAM en GPU, y usa vídeos de referencia con movimiento deliberado para mejores resultados visuales.

Sigue leyendo

Si quieres generar tus propios fotogramas iniciales con Krea 2 Turbo como hice en esta prueba, consulta nuestra guía de Krea 2 en ComfyUI. Si te interesa la familia LTX 2.3 y sus workflows reales en RTX 3090, tenemos también la reproducción del workflow LTXV-2.3 + RTX Super Resolution. Y si el bug de RAM del sistema te suena a algo que ya te ha pasado, no es casualidad: documentamos el mismo cuello de botella (RAM, no VRAM) de forma mucho más exhaustiva, con 4 crashes reproducidos y confirmados por el OOM killer del kernel, en este otro artículo sobre el modelo dev de LTXV-2.3 en RTX 3090.