OpenCV: Computer Vision Deep Dive

Hola, soy Alex de DEV STORIES DOT EU. OpenCV: Computer Vision Deep Dive, episodio 1 de 20. La mayoría de los desarrolladores piensan en una imagen como un archivo comprimido guardado en un disco duro. Pero en el momento en que le pasas ese archivo a una librería de computer vision, se deshace de su formato de archivo y se convierte en una enorme cuadrícula de números esperando a que hagas operaciones con matrices. Entender exactamente cómo se estructuran esos números es El Alma de OpenCV: Píxeles como Matrices. Cuando cargas una imagen usando OpenCV, la función read saca el archivo del disco y lo convierte al instante en un array multidimensional de NumPy. Esta es la parte que importa. OpenCV en Python no usa un objeto de imagen propietario. Depende completamente de NumPy. Como una imagen es solo un array estándar, cualquier operación matemática que le puedas aplicar a un array, se la puedes aplicar directamente a tu imagen. Vamos a ver la estructura de este array. Si cargas una imagen en color estándar, obtienes una matriz tridimensional. La primera dimensión es la altura, que representa el número de filas. La segunda dimensión es la anchura, que representa el número de columnas. La tercera dimensión contiene los canales de color. Si tienes una imagen de ochocientos píxeles de ancho y seiscientos píxeles de alto, el shape de tu array será de seiscientas filas, ochocientas columnas y tres canales. Cada intersección de una fila y una columna contiene un píxel. Y para imágenes estándar, cada canal de color dentro de ese píxel contiene un valor entero de cero a doscientos cincuenta y cinco, que representa la intensidad de ese color. Aquí hay una trampa muy común. La mayoría del software de gráficos y navegadores web representan los colores en el formato Red, Green, Blue, conocido como RGB. OpenCV no lo hace. Por razones históricas que se remontan al hardware de las primeras cámaras, OpenCV guarda los canales de color en orden inverso: Blue, Green, Red, o BGR. Si intentas mostrar una imagen de OpenCV en otra librería sin intercambiar esos canales, tus rojos se verán azules y tus azules se verán rojos. No es un bug en tu código. Solo recuerda que el valor en el index cero del canal es azul, el index uno es verde y el index dos es rojo. Como las imágenes son solo arrays de NumPy, manipularlas depende de la sintaxis estándar de Python. No necesitas funciones especializadas de OpenCV para recortar una imagen. Simplemente haces un slice del array. Supón que tienes el feed de una cámara de seguridad en alta definición, y solo te importa una región de cien por cien píxeles donde hay una puerta. Extraes una Region of Interest, o ROI, usando el slicing estándar de arrays. Especificas la fila inicial y la fila final, seguidas de la columna inicial y la columna final. En términos matemáticos, haces el slice del eje Y primero, y luego del eje X. Esto devuelve al instante un array de NumPy más pequeño que contiene solo los datos de los píxeles de la puerta. Una vez que has hecho el slice de tu array o has modificado sus píxeles, normalmente quieres guardar el resultado. OpenCV maneja esto con una simple función write. Proporcionas un file path de destino y le pasas tu array de NumPy. OpenCV lee la extensión de archivo que has pedido, como punto JPG, y maneja automáticamente la compleja compresión necesaria para convertir esa matriz de números de vuelta en un archivo de imagen estándar. Lo más útil que puedes hacer al aprender computer vision es dejar de pensar en las imágenes como lienzos visuales, y empezar a tratarlas como sistemas de coordenadas llenos de datos numéricos raw. Si te gustan estos deep dives, puedes apoyar el programa buscando DevStoriesEU en Patreon. Eso es todo por este episodio. Gracias por escuchar, y ¡sigue construyendo!

Hola, soy Alex de DEV STORIES DOT EU. OpenCV: Computer Vision Deep Dive, episodio 2 de 20. Aplicar un filtro de blur a una foto parece un efecto visual complejo, pero computacionalmente, es simplemente reemplazar cada píxel con la media matemática de sus vecinos inmediatos. El mecanismo detrás de esto es lo que veremos hoy: Convolution Kernels: filtrado y edge detection. Cuando escuchas la palabra convolución, probablemente pienses inmediatamente en Convolutional Neural Networks. Tenemos que separar esos conceptos ahora mismo. En una red de deep learning, un modelo averigua los valores dentro de sus filtros durante un proceso de entrenamiento masivo. Hoy vamos a hablar de la convolución clásica bidimensional. Estos kernels son matrices matemáticas fijas y hardcodeadas que existen desde hace décadas. No aprenden. Solo calculan. Un kernel es simplemente una pequeña cuadrícula de números. Un tamaño muy común es un cuadrado de tres por tres. La convolución es el proceso de coger esta pequeña cuadrícula y deslizarla por toda tu imagen, píxel a píxel. En cada parada, alineas el centro de tu kernel con un píxel específico de la imagen. Luego, multiplicas cada número de tu kernel por el valor del píxel de la imagen que está justo debajo. Sumas esos nueve resultados, y esa suma final se convierte en el nuevo valor único para el píxel central en tu imagen de output. Haces esto para cada píxel. Los números que pones dentro de esa pequeña cuadrícula dictan exactamente qué le pasa a toda la imagen. Si llenas el kernel con fracciones que suman uno, obtienes un blur. Un Gaussian blur es un tipo específico de kernel donde el valor central tiene el mayor peso, y los valores van disminuyendo a medida que te acercas a los bordes de la cuadrícula. Esto crea una media ponderada localizada. Esta es la parte que importa. No aplicamos blur a las imágenes para que queden artísticas. Les aplicamos blur para destruir el ruido. El sensor de una cámara registra pequeñas fluctuaciones aleatorias de luz. Si intentas analizar la estructura rígida de una imagen con esa estática presente, tus algoritmos van a fallar. El Gaussian blur suaviza el ruido errático mientras preserva las formas generales. Una vez que el ruido ha desaparecido, normalmente quieres encontrar los objetos reales en el frame. Imagina un sistema de cámaras diseñado para leer matrículas. Antes de poder leer los caracteres, tienes que aislar la matrícula rectangular del parachoques del coche. Para un ordenador, un borde es simplemente una transición repentina de píxeles oscuros a píxeles claros, o viceversa. Para encontrar estas transiciones bruscas, cambiamos la matriz de blur por una matriz de edge detection, como el kernel de Sobel. Un kernel de Sobel vertical está diseñado específicamente para encontrar bordes verticales. Es una cuadrícula de tres por tres que contiene una columna de números negativos a la izquierda, una columna de ceros en el medio y una columna de números positivos a la derecha. A medida que este kernel se desliza por un área de color sólido, como un parachoques gris liso, los números negativos y positivos se multiplican por el mismo valor de gris. Se cancelan entre sí. La suma es cero, lo que se traduce en un píxel negro en la imagen de output. Las áreas sólidas desaparecen. Pero cuando el kernel cae justo en el límite vertical entre ese parachoques oscuro y una matrícula blanca brillante, las matemáticas cambian. Los números negativos se multiplican por los píxeles oscuros, produciendo un valor pequeño. Los números positivos se multiplican por los píxeles blancos brillantes, produciendo un valor enorme. Ya no se cancelan. La suma final es un número positivo muy alto, lo que crea un píxel blanco brillante en tu imagen de output exactamente donde está el borde. Al ejecutar esta operación por toda la imagen, el parachoques se desvanece en la oscuridad, dejando atrás un contorno blanco muy marcado de la matrícula. Acabas de convertir datos de color raw en geometría estructural. La conclusión principal es que un kernel de convolución clásico no es más que una regla matemática local aplicada globalmente, que dicta cómo cada píxel debería reaccionar a sus vecinos inmediatos. Gracias por pasar unos minutos conmigo. Hasta la próxima, cuídate.

Hola, soy Alex de DEV STORIES DOT EU. OpenCV: Visión Artificial a fondo, episodio 3 de 20. Necesitas el contorno exacto de un objeto en una cinta transportadora. Tu primer instinto podría ser cargar una enorme red neuronal de segmentación semántica. Pero calcular ese contorno usando geometría estándar es órdenes de magnitud más rápido, computacionalmente más barato y no requiere una GPU. Eso es precisamente lo que te permite hacer Drawing Boundaries: Contours and Geometry. Un error común es tratar los bordes y los contornos como si fueran lo mismo. Son estructuras de datos fundamentalmente diferentes. Un detector de bordes te da un mapa binario de píxeles blancos desorganizados y desconectados donde cambia la intensidad. Un contorno es una curva matemática continua que une todos los puntos consecutivos a lo largo de un borde con el mismo color o intensidad. Los bordes son solo puntos aislados en una pantalla. Los contornos forman figuras cerradas y medibles. Imagina un sistema de control de calidad en una fábrica inspeccionando un engranaje metálico. Ya has convertido el feed de la cámara a una imagen binaria en blanco y negro. El engranaje es blanco sólido sobre un fondo negro. Para obtener el borde matemático de ese engranaje, le pasas esta imagen a la función para encontrar contornos. OpenCV lo hace escaneando la imagen fila por fila. Cuando el algoritmo encuentra un límite entre píxeles blancos y negros, traza ese borde, guardando las coordenadas en un array. Para ahorrar memoria, comprime el output, guardando solo los puntos de inicio y fin de los segmentos rectos en lugar de cada píxel individual. Este proceso también captura las relaciones espaciales. El engranaje tiene un borde exterior, pero también tiene un agujero en el centro para el eje. El algoritmo de contornos crea una jerarquía. Registra el borde exterior como un contorno padre, y el agujero interior como un contorno hijo. Esto te permite analizar selectivamente o ignorar las formas internas según tus necesidades. Ahora que tienes el engranaje como un borde conectado, puedes extraer su geometría. Puedes calcular el área del contorno. Este es un cálculo matemático del área total de píxeles dentro de la curva cerrada. Un engranaje fabricado a la perfección tendrá un área específica y conocida. Si un engranaje tiene un diente roto, el área de su contorno cae por debajo de tu umbral aceptable. Marcas el defecto al instante. A veces necesitas entender la forma general de un objeto ignorando sus detalles más intrincados. Aquí es donde la cosa se pone interesante. Puedes calcular el convex hull de un contorno. Imagina el convex hull como una goma elástica bien tensada alrededor del exterior de tu objeto. Para el engranaje, el contorno estándar traza a la perfección cada diente y valle. El convex hull ignora los valles. Se estira en línea recta desde la punta de un diente hasta la punta del siguiente. Al comparar el contorno original con el convex hull, identificas anomalías estructurales. Los espacios vacíos entre la goma elástica y el contorno real del engranaje se llaman convexity defects. Medir estos defectos te dice exactamente la profundidad de los dientes del engranaje y si alguno está desgastado, todo mediante puro cálculo geométrico. Los contornos cierran la brecha entre el procesamiento de imágenes de bajo nivel y el análisis de objetos de alto nivel, convirtiendo una cuadrícula de píxeles tontos en formas geométricas estructuradas que puedes validar estrictamente. Eso es todo por este episodio. ¡Gracias por escuchar, y sigue creando!

Hola, soy Alex de DEV STORIES DOT EU. OpenCV: Computer Vision Deep Dive, episodio 4 de 20. Los visual trackers más robustos no memorizan el aspecto completo de un objeto. En cambio, se fijan en esquinas matemáticamente distintas y gradientes de alto contraste que se mantienen constantes independientemente de la iluminación. Lograr esto correctamente es el dominio de los Feature Detectors: Keypoints y Neural Matching. Antes de ver cómo funciona, tenemos que separar esto del object detection. El object detection aplica categorías semánticas amplias. Dibuja un bounding box y te dice que hay un edificio en el frame. El feature matching es estrictamente estructural. No sabe lo que es un edificio. Encuentra una intersección específica e idéntica de dos ladrillos en dos imágenes diferentes. Piensa en crear una aplicación de panorama stitching. Tienes dos fotos superpuestas de una pared de ladrillos, tomadas desde ángulos ligeramente diferentes. Para unirlas a la perfección, el software necesita alinear matemáticamente el solapamiento. Esto lo hace encontrando features locales distintivas en la primera imagen, buscando esas mismas features en la segunda imagen, y emparejándolas. El primer paso es la detección. El sistema escanea la imagen en busca de keypoints. Un keypoint es una ubicación específica de píxeles que destaca de su entorno. Las áreas planas, como un cielo despejado o una pared blanca lisa, son inútiles porque todos los píxeles se ven exactamente iguales. El algoritmo busca texturas pronunciadas, esquinas definidas y líneas que se cruzan. Tradicionalmente, los algoritmos se basaban en fórmulas matemáticas creadas a mano para encontrar estos bordes. Los enfoques modernos utilizan redes neuronales convolucionales. Le pasas la imagen a la red, y esta devuelve un mapa de probabilidad que indica cómo de probable es que un píxel dado sea un keypoint estable. Una vez que la red identifica un punto, como la esquina del marco de una ventana en concreto, necesita una forma de describirlo. Este es el descriptor. La red neuronal genera un vector de alta dimensión, un embedding, que captura el patrón visual de los píxeles que rodean inmediatamente a ese keypoint. Un descriptor robusto se mantiene matemáticamente similar incluso si la segunda foto se toma a una escala diferente, se rota o bajo condiciones de iluminación distintas. Aquí está la clave. Tener una lista de puntos y sus descripciones es solo la mitad del puzzle. Todavía tienes que hacer match entre los puntos de tu primera imagen y los puntos de tu segunda imagen. Históricamente, simplemente calculabas la distancia entre los vectores y elegías el más cercano. Pero los patrones repetidos, como cientos de ladrillos idénticos en una pared, provocan errores de mismatching graves. Aquí es donde entran en juego los modelos de neural matching. En lugar de evaluar un keypoint de forma aislada, un neural matcher analiza las relaciones espaciales entre todos los keypoints a la vez. Básicamente, aprende que una esquina en concreto puede parecerse a otras cincuenta esquinas de ladrillo, pero es la única ubicada exactamente entre el marco de una ventana y una sombra específica. Al pasar los descriptores y sus posiciones geométricas a través de capas de self-attention, el sistema rechaza los falsos positivos y devuelve pares de matching de alta precisión. En un pipeline típico, primero pasas ambas imágenes por una red de feature extraction. Esto devuelve dos conjuntos de keypoints y dos conjuntos de descriptores. Después, pasas ambos conjuntos de datos a una matching network. La matching network calcula las similitudes contextuales y devuelve una lista de pares válidos, descartando los keypoints que no existen en ambos frames. Luego usas esos pares de coordenadas que han hecho match para calcular la transformación geométrica necesaria para hacer el warp y el stitch de las dos fotos a la perfección. El cambio de fórmulas creadas a mano a neural embeddings significa que el feature matching ahora puede manejar variaciones extremas de iluminación y puntos de vista extremos que antes rompían por completo los algoritmos más antiguos. ¡Gracias por escuchar, happy coding a todos!

Hola, soy Alex de DEV STORIES DOT EU. OpenCV: Computer Vision Deep Dive, episodio 5 de 20. Las apps móviles de escaneo de documentos parecen magia compleja de AI. Apuntas con el móvil a un papel y, al instante, se aplana para convertirse en un documento digital perfecto. Pero el motor principal detrás de esto no es una neural network prediciendo detalles que faltan. Se basa en un truco matemático de hace quince años que utiliza una transformation matrix de tres por tres. Este episodio trata sobre Real-World Geometry: Building a Document Scanner. Piensa en un ticket arrugado sobre la mesa de un restaurante. Haces una foto desde un ángulo inclinado. Por la perspectiva, el ticket parece un trapecio deformado, rodeado por la textura de la mesa. Para extraer el documento, el primer paso es aislarlo del fondo. Conviertes la imagen a grayscale y aplicas un ligero blur. Esto suaviza los detalles con ruido, como las arrugas del papel o las vetas de la madera de la mesa, manteniendo intactos los boundaries principales. Luego, ejecutas Canny edge detection. Esto resalta los cambios bruscos de intensidad, dejándote con un contorno brillante del ticket sobre un fondo oscuro. A continuación, necesitas convertir esos edges sueltos en una forma definida. Buscas los contours en el edge map. La imagen contendrá muchos contours, y la mayoría son pequeños artefactos inútiles. Los ordenas por área, quedándote solo con los más grandes. Luego, iteras sobre estos contours grandes y aproximas su forma poligonal. Buscas una pista estructural específica. Si encuentras una forma que se pueda aproximar con exactamente cuatro puntos, has encontrado el boundary de tu ticket. Esos cuatro puntos definen las esquinas de tu documento en la foto original inclinada. Ahora llegamos al paso crítico de aplanar el documento. Un error común es pensar que este proceso utiliza AI para adivinar o alucinar datos que faltan. No es así. Un perspective transform es un warping matemático puro de las coordenadas de los píxeles de un plano a otro. Para ejecutar esto, necesitas dos sets de cuatro puntos. El primer set son las cuatro esquinas que acabas de encontrar en el ticket. El segundo set representa dónde deberían estar esas esquinas en la imagen final perfecta. Para obtener el segundo set, calculas el width y el height máximos del ticket deformado usando la fórmula de distancia entre los puntos originales. Luego defines un nuevo rectángulo perfecto que empieza en la coordenada cero-cero, y se extiende hasta ese width y height exactos. Con estos dos sets de puntos, calculas una perspective transformation matrix. Esta matriz define exactamente cuánto necesita desplazarse, estirarse o comprimirse cada píxel para pasar de la forma de trapecio inclinado a la forma de rectángulo plano. Finalmente, aplicas esta matriz a la imagen original en alta resolución. Las matemáticas literalmente tiran de las cuatro esquinas hacia afuera y las cuadran, haciendo un warping de todos los píxeles interiores junto con ellas. El resultado es una imagen bidimensional perfecta de tu ticket, vista desde arriba, lista para ser procesada. Aquí está la clave. No necesitas deep learning para corregir la perspectiva. Siempre y cuando puedas aislar cuatro esquinas, una simple operación de matrices hará un remap perfecto de la geometría de cualquier superficie plana. Gracias por pasarte por aquí. Espero que hayas aprendido algo nuevo.

Hola, soy Alex de DEV STORIES DOT EU. OpenCV: Deep Dive en Computer Vision, episodio 6 de 20. Para cuando un nuevo algoritmo de tracking se convierte en una función estándar en la librería principal de OpenCV, a menudo ha pasado años siendo testeado a fondo por investigadores en un espacio separado y paralelo. Si te limitas solo a las releases por defecto, te estás perdiendo las técnicas más novedosas del sector. Ese espacio paralelo es el repositorio opencv_contrib. Muchos desarrolladores ven la palabra contrib y asumen que el código está roto, sin testear o que es estrictamente software en beta. Eso es un malentendido. El código de este repositorio suele estar altamente optimizado y se utiliza activamente en entornos exigentes. La diferencia radica totalmente en la estabilidad de la API, no en la calidad del código. La librería core de OpenCV impone garantías estrictas de retrocompatibilidad a largo plazo. Si una función entra en la release principal, sus inputs, outputs y comportamiento deben mantenerse estables durante años. Pero la investigación en Computer Vision avanza a un ritmo vertiginoso. Los investigadores necesitan un lugar donde publicar nuevos algoritmos, renombrar parámetros y modificar estructuras de datos basándose en el feedback del mundo real. El repositorio opencv_contrib proporciona exactamente ese entorno. Actúa como una incubadora. Los maintainers de estos módulos extra tienen permitido romper la API entre releases. Pueden renombrar funciones o cambiar cómo se inicializa un algoritmo sin saltarse las reglas estrictas de la librería core. Con el tiempo, un módulo puede demostrar ser universalmente útil. Su API se estabiliza, se pulen los edge cases y la comunidad empieza a depender mucho de él. Cuando eso pasa, los maintainers de OpenCV migran el código. Mueven físicamente el módulo fuera del repositorio opencv_contrib y lo mergean directamente en el repositorio principal de OpenCV. Este proceso de graduación asegura que la librería core solo absorba tecnología probada y estable. Imagina un escenario concreto. Estás montando un proyecto de realidad aumentada y quieres usar el módulo de tracking ArUco para detectar marcadores fiduciales cuadrados en un feed de cámara en directo. Este módulo contiene funciones altamente especializadas y de última generación. Para usarlo, compilas tu entorno OpenCV desde el código fuente. Clonas el repositorio principal en tu máquina local y, luego, clonas el repositorio opencv_contrib justo al lado. Cuando configuras tu build tool, le pasas una variable de path específica que apunta a la carpeta de módulos dentro del repositorio contrib. El build system lee esta flag y compila la librería core, pero también se va a la carpeta contrib, compila el módulo ArUco y lo linka directamente en tus binarios finales. No acabas teniendo dos librerías separadas. Consigues una única instalación unificada de OpenCV que incluye tanto la base sólida como los módulos experimentales que hayas elegido. Si te gusta el podcast y quieres apoyar el programa, puedes buscar DevStoriesEU en Patreon; siempre se agradece. El verdadero poder de esta arquitectura reside en entender su doble naturaleza: el repositorio principal protege tus pipelines de producción de los breaking changes, mientras que el repositorio contrib te pone en las manos hoy mismo la investigación en Computer Vision del mañana. Eso es todo por este episodio. ¡Nos vemos en el próximo!

Hola, soy Alex de DEV STORIES DOT EU. OpenCV: Computer Vision Deep Dive, episodio 7 de 20. Puedes arrancarle el cerebro a un enorme servidor de training de PyTorch, exportarlo como un único archivo y ejecutarlo rapidísimo en C++ puro sin instalar PyTorch para nada. Cuando pasas de entrenar un modelo a hacer su deploy en el mundo real, tus requisitos cambian de flexibilidad a velocidad pura. Aquí es exactamente donde entra en juego el Inference Engine, el módulo DNN de OpenCV. Una trampa común en la que caen los ingenieros es asumir que si un modelo se entrenó con TensorFlow, la máquina donde se haga el deploy también debe tener una instalación pesada de TensorFlow para ejecutarlo. Esto es falso. OpenCV ejecuta la inferencia de forma totalmente nativa. El módulo DNN es un inference engine dedicado y altamente optimizado para el forward-pass. No hace backpropagation. No calcula gradientes. No entrena modelos. Su único trabajo es coger una red preentrenada, ingerir una imagen y darte una respuesta tan rápido como el hardware lo permita. OpenCV ofrece loaders nativos para los formatos de modelo estándar. Puedes cargar modelos de Caffe, protocol buffers de TensorFlow, configuraciones de Darknet y archivos ONNX directamente en tu aplicación. Aquí está la clave. Cuando llamas a una función como readNet, OpenCV parsea el formato del archivo externo y reconstruye el grafo de la red neuronal usando sus propias implementaciones internas de capas en C++. Las dependencias externas se eliminan por completo. Tu aplicación solo enlaza con OpenCV. Imagina una cámara inteligente embedded en C++ diseñada para detectar peatones en la calle. No quieres un runtime de Python masivo consumiendo tu memoria limitada, y desde luego no quieres gigabytes de librerías de deep learning ocupando espacio de almacenamiento en un edge device. En su lugar, entrenas tu detector de peatones en un clúster de GPUs potente y exportas los pesos finales a un archivo ONNX. Y simplemente metes ese único archivo en el almacenamiento de tu cámara. En tu aplicación en C++, usas el módulo DNN para cargar el archivo ONNX. A continuación, capturas un frame del sensor de la cámara. Las redes neuronales no pueden procesar imágenes raw directamente. Tienes que convertir ese frame en un array estructurado de cuatro dimensiones, comúnmente llamado blob. OpenCV proporciona una función dedicada para construir este blob, que se encarga de redimensionar la imagen, intercambiar los canales de color y aplicar la resta de la media o el escalado específico que requiera el modelo original. Le pasas este blob preparado a la input layer de la red. Luego, llamas a la función forward. El módulo DNN toma el control, empujando los datos a través de cada capa convolucional, función de activación y pooling layer. Como OpenCV es dueño de todo el execution graph en este punto, puede optimizar las matemáticas de forma agresiva. Fusiona capas adyacentes donde es posible para reducir el ancho de banda de memoria y utiliza automáticamente la aceleración de hardware nativa. La función forward termina y devuelve un array final que contiene las coordenadas del bounding box y los confidence scores de los peatones que ha encontrado. Mantén tus frameworks pesados en el laboratorio para el training, y usa el módulo DNN de OpenCV para un deploy ligero y sin dependencias en producción. Gracias por escuchar. Espero que hayas aprendido algo nuevo.

Hola, soy Alex de DEV STORIES DOT EU. OpenCV: Computer Vision Deep Dive, episodio 8 de 20. Antes de que llegaran los sistemas modernos, los detectores de objetos tenían que escanear una sola imagen docenas de veces a diferentes escalas solo para encontrar un objetivo. Era horriblemente lento y muy pesado a nivel computacional. Entonces, una nueva arquitectura revolucionó el sector al hacer todo el trabajo en una pasada matemática increíblemente rápida. Hoy veremos el linaje de YOLO: Fast Object Detection. Para entender por qué You Only Look Once, o YOLO, lo cambió todo, fíjate en el estándar anterior. Los antiguos pipelines multi-stage se basaban en region proposals. Generaban cientos de suposiciones sobre dónde podría estar un objeto, hacían un crop de esas áreas y luego ejecutaban un image classifier sobre cada patch aislado. Estabas ejecutando redes complejas en un loop. Era algo desconectado, difícil de optimizar y, en el fondo, lento. Algunos desarrolladores confunden YOLO con la image classification estándar, que simplemente asigna una label a una imagen completa. YOLO hace mucho más. Devuelve bounding boxes espaciales precisos junto con class probabilities. Te dice qué es el objeto y exactamente dónde está en el espacio físico. YOLO logró esto replanteando por completo el object detection. En lugar de un pipeline multi-stage, convirtió la detección en un único problema de regresión. La lógica va directamente desde los píxeles raw de la imagen hasta las coordenadas del bounding box y las class probabilities en un solo paso continuo. Aquí está la clave. YOLO coge la imagen de input y la divide en un grid uniforme. Si el centro de un objeto cae dentro de una celda específica del grid, esa celda exacta pasa a ser la responsable de detectar el objeto. Cada celda del grid predice simultáneamente un número fijo de bounding boxes. Para cada box, devuelve las coordenadas del centro, el width y el height. También devuelve un confidence score, que le dice al sistema lo seguro que está de que el box realmente contiene un objeto. Simultáneamente, la celda predice las class probabilities. Está calculando si el objeto es un coche, un camión o una persona. Luego, la red multiplica el confidence del box por la class probability. Esta única operación matemática filtra todas las suposiciones débiles en todo el grid, dejando solo los bounding boxes de alta precisión. Imagina una cámara de peaje en una autopista de alta velocidad. Los coches se mueven a 130 km/h. Necesitas una red single-pass para dibujar bounding boxes alrededor de las matrículas antes de que el coche salga del frame. Un detector multi-stage tendría lag, haciendo crop y analizando patches aislados de asfalto mientras el coche se aleja a toda velocidad. YOLO procesa todo el frame de una sola vez. Aplica el grid, predice la geometría y calcula las probabilidades en un único forward pass de la red neuronal. Como YOLO procesa toda la imagen en una sola pasada, entiende de forma inherente el contexto global de la escena. Los modelos más antiguos a menudo confundían patches de background con objetos porque solo veían crops aislados. Al plantear la detección como un único problema de regresión sobre un grid, YOLO obliga a la red a aprender representaciones generalizadas de los objetos en todo su contexto. Gracias por pasar unos minutos conmigo. Hasta la próxima, cuídate.

Hola, soy Alex de DEV STORIES DOT EU. OpenCV: Deep Dive en Computer Vision, episodio 9 de 20. Durante una década, el mayor cuello de botella en la detección de objetos en tiempo real no era la red neuronal en sí. Era el algoritmo pesado y programado a mano que se usaba para limpiar sus predicciones desordenadas y superpuestas. La solución a esto es YOLOv26, concretamente su arquitectura de detección end-to-end NMS-free. Para entender este cambio, tienes que ver cómo los detectores tradicionales terminan su trabajo. Se basan en Non-Maximum Suppression, o NMS. El NMS es un paso de post-processing lento. Cuando un modelo estándar analiza un objeto, no predice solo un bounding box. Predice docenas de bounding boxes superpuestos alrededor del mismo objeto. El NMS interviene para puntuar estos boxes, calcular su solapamiento, eliminar los duplicados y dejar solo el que mejor encaja. Este proceso de limpieza es inherentemente secuencial y casi siempre se ejecuta en la CPU. Imagínate hacer deploy de un modelo de visión en una NVIDIA Jetson Orin para un robot de clasificación de almacén. Necesitas detectar cientos de paquetes que se mueven rápido a 60 frames por segundo. La GPU vuela a través de las layers de la red neuronal. Luego, el pipeline se atasca. La CPU se ahoga intentando ejecutar NMS sobre miles de coordenadas raw de boxes superpuestos. Tu frame rate se desploma por culpa de la limpieza, no de la inferencia. YOLOv26 elimina este cuello de botella por completo al proporcionar una inferencia NMS-free nativa. Le pasas una imagen a la red, y la red devuelve exactamente un box por objeto. El script de post-processing desaparece. Para hacer esto posible, la arquitectura de YOLOv26 elimina un componente llamado Distribution Focal Loss, o DFL. En iteraciones anteriores, el DFL se usaba para modelar los bordes de un bounding box como una distribución estadística continua. Ayudaba al modelo a adivinar dónde podían estar los bordes borrosos u ocultos, pero naturalmente animaba a la red a devolver múltiples predicciones superpuestas. Eliminar el DFL cambia fundamentalmente el comportamiento de la red. Sin él, el modelo es fuertemente penalizado durante el training por predecir más de un box por objeto. Obliga a la red a ser absolutamente decisiva. Sin embargo, eliminar el DFL crea un nuevo problema. Obligar a la red a devolver exactamente un hard boundary hace que el proceso de training sea muy inestable. El loss landscape se vuelve abrupto y caótico. Para solucionar esto, YOLOv26 integra el optimizador MuSGD en su training pipeline. MuSGD estabiliza el proceso de aprendizaje ajustando dinámicamente el momentum en función de la varianza de los gradientes. Cuando el training llega a una parte abrupta y caótica del loss landscape, MuSGD amortigua los weight updates para que el modelo no descarrile. Cuando la trayectoria del gradiente es estable, se acelera. Este optimizador específico es lo que permite que la arquitectura converja en una única predicción estricta sin colapsar. El resultado en el deployment es brutal. Cuando exportas un modelo YOLOv26 a TensorRT para ese robot de almacén, todo el pipeline se queda en la GPU. La red procesa el frame y devuelve directamente las coordenadas finales del paquete. La CPU queda completamente libre para otras tareas de control robótico. Aquí está la clave. El código más rápido es el código que nunca se ejecuta. Al trasladar la carga de la deduplicación de un script de post-processing en runtime a la fase de optimización del training, YOLOv26 desbloquea una eficiencia de hardware que antes era imposible. Eso es todo por este episodio. ¡Gracias por escuchar, y seguid construyendo!

Hola, soy Alex de DEV STORIES DOT EU. OpenCV: Computer Vision Deep Dive, episodio 10 de 20. Los detectores de objetos tradicionales sufren de una forma severa de visión de túnel. Pueden trackear perfectamente coches, personas y bicicletas, pero si les pides que encuentren una taza de café derramada, se quedan completamente ciegos, limitados a las pocas clases con las que fueron entrenados explícitamente en el laboratorio. Para solucionar esto, no necesitas etiquetar miles de tazas derramadas. Necesitas YOLO-World y Open-Vocabulary Zero-Shot Detection. Imagina un escenario específico. Gestionas un sistema de seguridad de una tienda. Necesitas buscar en los feeds de vídeo en directo una botella hydroflask azul o un golden retriever perdido. Con un detector estándar de vocabulario fijo, tendrías que detener el sistema, recopilar imágenes de golden retrievers en tu tienda, dibujar manualmente bounding boxes alrededor de ellos, reentrenar el modelo y hacer un redeploy. Con YOLO-World, simplemente escribes el text prompt en el sistema. Encuentra el objeto al instante, zero-shot. Este no es un modelo generativo text-to-image. No crea imágenes. También es muy diferente de simplemente añadir una nueva clase a un dataset existente. La Open-vocabulary detection se basa en una profunda comprensión semántica del lenguaje. Mapea directamente los text prompts lingüísticos a bounding boxes visuales. El sistema recibe dos inputs: una imagen y un conjunto de text prompts. Utiliza un vision backbone para extraer features visuales de la imagen. Simultáneamente, utiliza un text encoder para traducir tus text prompts en vectores matemáticos, llamados embeddings. Aquí es donde la cosa se pone interesante. Estos dos streams de datos distintos deben combinarse. YOLO-World gestiona esto mediante una estructura llamada RepVL-PAN. Que significa Reparameterizable Vision-Language Path Aggregation Network. El acrónimo es denso, pero su función es sencilla. RepVL-PAN fusiona las features de la imagen y del texto. Inyecta el significado semántico de tu text prompt directamente en el feature map visual a múltiples escalas. A medida que la red procesa los píxeles, es guiada activamente por el text embedding. El modelo aprende a hacer esto durante su fase de entrenamiento inicial mediante un mecanismo llamado region-text contrastive loss. El modelo genera bounding boxes y extrae features visuales de esas regiones. Luego, compara esas features visuales con los text embeddings. La contrastive loss penaliza severamente al modelo si las features visuales de una box no coinciden con el text embedding correcto. Y recompensa al modelo cuando coinciden. Esto obliga a la red a alinear su representación visual con precisión con conceptos lingüísticos a través de datasets masivos de pares imagen-texto. Aprende qué significan azul, hydroflask y botella como conceptos generales, en lugar de memorizar una única categoría rígida. Cuando ejecutas el modelo en producción, el workflow es increíblemente limpio. Primero, defines una lista de vocabulario personalizada que contiene tus objetos objetivo. Pasas esa lista por el text encoder una vez para generar tus text embeddings. Luego, introduces tus frames de vídeo en directo en el vision backbone. La arquitectura RepVL-PAN fusiona los datos visuales entrantes con tus text embeddings precalculados. Finalmente, el modelo devuelve bounding boxes y confidence scores basados en la similitud entre las regiones visuales y tus palabras. El verdadero poder de YOLO-World es desacoplar el detector de un dataset rígido, permitiéndote usar el lenguaje natural como una query ejecutable en tiempo real para el mundo físico. Gracias por escuchar. ¡Hasta la próxima!

Hola, soy Alex de DEV STORIES DOT EU. OpenCV: Computer Vision Deep Dive, episodio 11 de 20. Para una IA moderna, tu identidad no se define por la forma de tu nariz ni por la distancia entre tus ojos. En cambio, tu identidad se define por tu posición exacta en un espacio geométrico de 128 dimensiones. Classic to Deep: Facial Recognition Evolution explica cómo llegamos a este modelo. Primero, necesitamos diferenciar dos conceptos que a menudo se confunden. El face detection consiste en encontrar dónde está una cara en una imagen. Dibuja un bounding box alrededor de los píxeles que parecen una cabeza humana. El face recognition consiste en identificar de quién es la cara que está dentro de ese bounding box. Este episodio se centra estrictamente en el recognition. Durante décadas, el enfoque estándar fue estadístico. Si construiste un sistema a principios de los dos mil, probablemente usaste una técnica llamada Eigenfaces. Eigenfaces se basa en un algoritmo llamado Principal Component Analysis, o PCA. Empiezas con un dataset de imágenes de caras y haces un flatten de cada imagen para convertirla en un array unidimensional enorme de intensidades de píxeles raw. Luego, el PCA analiza todo este dataset para encontrar las direcciones de máxima varianza. Encuentra los patrones matemáticos subyacentes que diferencian una cara de otra. Cuando visualizas estos principal components, parecen caras fantasmales y borrosas. Para reconocer a una persona nueva usando Eigenfaces, el sistema proyecta la nueva imagen raw en este subespacio de principal components y calcula la distancia hasta las caras conocidas de la base de datos. Esto funciona en entornos muy controlados, pero falla en el mundo real. Una sombra en una mejilla o una ligera inclinación de la cabeza alteran por completo los valores raw de los píxeles. El algoritmo ve un patrón de luz diferente y no logra reconocerte. Aquí está la clave. El Deep Learning descartó por completo la idea de comparar la varianza de los píxeles raw. Los sistemas modernos utilizan Convolutional Neural Networks para generar embeddings. Un embedding es un vector denso de números que representa las features de alto nivel de una cara. Estas redes se entrenan con millones de imágenes utilizando penalizaciones matemáticas avanzadas, como el ArcFace loss. Durante el entrenamiento, la red se ve obligada a acercar los vectores de embedding de una misma persona en el espacio geométrico, mientras aleja los vectores de personas diferentes. Imagínate una cerradura de seguridad en la puerta de una oficina equipada con una cámara. Cuando un visitante se acerca, el sistema detecta y recorta la cara, y luego pasa esa imagen recortada por la red neuronal. La red devuelve un único array de 128 números en floating-point. Ese es el vector de embedding. Luego, el sistema calcula la simple distancia euclidiana entre ese vector del visitante y una base de datos de vectores de empleados autorizados. No compara píxeles ni iluminación. Simplemente mide la distancia en línea recta entre dos puntos en un espacio de 128 dimensiones. Si la distancia a un vector de empleado está por debajo de un threshold predefinido, la puerta se abre. El sistema es robusto porque la red aprendió a ignorar sombras, gafas y ligeras rotaciones de cabeza durante el entrenamiento. La evolución de Eigenfaces a deep embeddings es el salto de analizar cómo incide la luz en una cara a mapear la identidad conceptual de una persona en un sistema de coordenadas medible. Si quieres ayudar a que el café siga fluyendo y apoyar el programa, puedes buscar DevStoriesEU en Patreon. Eso es todo por este episodio. ¡Gracias por escuchar, y keep building!

Hola, soy Alex de DEV STORIES DOT EU. OpenCV: Computer Vision Deep Dive, episodio 12 de 20. Ejecutar una red neuronal pesada en cada frame de un vídeo de alta resolución es un desperdicio computacional. Los sistemas inteligentes detectan un objeto una sola vez, y luego usan ecuaciones físicas ultrarrápidas para predecir dónde se moverá después. Este es el dominio de la percepción persistente: los algoritmos de Object Tracking. Imagina un sistema de monitorización de tráfico en una smart city. Tienes que contar los vehículos únicos que pasan por un cruce concurrido. Un modelo de object detection analiza un único instante congelado en el tiempo. Si ejecutas detección pura en un vídeo a treinta frames por segundo, un coche parado en un semáforo en rojo durante diez segundos genera trescientas bounding boxes separadas y desconectadas. Sin lógica de tracking, tu sistema cuenta trescientos coches. La detección encuentra el objeto. El tracking asocia matemáticamente ese objeto con su yo del pasado a lo largo del tiempo. Para arreglar la cámara de tráfico, necesitas un multi-object tracker para mantener un ID persistente para cada vehículo. Los trackers modernos, como los implementados usando Roboflow y OpenCV, dividen este problema en dos fases matemáticas distintas. La primera fase es la predicción, y la segunda fase es la asociación. Cuando un coche entra en el feed de la cámara, el detector inicial dibuja una bounding box. El tracker extrae las coordenadas del centro, el ancho y el alto de esa box, y le asigna un número entero único, como el ID 42. Cuando llega el siguiente frame de vídeo, el tracker no escanea la imagen inmediatamente. En su lugar, usa un modelo matemático, normalmente un Filtro de Kalman, para hacer state estimation. Al evaluar cómo se movió el ID 42 en los frames anteriores, el filtro calcula la velocidad del vehículo. Luego proyecta esas propiedades físicas hacia adelante para predecir exactamente dónde debería estar la bounding box del ID 42 en el nuevo frame. Ahora tienes dos conjuntos de datos para el frame actual. Tienes las boxes predichas generadas por el estimador de estado, y las boxes reales que acaba de encontrar el detector. Aquí está la clave. El tracker debe reconciliar estos dos conjuntos para mantener los IDs consistentes sin volver a analizar los píxeles reales. Construye una matriz comparando cada box predicha con cada box recién detectada. La métrica principal usada para esta comparación es Intersection over Union, o IoU. Esto mide cuánto se superpone el área geométrica predicha con el área geométrica detectada. Si la ubicación predicha para el ID 42 se superpone mucho con una bounding box recién detectada, el sistema concluye que son el mismo vehículo. Un método de optimización, normalmente el algoritmo húngaro, resuelve esta matriz para encontrar los emparejamientos uno a uno más lógicos en todo el cruce. La nueva detección hereda el ID 42, y el tracker actualiza su modelo de velocidad con las nuevas coordenadas confirmadas. Este loop de predicción y asociación maneja inherentemente las obstrucciones visuales temporales. Si un autobús bloquea la vista de nuestro coche durante unos frames, el detector no logra encontrarlo. Sin embargo, el estimador de estado sigue prediciendo el movimiento del coche detrás del autobús basándose en su última trayectoria conocida. El ID se mantiene vivo en un estado pendiente. Cuando el coche emerge y el detector marca una bounding box que se alinea con la predicción a ciegas en curso del tracker, el ID se vuelve a vincular al instante. Al cerrar la brecha entre frames independientes, el multi-object tracking transforma un stream de imágenes estáticas en un mapa cohesivo de entidades en movimiento. El tracking permite que tu aplicación deje de preguntarse qué hay en el frame, y empiece a entender cómo se comportan las cosas a lo largo del tiempo. Eso es todo por este episodio. ¡Gracias por escuchar, y sigue construyendo!

Hola, soy Alex de DEV STORIES DOT EU. OpenCV: Deep Dive en Computer Vision, episodio 13 de 20. Llevamos años entrenando IA para dibujar bounding boxes alrededor de objetos, pero las cajas son toscas y están llenas de ruido de fondo. El objetivo real es pedirle a un sistema en lenguaje natural que pinte una silueta pixel-perfect alrededor de los contornos exactos de un objeto, incluso si nunca se ha entrenado explícitamente con ese objeto antes. Esto nos lleva a los Vision-Language Models para segmentación. Los modelos tradicionales de segmentación de imágenes son rígidos. Mapean píxeles a una lista fija y cerrada de categorías como coche, persona o árbol. Si quieres segmentar algo fuera de esa lista, tienes que recopilar un dataset enorme y entrenar un modelo completamente nuevo. Los Vision-Language Models, o VLMs, rompen esta limitación fusionando large language models con encoders visuales para hacer segmentación open-world. Le pasas una imagen y un string de texto arbitrario, y el modelo te devuelve una máscara densa a nivel de píxel de lo que hayas descrito. Imagina un dron agrícola automatizado sobrevolando un viñedo. Un agricultor no quiere bounding boxes genéricas alrededor de las plantas. Necesita un mapa preciso de la infección. Le hace un prompt al dron con el string de texto hojas de vid enfermas. El VLM procesa el feed visual y el prompt de texto a la vez. Entiende el significado semántico de enfermas y hojas de vid por su entrenamiento de lenguaje, alinea ese significado con las features visuales de la imagen, y devuelve una máscara. Esta máscara aísla solo el follaje infectado hasta el píxel exacto, ignorando por completo las hojas sanas, la tierra y las sombras. Esto nos lleva a cómo el modelo ejecuta realmente esta lógica. El enfoque baseline es el text prompting de zero-prediction, a menudo llamado zero-shot. En este modo, el modelo depende completamente del enorme dataset con el que se entrenó originalmente. El prompt de texto pasa por un text encoder, convirtiéndose en una representación matemática de tu petición. Simultáneamente, la imagen pasa por un vision encoder, dividiendo la foto en un grid de features visuales. Luego, el modelo calcula la similitud entre tu representación de texto y cada feature visual individual en ese grid. Los scores de alta similitud se convierten en tu máscara. El punto crucial aquí es que los weights del modelo permanecen completamente congelados. Estás extrayendo una pixel mask compleja usando solo el poder del alineamiento de lenguaje. Aquí está la clave. Zero-prediction es potente, pero depende de un entrenamiento amplio y de propósito general. A veces, el dominio visual es simplemente demasiado especializado. Si una enfermedad específica de la hoja de la vid se ve idéntica a una deficiencia de nutrientes inofensiva, el VLM congelado podría tener problemas para diferenciarlas puramente a partir de una descripción de texto. Aquí es cuando pasas al fine-tuning visual. En lugar de solo cambiar el prompt de texto, actualizas los weights reales de los componentes visuales del modelo usando un pequeño dataset de imágenes muy específicas, enmascaradas manualmente. Le estás enseñando explícitamente al vision encoder la textura visual matizada de la enfermedad, en lugar de depender solo de la comprensión conceptual amplia del language model sobre la palabra enfermedad. Zero-prediction trata al VLM como un motor de razonamiento out-of-the-box guiado completamente por palabras, mientras que el fine-tuning visual lo trata como un foundation potente que alteras permanentemente para dominar un dominio visual específico. El verdadero poder de la segmentación moderna ya no va de recopilar millones de píxeles etiquetados; se trata de saber cuándo guiar a un modelo congelado con un prompt de texto inteligente, y cuándo gastar el compute para alterar sus weights visuales. Eso es todo por este episodio. ¡Gracias por escuchar, y sigue construyendo!

Hola, soy Alex de DEV STORIES DOT EU. OpenCV: Computer Vision Deep Dive, episodio 14 de 20. Aunque los humanos pensamos en el color como una mezcla de rojo, verde y azul, intentar programar un ordenador para trackear un objeto usando RGB es una pesadilla en el momento en que una nube cubre el sol. La solución está en cómo representamos y combinamos matemáticamente los píxeles. Hoy veremos Pixel Alchemy: Alpha Blending y Color Spaces. El problema principal del color space RGB es que acopla la información de color directamente con la luminancia. Si una sombra cae sobre un objeto verde brillante, los valores de sus píxeles rojo, verde y azul cambian significativamente. Para un algoritmo de thresholding estándar, un objeto verde a la sombra se ve completamente diferente de uno iluminado. Para solucionar esto, transformas la imagen de RGB al color space HSV. HSV significa Hue, Saturation y Value. El Hue representa el color base en sí como un ángulo en un cilindro de color. La Saturation representa la intensidad de ese color, y el Value representa el brillo. Al aislar la información de color puro en ese único canal Hue, tu pipeline de Computer Vision se vuelve altamente resistente a los cambios de iluminación. Puedes configurar tu lógica para buscar un tono específico de verde, y lo encontrará tanto si la habitación está muy iluminada como si está a oscuras. Esta robustez es fundamental cuando construyes algo como un sistema automatizado de green-screen para un broadcast. Quieres integrar a la perfección un mapa del tiempo dinámico detrás de un presentador de noticias. Primero, coges el feed de la cámara y lo conviertes a HSV. Luego, defines un rango de Hues verdes que corresponden al fondo físico. Para cada píxel que caiga dentro de ese rango de Hue verde, devuelves un cero. Para todo lo demás, como el presentador, devuelves un uno. Esto crea una máscara binaria. Esta máscara actúa como tu canal alpha. Aquí está la clave. Los oyentes a menudo hablan del alpha como si fuera un color, casi como un tinte transparente. No lo es. El alpha es puramente un peso numérico, un valor escalar entre cero y uno que dicta la opacidad en una ecuación de interpolación lineal. El image blending es simplemente aritmética píxel a píxel. Para combinar el presentador del foreground y el mapa del tiempo del background, usas una ecuación específica. Para cada píxel, el color del output final es igual al píxel del foreground multiplicado por el valor alpha, más el píxel del background multiplicado por uno menos el valor alpha. Piensa en las matemáticas de ese escenario de green-screen. Donde está el presentador, el alpha es uno. El píxel del foreground se multiplica por uno, preservando al presentador a la perfección. El píxel del mapa del tiempo del background se multiplica por uno menos uno, que es cero. El mapa del tiempo desaparece en ese punto exacto. Por el contrario, donde está el green-screen, el alpha es cero. El píxel verde del foreground se multiplica por cero, borrando completamente la pantalla física. El píxel del mapa del tiempo del background se multiplica por uno menos cero, que es uno, haciendo que el mapa del tiempo sea completamente visible. Si quieres un borde suave y con anti-aliasing alrededor del presentador, usas valores alpha fraccionarios como cero coma cinco a lo largo del contorno. Esto hace una media entre los píxeles del foreground y del background para evitar contornos duros y dentados. Lo más útil que debes recordar es que las imágenes en memoria son solo matrices, y la manipulación de píxeles es solo aritmética matricial; elegir el sistema de coordenadas adecuado, como HSV, hace que esa aritmética sea robusta y predecible en lugar de frágil. Gracias por pasar unos minutos conmigo. Hasta la próxima, cuídate.

Hola, soy Alex de DEV STORIES DOT EU. OpenCV: Computer Vision Deep Dive, episodio 15 de 20. Cada fotografía que has hecho es una sutil mentira, distorsionada por el cristal curvo de la lente. En robótica, esa ligera distorsión es la diferencia entre atrapar una pelota y fallar por completo. Resolver esa brecha requiere Camera Calibration: navegando la distorsión de la lente. Montas una webcam fisheye barata y con mucha distorsión en un brazo robótico. El sistema necesita calcular la distancia exacta al milímetro para agarrar con seguridad una taza de café frágil. Si procesas el feed de vídeo raw directamente, tu geometría será completamente errónea. La lente curva la luz que entra, lo que significa que un píxel cerca del borde del frame representa una distancia en el mundo real drásticamente diferente a la de un píxel en el centro exacto. Si el robot confía en esos píxeles raw, aplastará la taza. Tenemos que corregir dos tipos principales de distorsión de la lente. El primero es la distorsión radial. La luz se curva más en los bordes de una lente que en su centro. Esto hace que las líneas rectas parezcan curvas, a menudo abombándose hacia afuera como un barril o hundiéndose hacia adentro. El segundo es la distorsión tangencial. Esto ocurre durante la fabricación cuando la lente no se monta perfectamente paralela al sensor de imagen, haciendo que algunas zonas de la imagen parezcan más cercanas que otras. Para arreglar esto, necesitamos un punto de referencia geométrico conocido. El estándar de la industria es un simple patrón de checkerboard plano impreso en un tablero rígido. Un checkerboard proporciona líneas de intersección nítidas y de alto contraste, haciendo que sea facilísimo para un algoritmo de detección localizar las esquinas interiores exactas. Y lo que es más importante, como lo hemos impreso nosotros, conocemos las dimensiones físicas exactas de los cuadrados. Los desarrolladores suelen confundir los parámetros intrínsecos y extrínsecos al trabajar con datos de calibración. Es fácil meterlos en el mismo saco como simples ajustes de la cámara. Aquí está la clave. Los parámetros extrínsecos no describen el hardware de la cámara en absoluto. Definen la ubicación física y la rotación de la cámara en el mundo 3D en relación con la escena. Los parámetros intrínsecos, por otro lado, definen las propiedades físicas internas de la lente y el sensor. Encapsulan la distancia focal y el centro óptico. La matriz intrínseca es única para esa cámara física en concreto y se mantiene constante sin importar a dónde se mueva el brazo robótico. El proceso de calibración funciona mapeando puntos 3D conocidos a píxeles 2D observados. Primero, haces una docena o más de fotos del checkerboard desde diferentes ángulos y distancias usando tu webcam. Después, ejecutas una función de detección de esquinas sobre esas imágenes. Construyes una lista de dónde caen estas coordenadas de píxeles 2D en las imágenes, y las emparejas con un array de las coordenadas 3D del mundo real de esas mismas esquinas. Las coordenadas 3D son simplemente un grid plano basado en el tamaño conocido de tu cuadrado, con el eje Z a cero. Pasas ambos sets de coordenadas a la función de calibración de la cámara. El algoritmo calcula la transformación matemática necesaria para mapear los puntos 3D en tus imágenes 2D. Te devuelve tu matriz intrínseca de la cámara, los vectores extrínsecos de rotación y traslación para cada imagen, y un set de coeficientes de distorsión. Estos coeficientes se encargan de la distorsión tanto radial como tangencial. Una vez que tienes estos coeficientes y la matriz intrínseca, los pasas a una función de undistortion. Cada nuevo frame que ve tu robot se estira y se ajusta matemáticamente hasta volver a una proyección rectilínea real. Las líneas rectas vuelven a ser rectas. Tu brazo robótico ahora puede medir milímetros exactos, estirarse y agarrar la taza con seguridad. La matriz intrínseca es la capa fundamental de la geometría de computer vision, convirtiendo un array de píxeles distorsionado en un sistema de coordenadas matemáticamente fiable. Eso es todo por este episodio. ¡Gracias por escuchar y seguid creando!

Hola, soy Alex de DEV STORIES DOT EU. OpenCV: Computer Vision Deep Dive, episodio 16 de 20. Tomando prestado el mismo truco biológico que usan nuestros dos ojos humanos para percibir el espacio tridimensional, un ordenador puede calcular al instante la distancia a un objeto usando solo geometría básica. Esto es Stereo Vision: Encontrando la profundidad con dos cámaras. Una sola cámara de salpicadero graba una proyección plana bidimensional del mundo. Pierde por completo la información de profundidad. Sin contexto, no puede saber de forma fiable si el coche de delante es pequeño y está cerca, o si es grande y está lejos. Para construir un Advanced Driver Assistance System, o ADAS, que realmente pueda evitar una colisión con un coche que frena, necesitas la distancia física real. Puedes conseguir esto montando dos cámaras de salpicadero perfectamente alineadas. La distancia física entre sus lentes se llama baseline. Para encontrar la distancia al coche de delante, el sistema tiene que encontrar exactamente el mismo punto en ese coche tanto en la imagen de la cámara izquierda como en la imagen de la cámara derecha. Buscar en toda la imagen derecha un punto de la imagen izquierda es demasiado lento para conducir en tiempo real. Aquí es donde entra en juego la geometría epipolar. Al transformar matemáticamente, o rectificar, las dos imágenes para que sus lentes estén virtualmente alineadas en exactamente el mismo plano, simplificas la búsqueda. Una luz trasera específica encontrada en la fila doscientos de la imagen izquierda, ahora solo existirá en la fila doscientos de la imagen derecha. Esta ruta de búsqueda horizontal se llama línea epipolar. El sistema solo tiene que escanear de izquierda a derecha a lo largo de una fila. Cuando el sistema encuentra el píxel correspondiente a lo largo de esa línea, mide la diferencia en sus posiciones horizontales. Esta diferencia se llama disparity. La gente suele confundir disparity con profundidad, pero son inversamente proporcionales. Los objetos que cambian drásticamente de posición entre las dos vistas de la cámara están físicamente más cerca de las lentes. Si el coche que frena delante salta cuarenta píxeles entre las vistas izquierda y derecha, está muy cerca. Si una montaña en el horizonte solo se desplaza un píxel, está lejos. Alta disparity significa baja profundidad. Aquí está la clave. No solo quieres la distancia a una luz trasera. Quieres un disparity map denso, es decir, un valor de profundidad para casi cada píxel del frame. OpenCV maneja esto usando block matching, específicamente un algoritmo llamado Semi Global Block Matching. En lugar de intentar hacer coincidir un único píxel ambiguo, coge un pequeño bloque de píxeles de la imagen izquierda. Luego desliza ese bloque a lo largo de la línea epipolar horizontal en la imagen derecha, comparando las intensidades de los píxeles hasta encontrar el mejor match matemático. Hace esto por toda la imagen, aplicando penalizaciones por saltos bruscos en la disparity para mantener el mapa resultante suave y físicamente realista. Una vez que tienes el disparity map, convertirlo a profundidad del mundo real es un solo cálculo. Multiplicas la distancia focal de las cámaras por la distancia física del baseline entre ellas, y divides ese resultado por el valor de disparity del píxel. Las matemáticas son absolutas. No estás adivinando basándote en sombras o en el tamaño del objeto. Mientras tus cámaras se mantengan rígidamente calibradas y alineadas, este cálculo geométrico te da la distancia precisa al vehículo de delante en milisegundos. La ventaja de un stereo rig calibrado es que evita la necesidad de identificar qué es un objeto antes de saber dónde está. Eso es todo por este episodio. ¡Gracias por escuchar, y seguid construyendo!

Hola, soy Alex de DEV STORIES DOT EU. OpenCV: Deep Dive en Computer Vision, episodio 17 de 20. Durante décadas, los ingenieros de Computer Vision creían que necesitabas dos cámaras para calcular la distancia real. Necesitabas visión estereoscópica para triangular puntos en el espacio. Hoy en día, los modelos de IA pueden percibir la distancia física a partir de una sola imagen plana interpretando las sombras, la textura y la escala, igual que hace un pintor. Este avance se llama Deep Monocular Metric Depth. La gente suele confundir la profundidad relativa con la profundidad métrica. La profundidad relativa es simplemente saber que un sofá está delante de una pared. Es una ordenación de capas visuales. La profundidad métrica significa saber que el sofá está exactamente a dos coma cuatro metros de la lente de la cámara. Hasta hace poco, sacar medidas métricas absolutas de una sola foto se consideraba matemáticamente imposible. Una sola imagen en 2D pierde toda su escala inherente. Un objeto podría ser pequeño y estar cerca de la lente, o ser enorme y estar muy lejos. Los modelos de deep learning se saltan por completo el problema de la geometría clásica. En lugar de triangular puntos entre dos lentes, redes como DepthPro aprenden de datasets masivos que contienen millones de imágenes emparejadas con mapas de profundidad 3D de ground-truth. Cuando le pasas una sola imagen estándar a la red, no busca disparidades estéreo. Evalúa pistas monoculares. Analiza los gradientes de textura, fijándose en que las superficies se ven más suaves cuanto más lejos están. Procesa la iluminación contextual, la oclusión y la escala física conocida de objetos reconocibles. Luego, el modelo construye una predicción densa, píxel a píxel, de la distancia absoluta. Aquí está la clave. Las arquitecturas modernas logran esto sin conocer tus camera intrinsics. No necesitas pasarle a la red la distancia focal, el field of view o el tamaño del sensor de la cámara que hizo la foto. La red infiere la distancia focal directamente del contenido visual de la propia imagen. Esto crea una solución zero-shot. Le pasas al modelo una foto hecha con cualquier lente aleatoria sin calibrar, y te devuelve un mapa de profundidad absoluta preciso. Piensa en una aplicación de realidad aumentada en un smartphone estándar. Un usuario quiere ver si una mesa de comedor nueva cabe en su casa. Se pone de pie en una habitación vacía y apunta su única cámara trasera al suelo. La realidad aumentada clásica requiere que muevas el teléfono para generar paralaje y construir poco a poco un mapa espacial. Con el deep monocular metric depth, la aplicación procesa un solo frame estático al instante. La red neuronal calcula el volumen y las dimensiones exactas del espacio del suelo en milisegundos. Luego, la aplicación renderiza una mesa virtual en el feed de la cámara, perfectamente escalada al mundo real, plantada en el suelo a la profundidad exacta. Bajo el capó, lograr esto requiere receptive fields masivos en la arquitectura de la red neuronal. El modelo usa Vision Transformers para capturar el contexto global. Mira toda la imagen a la vez para entender la geometría general de la habitación. Luego combina esta vista amplia con un procesamiento local de alta resolución. Este enfoque dual permite al modelo producir límites de profundidad nítidos alrededor de bordes complejos, como las patas finas de una silla o las hojas de una planta de interior. Evita por completo los artefactos borrosos y de bordes difusos que plagaban los modelos de estimación de profundidad anteriores. El cambio fundamental es la capacidad de extraer medidas espaciales absolutas de un solo frame de imagen, completamente sin calibrar. Eso es todo por este episodio. ¡Gracias por escuchar, y seguid desarrollando!

Hola, soy Alex de DEV STORIES DOT EU. OpenCV: Computer Vision Deep Dive, episodio 18 de 20. Los deploys de inteligencia artificial más impresionantes de hoy en día no se ejecutan en enormes granjas de servidores climatizadas. Se ejecutan en chips de silicio de dos dólares, alimentados por una pila de reloj, en medio de la nada. Mover redes neuronales complejas a estos diminutos dispositivos requiere un enfoque completamente diferente, lo que nos lleva a la IA en el Edge: Deploys en Microcontroladores. Los microcontroladores están increíblemente limitados. Hablamos de dispositivos con kilobytes de RAM, unos pocos megabytes de almacenamiento flash y límites de energía estrictos. Los modelos estándar de Computer Vision usan floats de 32 bits para sus weights y activations. Un modelo típico necesita cientos de megabytes solo para cargarse en memoria. Si intentas ejecutar eso en un microcontrolador básico, hará crash inmediatamente por falta de memoria. Piensa en una cámara de fauna silvestre alimentada por batería y recargada con energía solar, desplegada en lo profundo de un bosque. Su función es detectar un leopardo de las nieves en peligro de extinción. Si la cámara despierta su transmisor de radio para enviar cada foto activada por movimiento a un servidor en el cloud para su análisis, la batería se agotará en un día. El dispositivo tiene que ejecutar el object detector en local. Debe procesar el feed de vídeo directamente en el silicio y solo despertar al transmisor, que consume mucha energía, para enviar una alerta cuando identifique específicamente al leopardo. Para meter un modelo de visión en un chip tan pequeño, tienes que reducirlo drásticamente. Esto lo haces principalmente mediante dos técnicas: pruning y quantization. El pruning es exactamente lo que parece. Analizas la red neuronal entrenada y eliminas las conexiones que tienen el menor impacto en la predicción final. Básicamente, estás cortando la madera muerta de la arquitectura de la red para que se hagan menos cálculos por frame. La segunda técnica, la quantization, es donde ocurre la verdadera reducción de tamaño. Esta es la parte que importa. La quantization reduce la precisión numérica del modelo. En lugar de almacenar cada weight como un float de 32 bits, mapeas esos valores a un integer de 8 bits, lo que se conoce comúnmente como conversión INT8. El trade-off principal aquí es muy simple. Estás descartando intencionadamente precisión numérica. Para hacer esto correctamente, pasas un dataset de calibración por el modelo para rastrear los valores mínimo y máximo de los weights. Luego, escalas ese rango de floating-point para que encaje exactamente dentro de los 256 valores posibles de un integer de 8 bits. Esto intercambia una pequeña fracción de la accuracy del modelo por una reducción masiva en el memory footprint y el tiempo de ejecución. Un modelo INT8 ocupa exactamente una cuarta parte del almacenamiento de un modelo de 32 bits. Además, los microcontroladores manejan las matemáticas de integers mucho más rápido y con mucha menos energía que las matemáticas de floating-point. Muchos microcontroladores de bajo consumo carecen por completo de hardware dedicado para operaciones de floating-point. Esto significa que las matemáticas de floating-point tienen que emularse por software, lo cual es increíblemente lento y agota la batería. Con un modelo INT8 con quantization agresiva, cuando la cámara de fauna silvestre captura una imagen, la red neuronal multiplica y suma pequeños valores de integers en ciclos de reloj de hardware individuales. El microcontrolador puede evaluar la imagen en milisegundos, confirmar que no hay ningún leopardo de las nieves y volver instantáneamente a un estado de deep sleep para conservar energía. El proceso real de deploy empieza en un ordenador de escritorio normal. Entrenas tu modelo en un dataset estándar. Una vez entrenado, ejecutas un script conversor que aplica el pruning y la quantization a INT8. El output suele ser un array de bytes plano exportado como un bloque de código de cabecera de C que contiene los weights comprimidos. Compilas esto directamente en el firmware de tu microcontrolador junto con los drivers de tu cámara. No hay sistema operativo ni file system desde donde cargar modelos en el runtime. Es pura lógica compilada ejecutándose directamente en el bare metal. La limitación extrema en este entorno cambia cómo evalúas el éxito. En un microcontrolador, tu métrica principal ya no es la precisión máxima, es el número de inferencias precisas que puedes ejecutar por milijulio de energía de la batería. Si quieres ayudarnos a que el programa continúe, puedes apoyarnos buscando DevStoriesEU en Patreon. Eso es todo por este episodio. ¡Gracias por escuchar, y a seguir construyendo!

Hola, soy Alex de DEV STORIES DOT EU. OpenCV: Computer Vision Deep Dive, episodio 19 de 20. Los videojuegos tradicionales renderizan mundos dibujando millones de pequeños triángulos planos. La última revolución en Computer Vision elimina por completo los triángulos, renderizando la realidad como una densa nube de millones de blobs matemáticos brillantes y superpuestos. Esto es Radiance Fields: 3D Gaussian Splatting. Un agente inmobiliario recorre una casa grabando un vídeo estándar con un smartphone. Tienes que procesar ese raw footage para crear un tour virtual 3D fotorrealista y totalmente navegable, con reflejos e iluminación dinámicos. Durante algunos años, el enfoque estándar fueron los Neural Radiance Fields, o NeRFs. Un NeRF mapea el espacio usando una red neuronal implícita. Para generar una imagen, lanza un rayo matemático a través de la escena y hace una query a la red neuronal en cientos de puntos a lo largo de ese rayo para preguntarle qué color y densidad hay ahí. Produce resultados espectaculares, pero hacer queries a una red neuronal profunda para millones de píxeles es extremadamente lento. El 3D Gaussian Splatting abandona la red neuronal implícita. En su lugar, utiliza una estructura explícita similar a una point cloud. El pipeline empieza con un algoritmo estándar de structure-from-motion que analiza el vídeo del smartphone para trackear la posición de la cámara y construir una point cloud 3D dispersa de la casa. Luego, el algoritmo reemplaza cada punto de esa cloud con un 3D Gaussian. Puedes pensar en un 3D Gaussian como un elipsoide semitransparente y de color. Cada 3D Gaussian contiene un conjunto específico de parámetros. Tiene una coordenada central en el espacio 3D. Tiene una covariance matrix, que dicta su escala y rotación, estirándolo hasta formar un disco plano o un puro alargado dependiendo de la geometría que represente. Tiene un valor de opacidad. Finalmente, almacena datos de color usando Spherical Harmonics. Aquí está la clave. Los Spherical Harmonics son funciones matemáticas que codifican el color direccionalmente. Cuando miras el 3D Gaussian desde un ángulo, puede que refleje una ventana brillante. Desde otro ángulo, muestra la textura oscura de una tabla del suelo. Esto es lo que le da al tour virtual final su iluminación fotorrealista, dependiente de la vista. La point cloud inicial es caótica, así que el sistema entra en un loop de optimización. Proyecta, o hace splat, estos 3D Gaussians sobre una vista de cámara 2D para renderizar una imagen. Resta esta imagen renderizada de la fotografía real que tomó el agente inmobiliario para calcular el error. Luego, el algoritmo usa ese error para actualizar los parámetros de los 3D Gaussians. Durante esta optimización, el sistema gestiona activamente la población de 3D Gaussians. Si un blob crece demasiado y solapa demasiado detalle, el algoritmo lo divide en trozos más pequeños. Si un área con texturas complejas necesita más resolución, el algoritmo clona los 3D Gaussians existentes para aumentar la densidad. Si un blob se vuelve completamente transparente o irrelevante, el sistema lo borra. Como la escena final está compuesta enteramente por data points explícitos, renderizarla es excepcionalmente rápido. El hardware gráfico simplemente ordena los elipsoides de atrás hacia adelante y mezcla sus colores para formar la imagen final. El gran avance del 3D Gaussian Splatting es demostrar que una nube caótica de blobs matemáticos explícitos puede capturar luz y geometría complejas mucho más rápido que una red neuronal densa. Gracias por escuchar. Cuidaos todos.

Hola, soy Alex de DEV STORIES DOT EU. OpenCV: Deep Dive en Computer Vision, episodio 20 de 20. Durante décadas, los algoritmos de Computer Vision fueron completamente pasivos. Podían dibujar un bounding box alrededor de una taza sobre una mesa, pero ahí terminaba todo. Hoy en día, el sistema no solo ve la taza, sino que utiliza esos datos visuales para alcanzarla y agarrarla. El puente entre ver y actuar es el Vision-Action Loop, impulsado por Agentic AI. Antes de entrar en la mecánica, tenemos que marcar una línea clara entre dos tecnologías que suenan parecido, pero que hacen trabajos totalmente distintos. Un Vision-Language Model estándar, o VLM, es descriptivo. Le pasas un screenshot y te devuelve un texto diciéndote qué hay en la pantalla. Un modelo Vision-Language-Action, o VLA, es ejecutivo. Le das a un VLA un screenshot y un objetivo, y te devuelve comandos ejecutables. No solo describe la interfaz de usuario, sino que interactúa activamente con ella. Agentic AI convierte un pipeline de visión en un órgano sensorial para un motor de toma de decisiones. Este opera en un ciclo continuo de percibir, razonar y actuar. Primero, el sistema toma una observación visual de su entorno actual. Esto podría ser el feed de una cámara de un robot o una captura en tiempo real del escritorio de un ordenador. Después, el agente procesa este estado visual junto con un prompt o un objetivo específico. Analiza las relaciones espaciales, lee texto e identifica elementos interactivos. Cuando el modelo identifica un elemento, mapea la comprensión semántica —saber que un rectángulo verde específico es un botón de submit— a un espacio de coordenadas geométricas. Finalmente, en lugar de devolver una descripción, el modelo genera un payload de acción. A menudo, se trata de un comando estructurado que contiene coordenadas exactas de la pantalla, un ajuste de un motor de hardware o una API call. Una vez que se ejecuta la acción, el entorno cambia. El agente toma una nueva observación visual, comprueba si la acción anterior tuvo éxito y calcula el siguiente paso. Aquí está la clave. Los datos visuales ya no son un callejón sin salida; son el mecanismo de grounding para el uso autónomo de herramientas. Vamos a ver un escenario concreto de un asistente digital de contabilidad automatizado. El objetivo es autorizar un pago. El agente empieza capturando la pantalla. El modelo de visión procesa una factura en PDF escaneada, extrayendo el nombre del proveedor y el importe total. El motor de razonamiento sabe que necesita loguear estos datos. Genera una acción para mover el ratón al icono del software de contabilidad en la barra de tareas y hacer clic en él. La pantalla se actualiza. El agente toma otra observación visual para verificar que la aplicación está abierta. Escanea la nueva interfaz, localiza el campo de autorización de pago, mapea la ubicación visual a las coordenadas de la pantalla, escribe el importe y hace clic en el botón de submit. El pipeline de visión envía constantemente actualizaciones de estado al agente para que sepa exactamente cuándo ejecutar la siguiente acción y, lo que es más importante, cuándo parar. Computer Vision ha evolucionado de una herramienta de análisis independiente a la capa sensorial de los sistemas autónomos. Si tu pipeline solo analiza una imagen y se detiene, solo estás utilizando la mitad de la tecnología. Como este es nuestro último episodio, te animo a explorar la documentación oficial de los modelos VLA, a intentar construir un feedback loop básico de forma práctica, o a visitar devstories dot eu para sugerir temas para nuestra próxima serie. Eso es todo por este episodio. ¡Gracias por escuchar, y sigue construyendo!