OpenCV: Computer Vision Deep Dive

Olá, daqui é o Alex da DEV STORIES DOT EU. OpenCV: Deep Dive em Computer Vision, episódio 1 de 20. A maioria dos developers pensa numa imagem como um ficheiro comprimido guardado num disco rígido. Mas, no momento em que passas esse ficheiro para uma library de computer vision, ele abandona o seu file format e transforma-se numa enorme grelha de números, à espera de matemática de matrizes. Perceber exatamente como esses números estão estruturados é A Alma do OpenCV: Pixels como Matrizes. Quando carregas uma imagem usando o OpenCV, a função read puxa o ficheiro do disco e converte-o instantaneamente num array NumPy multidimensional. Esta é a parte que interessa. O OpenCV em Python não usa um objeto de imagem proprietário. Depende inteiramente do NumPy. Como uma imagem é apenas um array standard, qualquer operação matemática que possas aplicar a um array pode ser aplicada diretamente à tua imagem. Vamos olhar para a estrutura deste array. Se carregares uma imagem a cores standard, ficas com uma matriz tridimensional. A primeira dimensão é a altura, que representa o número de linhas. A segunda dimensão é a largura, que representa o número de colunas. A terceira dimensão guarda os canais de cor. Se tiveres uma imagem com oitocentos pixels de largura e seiscentos pixels de altura, o shape do teu array será de seiscentas linhas, oitocentas colunas e três canais. Cada interseção de uma linha e de uma coluna guarda um pixel. E para imagens standard, cada canal de cor dentro desse pixel guarda um valor integer de zero a duzentos e cinquenta e cinco, que representa a intensidade dessa cor. Há aqui uma armadilha muito comum. A maioria do software gráfico e dos web browsers representa as cores no formato Red, Green, Blue, conhecido como RGB. O OpenCV não. Por razões históricas que remontam ao hardware das primeiras câmaras, o OpenCV guarda os canais de cor na ordem inversa: Blue, Green, Red, ou BGR. Se tentares mostrar uma imagem do OpenCV noutra library sem fazeres swap a esses canais, os teus vermelhos vão parecer azuis e os teus azuis vão parecer vermelhos. Não é um bug no teu código. Lembra-te apenas que o valor no index zero do canal é azul, o index um é verde e o index dois é vermelho. Como as imagens são apenas arrays NumPy, manipulá-las depende da sintaxe standard de Python. Não precisas de funções especializadas do OpenCV para fazer crop a uma imagem. Basta fazeres slice do array. Supõe que tens o feed de uma câmara de segurança de alta definição, e só te interessa uma região de cem por cem pixels onde está localizada uma porta. Extrais uma Region of Interest, ou ROI, usando array slicing standard. Especificas a linha inicial e a linha final, seguidas pela coluna inicial e pela coluna final. Em termos matemáticos, fazes slice do eixo Y primeiro, e depois do eixo X. Isto devolve instantaneamente um array NumPy mais pequeno, contendo apenas os dados dos pixels da porta. Depois de fazeres slice do teu array ou de modificares os seus pixels, normalmente queres guardar o resultado. O OpenCV trata disso com uma simples função write. Forneces um file path de destino e passas o teu array NumPy. O OpenCV lê a extensão de ficheiro que pediste, como dot JPG, e trata automaticamente da compressão complexa necessária para transformar essa matriz de números de volta num ficheiro de imagem standard. A coisa mais útil que podes fazer ao aprender computer vision é parar de pensar nas imagens como telas visuais, e começar a tratá-las como sistemas de coordenadas cheios de dados numéricos raw. Se gostas destes deep dives, podes apoiar o programa procurando por DevStoriesEU no Patreon. É tudo por este episódio. Obrigado por ouvires, e continua a desenvolver!

Olá, daqui fala o Alex da DEV STORIES DOT EU. OpenCV: Computer Vision Deep Dive, episódio 2 de 20. Aplicar um filtro de blur a uma foto parece um efeito visual complexo, mas, computacionalmente, é apenas substituir cada pixel pela média matemática dos seus vizinhos imediatos. O mecanismo por trás disto é o que vamos abordar hoje: Convolution Kernels: Filtering e Edge Detection. Quando ouves a palavra convolução, podes pensar imediatamente em Convolutional Neural Networks. Precisamos de separar esses conceitos agora mesmo. Numa rede de deep learning, um modelo descobre os valores dentro dos seus filtros durante um processo de treino massivo. Hoje, vamos falar sobre convolução bidimensional clássica. Estes kernels são matrizes matemáticas fixas e hardcoded que existem há décadas. Eles não aprendem. Apenas calculam. Um kernel é simplesmente uma pequena grelha de números. Um tamanho comum é um quadrado de três por três. A convolução é o processo de pegar nesta pequena grelha e fazê-la deslizar por toda a tua imagem, um pixel de cada vez. Em cada paragem, alinhas o centro do teu kernel com um pixel específico da imagem. Depois, multiplicas cada número no teu kernel pelo valor do pixel da imagem diretamente por baixo dele. Somas todos esses nove resultados e essa soma final torna-se o novo valor único para o pixel central na tua imagem de output. Fazes isto para cada pixel. Os números que colocas dentro dessa pequena grelha ditam exatamente o que acontece à imagem inteira. Se preencheres o kernel com frações que somam um, obténs um blur. Um Gaussian blur é um tipo específico de kernel onde o valor central tem o maior peso, e os valores diminuem à medida que te moves em direção às extremidades da grelha. Isto cria uma média ponderada localizada. Esta é a parte que importa. Não aplicamos blur a imagens para as tornar artísticas. Aplicamos blur para destruir ruído. Um sensor de câmara regista pequenas flutuações aleatórias de luz. Se tentares analisar a estrutura rígida de uma imagem com essa estática presente, os teus algoritmos vão falhar. O Gaussian blur suaviza o ruído errático, preservando as formas gerais. Assim que o ruído desaparece, geralmente queres encontrar os objetos reais na frame. Considera um sistema de câmaras concebido para ler matrículas. Antes de poderes ler os caracteres, tens de isolar a matrícula retangular contra o para-choques do carro. Para um computador, uma edge é simplesmente uma transição repentina de pixels escuros para pixels claros, ou vice-versa. Para encontrar estas transições nítidas, trocamos a matriz de blur por uma matriz de edge detection, como o Sobel kernel. Um Sobel kernel vertical é concebido especificamente para encontrar edges verticais. É uma grelha de três por três contendo uma coluna de números negativos à esquerda, uma coluna de zeros no meio e uma coluna de números positivos à direita. À medida que este kernel desliza sobre uma área de cor sólida, como um para-choques cinzento liso, os números negativos e positivos multiplicam-se pelo mesmo valor de cinzento. Eles anulam-se mutuamente. A soma é zero, o que se traduz num pixel preto na imagem de output. As áreas sólidas desaparecem. Mas quando o kernel aterra exatamente na fronteira vertical entre esse para-choques escuro e uma matrícula branca brilhante, a matemática muda. Os números negativos multiplicam-se por pixels escuros, produzindo um valor pequeno. Os números positivos multiplicam-se por pixels brancos brilhantes, produzindo um valor enorme. Já não se anulam. A soma final é um número positivo muito alto, que cria um pixel branco brilhante na tua imagem de output exatamente onde a edge está localizada. Ao executar esta operação em toda a imagem, o para-choques desaparece na escuridão, deixando para trás um contorno branco nítido da matrícula. Acabaste de transformar dados de cor brutos em geometria estrutural. A principal conclusão é que um convolution kernel clássico não é mais do que uma regra matemática local aplicada globalmente, ditando como cada pixel deve reagir aos seus vizinhos imediatos. Obrigado por passares uns minutos comigo. Até à próxima, fica bem.

Olá, daqui é o Alex da DEV STORIES DOT EU. OpenCV: Computer Vision Deep Dive, episódio 3 de 20. Precisas do contour exato de um objeto num tapete rolante. O teu primeiro instinto pode ser usar uma enorme semantic segmentation neural network. Mas calcular esse contour usando geometria standard é ordens de magnitude mais rápido, computacionalmente mais barato e não requer uma GPU. É exatamente isso que o Drawing Boundaries: Contours and Geometry te permite fazer. Um erro comum é tratar edges e contours como a mesma coisa. São data structures fundamentalmente diferentes. Um edge detector dá-te um binary map de pixels brancos desorganizados e desconectados, onde a intensidade muda. Um contour é uma curva matemática contínua que une todos os pontos consecutivos ao longo de uma boundary com a mesma cor ou intensidade. Edges são apenas pontos isolados num ecrã. Contours criam formas fechadas e mensuráveis. Imagina um sistema de controlo de qualidade de uma fábrica a inspecionar uma engrenagem de metal. Já converteste o feed da câmara numa imagem binária a preto e branco. A engrenagem é totalmente branca contra um fundo preto. Para obteres a mathematical boundary dessa engrenagem, passas esta imagem para a função de contour finding. O OpenCV faz isto ao fazer scan da imagem linha a linha. Quando o algoritmo encontra uma boundary entre pixels pretos e brancos, ele traça essa boundary, registando as coordenadas num array. Para poupar memória, ele comprime o output, guardando apenas os pontos inicial e final de segmentos retos, em vez de cada pixel individual. Este processo também captura relações espaciais. A engrenagem tem uma outer edge, mas também tem um buraco no meio para o eixo. O algoritmo de contours constrói uma hierarquia. Ele regista a outer boundary como um parent contour, e o buraco interno como um child contour. Isto permite-te analisar ou ignorar seletivamente formas internas, com base nas tuas necessidades. Agora que tens a engrenagem como uma connected boundary, podes extrair a sua geometria. Podes calcular a contour area. Este é um cálculo matemático da área total de pixels dentro da curva fechada. Uma engrenagem perfeitamente fabricada terá uma área específica e conhecida. Se uma engrenagem tiver um dente partido, a área do seu contour cai abaixo do teu threshold aceitável. Sinalizas o defeito instantaneamente. Às vezes, precisas de entender a forma geral de um objeto, ignorando os seus detalhes intrincados. É aqui que a coisa fica interessante. Podes computar o convex hull de um contour. Pensa no convex hull como um elástico esticado firmemente à volta da parte de fora do teu objeto. Para a engrenagem, o standard contour traça perfeitamente cada dente e reentrância. O convex hull ignora as reentrâncias. Estende-se em linha reta da ponta de um dente até à ponta do próximo. Ao comparar o contour original com o convex hull, identificas anomalias estruturais. Os espaços vazios entre o elástico e o contour real da engrenagem chamam-se convexity defects. Medir estes defects diz-te exatamente a profundidade dos dentes da engrenagem e se algum deles está desgastado, tudo através de puro cálculo geométrico. Os contours preenchem a lacuna entre o image processing de baixo nível e a object analysis de alto nível, transformando uma grelha de pixels burros em formas geométricas estruturadas que podes validar rigorosamente. É tudo por este episódio. Obrigado por ouvires, e continua a construir!

Olá, daqui fala o Alex da DEV STORIES DOT EU. OpenCV: Computer Vision Deep Dive, episódio 4 de 20. Os visual trackers mais robustos não memorizam a aparência completa de um objeto. Em vez disso, fixam-se em cantos matematicamente distintos e gradients de alto contraste que se mantêm consistentes independentemente da iluminação. Fazer isto bem é o domínio dos Feature Detectors: Keypoints e Neural Matching. Antes de olharmos para a mecânica, precisamos de separar isto da object detection. A object detection aplica categorias semânticas amplas. Desenha uma bounding box e diz-te que está um edifício na frame. O feature matching é estritamente estrutural. Não sabe o que é um edifício. Encontra uma interseção específica e idêntica de dois tijolos em duas imagens diferentes. Pensa em criar uma aplicação de panorama stitching. Tens duas fotos sobrepostas de uma parede de tijolos, tiradas de ângulos ligeiramente diferentes. Para fazer o stitch de forma perfeita, o software precisa de alinhar matematicamente a sobreposição. Faz isto encontrando local features distintas na primeira imagem, encontrando essas mesmas features na segunda imagem e emparelhando-as. O primeiro passo é a detection. O sistema faz o scan da imagem em busca de keypoints. Um keypoint é uma localização específica de um pixel que se destaca da sua área envolvente. Áreas planas, como um céu limpo ou uma parede branca lisa, são inúteis porque todos os pixels são exatamente iguais. O algoritmo procura por texturas fortes, cantos nítidos e linhas que se cruzam. Tradicionalmente, os algoritmos dependiam de fórmulas matemáticas hand-crafted para encontrar estas edges. As abordagens modernas utilizam convolutional neural networks. Alimentas a rede com a imagem, e ela faz o output de um probability map que indica a probabilidade de um determinado pixel ser um keypoint estável. Assim que a rede identifica um ponto, como o canto de uma moldura de janela específica, precisa de uma maneira de o descrever. Este é o descriptor. A neural network gera um vetor de alta dimensão, um embedding, que captura o padrão visual dos pixels imediatamente à volta desse keypoint. Um descriptor robusto permanece matematicamente semelhante mesmo que a segunda foto seja tirada numa escala diferente, rodada, ou sob diferentes condições de iluminação. Aqui está o insight principal. Ter uma lista de pontos e as suas descrições é apenas metade do puzzle. Ainda tens de fazer o match dos pontos da tua primeira imagem com os pontos da tua segunda imagem. Historicamente, calculavas apenas a distância entre os vetores e escolhias o mais próximo. Mas padrões repetidos, como centenas de tijolos idênticos numa parede, causam erros graves de mismatching. É aqui que entram os modelos de neural matching. Em vez de avaliar um keypoint isoladamente, um neural matcher analisa as relações espaciais entre todos os keypoints de uma só vez. Aprende, essencialmente, que um canto específico pode parecer-se com outros cinquenta cantos de tijolos, mas é o único localizado exatamente entre a moldura de uma janela e uma sombra específica. Ao passar os descriptors e as suas posições geométricas por self-attention layers, o sistema rejeita falsos positivos e faz o output de matching pairs altamente precisos. Numa pipeline típica, primeiro passas ambas as imagens por uma feature extraction network. Isto devolve dois conjuntos de keypoints e dois conjuntos de descriptors. A seguir, passas ambos os conjuntos de dados para uma matching network. A matching network calcula as similaridades contextuais e devolve uma lista de pares válidos, descartando os keypoints que não existem em ambas as frames. Depois, usas esses pares de coordenadas que fizeram match para calcular a transformação geométrica necessária para fazer o warp e o stitch das duas fotos perfeitamente. A mudança de fórmulas hand-crafted para neural embeddings significa que o feature matching agora pode lidar com variações extremas de iluminação e pontos de vista extremos que costumavam quebrar completamente os algoritmos mais antigos. Obrigado por ouvirem, happy coding a todos!

Olá, daqui fala o Alex da DEV STORIES DOT EU. OpenCV: Deep Dive em Computer Vision, episódio 5 de 20. As apps de document scanner para telemóvel parecem magia complexa de AI. Apontas o telemóvel para uma folha de papel e, instantaneamente, ela achata-se num documento digital perfeito. Mas o core engine por trás disto não é uma neural network a prever detalhes em falta. Baseia-se num truque matemático com quinze anos que envolve uma matriz de transformação três por três. Este episódio aborda Geometria do Mundo Real: Construir um Document Scanner. Imagina um recibo amarrotado em cima da mesa de um restaurante. Tiras uma foto de um ângulo inclinado. Devido à perspetiva, o recibo parece um trapézio distorcido, rodeado pela textura da mesa. Para extrair o documento, o primeiro passo é isolá-lo do background. Convertes a imagem para grayscale e aplicas um ligeiro blur. Isto suaviza os detalhes com ruído, como os vincos no papel ou os veios da madeira na mesa, enquanto mantém as boundaries principais intactas. A seguir, corres o Canny edge detection. Isto destaca as mudanças bruscas de intensidade, deixando-te com um outline brilhante do recibo contra um background escuro. De seguida, precisas de transformar essas edges soltas numa forma definida. Encontras os contours no edge map. A imagem vai conter muitos contours, e a maioria deles são pequenos artefactos inúteis. Ordenas por área, mantendo apenas os maiores. Depois, iteras por estes grandes contours e aproximas a sua forma poligonal. Estás à procura de uma pista estrutural específica. Se encontrares uma forma que possa ser aproximada com exatamente quatro pontos, encontraste a boundary do teu recibo. Esses quatro pontos definem os cantos do teu documento na foto original, em ângulo. Agora chegamos à etapa crucial de achatar o documento. Um equívoco comum é que este processo usa inteligência artificial para adivinhar ou alucinar missing data. Não é o caso. Um perspective transform é um puro warping matemático de pixel coordinates de um plano para outro. Para executar isto, precisas de dois conjuntos de quatro pontos. O primeiro conjunto são os quatro cantos que acabaste de encontrar no recibo. O segundo conjunto representa onde esses cantos deveriam estar na imagem final e perfeita. Para obter o segundo conjunto, calculas a largura e a altura máximas do recibo distorcido usando a fórmula da distância entre os pontos originais. De seguida, defines um novo retângulo perfeito, começando na coordenada zero zero e estendendo-se até essa largura e altura exatas. Com estes dois conjuntos de pontos, calculas uma perspective transformation matrix. Esta matriz define exatamente o quanto cada pixel precisa de ser deslocado, esticado ou comprimido para passar da forma trapezoidal inclinada para a forma retangular plana. Finalmente, aplicas esta matriz à imagem original de alta resolução. A matemática literalmente puxa os quatro cantos para fora e endireita-os, fazendo o warping de todos os pixels interiores juntamente com eles. O resultado é uma imagem bidimensional perfeitamente top-down do teu recibo, pronta para processamento. Aqui está o principal insight. Não precisas de deep learning para corrigir a perspetiva. Desde que consigas isolar quatro cantos, uma simples operação matricial vai remapear perfeitamente a geometria de qualquer superfície plana. Obrigado por estares aí. Espero que tenhas aprendido algo novo.

Olá, daqui fala o Alex do DEV STORIES DOT EU. OpenCV: Deep Dive em Computer Vision, episódio 6 de 20. Quando um novo algoritmo de tracking se torna uma função standard na library principal do OpenCV, muitas vezes já passou anos a ser testado exaustivamente por investigadores num espaço paralelo e separado. Se te limitares apenas às releases default, estás a perder as técnicas mais recentes da área. Esse espaço paralelo é o repository opencv_contrib. Muitos developers veem a palavra "contrib" e assumem que o código está broken, não foi testado, ou é estritamente software beta. Isso é um mal-entendido. O código neste repository é muitas vezes altamente otimizado e usado ativamente em ambientes exigentes. A distinção tem inteiramente a ver com a estabilidade da API, e não com a qualidade do código. A library core do OpenCV impõe garantias rigorosas de backward-compatibility a longo prazo. Se uma função entra na release principal, os seus inputs, outputs e comportamento devem permanecer estáveis durante anos. Mas a investigação em computer vision avança de forma agressivamente rápida. Os investigadores precisam de um lugar para publicar novos algoritmos, renomear parâmetros e alterar estruturas de dados com base em feedback do mundo real. O repository opencv_contrib oferece exatamente esse ambiente. Funciona como uma incubadora. Os maintainers destes módulos extra têm permissão para quebrar a API entre releases. Podem renomear funções ou alterar a forma como um algoritmo inicializa sem violar as regras estritas da library core. Com o tempo, um módulo pode revelar-se universalmente útil. A sua API estabiliza, os edge cases são resolvidos, e a comunidade passa a depender muito dele. Quando isso acontece, os maintainers do OpenCV migram o código. Movem fisicamente o módulo para fora do repository opencv_contrib e fazem merge diretamente para o repository principal do OpenCV. Este processo de graduação garante que a library core absorve apenas tecnologia comprovada e estável. Considera um cenário concreto. Estás a construir um projeto de realidade aumentada e queres usar o módulo de tracking ArUco para detetar marcadores fiduciais quadrados num feed de câmara em direto. Este módulo contém funções state-of-the-art altamente especializadas. Para o usares, fazes a build do teu ambiente OpenCV a partir do source. Fazes clone do repository principal para a tua máquina local, e depois fazes clone do repository opencv_contrib logo ao lado. Ao configurares a tua build tool, passas uma variável de path específica que aponta para a pasta modules dentro do repository contrib. O build system lê esta flag e compila a library core, mas também vai à pasta contrib, compila o módulo ArUco, e faz o link diretamente para os teus binaries finais. Não acabas com duas libraries separadas. Ficas com uma única instalação unificada do OpenCV que inclui tanto a base sólida como os módulos experimentais que escolheste. Se gostas do podcast e queres ajudar a apoiar o programa, podes procurar por DevStoriesEU no Patreon — é sempre apreciado. O verdadeiro poder desta arquitetura reside em compreender a sua natureza dupla: o repository principal protege os teus pipelines de produção de breaking changes, enquanto o repository contrib te entrega a investigação em computer vision de amanhã, hoje. É tudo por este episódio. Até à próxima!

Olá, daqui fala o Alex da DEV STORIES DOT EU. OpenCV: Análise aprofundada de Visão Computacional, episódio 7 de 20. Podes arrancar o cérebro de um servidor massivo de treino PyTorch, exportá-lo como um único ficheiro e corrê-lo de forma incrivelmente rápida em C++ puro, sem instalares o PyTorch de todo. Quando passas do treino de um modelo para fazer o seu deploy no mundo real, os teus requisitos mudam de flexibilidade para velocidade bruta. É exatamente aqui que o Inference Engine, o módulo DNN do OpenCV, entra em ação. Uma armadilha comum em que os engenheiros caem é assumir que, se um modelo foi treinado usando TensorFlow, a máquina de destino do deploy também tem de ter uma instalação pesada do TensorFlow para o correr. Isso é falso. O OpenCV executa a inferência de forma totalmente nativa. O módulo DNN é um inference engine de forward-pass dedicado e altamente otimizado. Não faz backpropagation. Não calcula gradientes. Não treina modelos. O seu único trabalho é pegar numa rede pré-treinada, ingerir uma imagem e dar-te uma resposta o mais rápido que o hardware permitir. O OpenCV oferece loaders nativos para formatos de modelo standard. Podes carregar modelos Caffe, protocol buffers do TensorFlow, configurações do Darknet e ficheiros ONNX diretamente na tua aplicação. Aqui está o ponto chave. Quando chamas uma função como readNet, o OpenCV faz o parse do formato do ficheiro externo e reconstrói o graph da rede neuronal usando as suas próprias implementações internas de layers em C++. As dependências externas são completamente removidas. A tua aplicação apenas faz link contra o OpenCV. Considera uma smart camera embedded em C++ desenhada para detetar peões na rua. Não queres um runtime de Python massivo a consumir a tua memória limitada, e certamente não queres gigabytes de bibliotecas de deep learning a ocupar espaço de armazenamento num edge device. Em vez disso, treinas o teu detetor de peões num cluster pesado de GPUs e exportas os weights finais para um ficheiro ONNX. Colocas esse único ficheiro no armazenamento da tua câmara. Na tua aplicação em C++, usas o módulo DNN para carregar o ficheiro ONNX. A seguir, capturas uma frame do sensor da câmara. As redes neuronais não conseguem processar imagens raw diretamente. Tens de converter essa frame num array estruturado de quatro dimensões, geralmente chamado de blob. O OpenCV fornece uma função dedicada para construir este blob, que trata de fazer o resize da imagem, trocar os canais de cor e aplicar a mean subtraction ou scaling específicos que o modelo original requer. Passas este blob preparado para a input layer da rede. Depois, chamas a função forward. O módulo DNN assume o controlo, passando os dados por cada convolutional layer, activation function e pooling layer. Como o OpenCV detém todo o execution graph neste ponto, pode otimizar agressivamente a matemática. Funde layers adjacentes sempre que possível para reduzir a memory bandwidth e utiliza automaticamente a aceleração nativa de hardware. A função forward termina e devolve um array final que contém as coordenadas da bounding box e os confidence scores para os peões que encontrou. Guarda os teus frameworks pesados no laboratório para treino, e usa o módulo DNN do OpenCV para um deploy leve e sem dependências em produção. Obrigado por estares aí. Espero que tenhas aprendido algo novo.

Olá, daqui fala o Alex da DEV STORIES DOT EU. OpenCV: Computer Vision Deep Dive, episódio 8 de 20. Antes dos sistemas modernos chegarem, os detetores de objetos tinham de fazer scan a uma única imagem dezenas de vezes a diferentes escalas só para encontrar um alvo. Era dolorosamente lento e computacionalmente pesado. Depois, uma nova arquitetura revolucionou a área ao fazer o trabalho todo numa única passagem matemática incrivelmente rápida. Hoje, vamos olhar para a linhagem YOLO: Fast Object Detection. Para perceberes porque é que o You Only Look Once, ou YOLO, mudou tudo, olha para o standard anterior. Os multi-stage pipelines mais antigos dependiam de region proposals. Geravam centenas de guesses sobre onde um objeto podia estar, faziam crop dessas áreas e, depois, corriam um image classifier sobre cada patch isolado. Estavas a correr networks complexas num loop. Era desconectado, difícil de otimizar e fundamentalmente lento. Alguns developers confundem o YOLO com standard image classification, que simplesmente atribui uma label a uma imagem completa. O YOLO faz muito mais. Faz output de bounding boxes espaciais precisas juntamente com class probabilities. Diz-te o que o objeto é e exatamente onde se encontra no espaço físico. O YOLO conseguiu isto ao reformular completamente o object detection. Em vez de um multi-stage pipeline, transformou a detection num único problema de regressão. A lógica vai diretamente dos raw pixels da imagem para as coordenadas das bounding boxes e class probabilities numa única etapa contínua. Aqui está o ponto chave. O YOLO pega na input image e divide-a numa grid uniforme. Se o centro de um objeto cair numa grid cell específica, essa mesma célula torna-se responsável por detetar o objeto. Cada grid cell prevê simultaneamente um número fixo de bounding boxes. Para cada box, faz output das coordenadas do centro, da largura e da altura. Também faz output de um confidence score, que diz ao sistema o grau de certeza de que a box realmente contém um objeto. Simultaneamente, a célula prevê as class probabilities. Está a calcular se o objeto é um carro, um camião ou uma pessoa. A network depois multiplica a box confidence pela class probability. Esta única operação matemática filtra todas as weak guesses em toda a grid, deixando apenas as bounding boxes de alta precisão. Imagina uma câmara de portagem numa autoestrada de alta velocidade. Os carros movem-se a 130 quilómetros por hora. Precisas de uma single-pass network para desenhar bounding boxes à volta das matrículas antes que o carro saia da frame. Um multi-stage detector iria ter lag, a fazer crop e a analisar patches isolados de asfalto enquanto o carro se afasta a alta velocidade. O YOLO processa a frame inteira de uma só vez. Aplica a grid, prevê a geometria e calcula as probabilidades numa única forward pass da neural network. Como o YOLO processa a imagem inteira num único sweep, percebe inerentemente o contexto global da cena. Os modelos mais antigos frequentemente confundiam patches de background com objetos porque só viam crops isolados. Ao enquadrar a detection como um único problema de regressão numa grid, o YOLO força a network a aprender representações generalizadas de objetos no seu contexto completo. Obrigado por passares uns minutos comigo. Até à próxima, fica bem.

Olá, daqui é o Alex da DEV STORIES DOT EU. OpenCV: Computer Vision Deep Dive, episódio 9 de 20. Durante uma década, o maior bottleneck na object detection em tempo real não era a neural network em si. Era o algoritmo pesado, feito à mão, usado para limpar as suas predictions confusas e sobrepostas. A solução para isto é o YOLOv26, especificamente a sua arquitetura de detection end-to-end NMS-free. Para perceberes esta mudança, tens de olhar para a forma como os detectors tradicionais terminam o seu trabalho. Eles dependem de Non-Maximum Suppression, ou NMS. O NMS é um passo de post-processing lento. Quando um model standard olha para um objeto, não faz a prediction de apenas uma bounding box. Faz a prediction de dezenas de bounding boxes sobrepostas à volta do mesmo objeto. O NMS entra em ação para dar um score a estas boxes, calcular o seu overlap, apagar os duplicados e deixar apenas o melhor fit. Este processo de limpeza é inerentemente sequencial e corre quase sempre no CPU. Imagina fazeres o deploy de um vision model num NVIDIA Jetson Orin para um robô de triagem de um armazém. Precisas de detetar centenas de pacotes em movimento rápido a 60 frames por segundo. A GPU processa as layers da neural network a uma velocidade incrível. Depois, a pipeline encrava. O CPU engasga-se a tentar correr o NMS em milhares de coordenadas raw de boxes sobrepostas. A tua frame rate cai a pique por causa da limpeza, não da inference. O YOLOv26 elimina este bottleneck por completo, fornecendo inference nativa NMS-free. Passas uma imagem para a network, e a network faz o output de exatamente uma box por objeto. O script de post-processing desaparece. Para tornar isto possível, a arquitetura do YOLOv26 remove um componente chamado Distribution Focal Loss, ou DFL. Em iterações anteriores, o DFL era usado para modelar as edges de uma bounding box como uma distribuição estatística contínua. Isto ajudava o model a adivinhar onde poderiam estar edges difusas ou obscurecidas, mas naturalmente encorajava a network a fazer o output de múltiplas guesses sobrepostas. Remover o DFL muda fundamentalmente o comportamento da network. Sem ele, o model é fortemente penalizado durante o training por fazer a prediction de mais do que uma box por objeto. Isto força a network a ser absolutamente decisiva. No entanto, remover o DFL cria um novo problema. Forçar a network a fazer o output de exatamente uma hard boundary torna o processo de training altamente instável. A loss landscape torna-se íngreme e caótica. Para resolver isto, o YOLOv26 integra o optimizer MuSGD na sua training pipeline. O MuSGD estabiliza o processo de learning ajustando dinamicamente o momentum com base na variância dos gradients. Quando o training atinge uma parte íngreme e caótica da loss landscape, o MuSGD atenua os weight updates para que o model não descarrile. Quando o caminho do gradient está estável, ele acelera. Este optimizer específico é o que permite que a arquitetura convirja numa única prediction rigorosa sem colapsar. O resultado no deployment é brutal. Quando exportas um model YOLOv26 para TensorRT para aquele robô de armazém, a pipeline inteira fica na GPU. A network processa a frame e faz diretamente o output das coordenadas finais do pacote. O CPU fica completamente livre para outras tarefas de controlo robótico. Aqui está o insight principal. O código mais rápido é o código que nunca corre. Ao transferir o peso da desduplicação de um script de post-processing em runtime de volta para a fase de otimização do training, o YOLOv26 desbloqueia uma eficiência de hardware que antes era impossível. É tudo por este episódio. Obrigado por ouvires, e continua a programar!

Olá, daqui fala o Alex da DEV STORIES DOT EU. OpenCV: Deep Dive em Visão Computacional, episódio 10 de 20. Os detetores de objetos tradicionais sofrem de uma forma grave de visão em túnel. Eles conseguem fazer o tracking perfeito de carros, pessoas e bicicletas, mas se lhes pedires para encontrarem uma chávena de café derramada, ficam completamente cegos, limitados à meia dúzia de classes para as quais foram explicitamente treinados no laboratório. Para resolver isto, não precisas de fazer label de milhares de chávenas derramadas. Precisas do YOLO-World e de Zero-Shot Detection com Open-Vocabulary. Considera um cenário específico. Geres o sistema de segurança de uma loja de retalho. Precisas de procurar nos live video feeds por uma garrafa Hydro Flask azul ou por um golden retriever perdido. Com um detetor standard de fixed-vocabulary, terias de parar o sistema, recolher imagens de golden retrievers na tua loja, desenhar manualmente bounding boxes à volta deles, fazer retrain ao modelo e fazer redeploy. Com o YOLO-World, só tens de escrever o text prompt no sistema. Ele encontra o objeto instantaneamente, em zero-shot. Este não é um modelo generativo text-to-image. Ele não cria imagens. É também muito diferente de simplesmente adicionar uma nova classe a um dataset existente. A deteção open-vocabulary depende de uma compreensão semântica profunda da linguagem. Mapeia diretamente text prompts linguísticos para bounding boxes visuais. O sistema recebe dois inputs: uma imagem e um conjunto de text prompts. Usa um vision backbone para extrair visual features da imagem. Simultaneamente, usa um text encoder para traduzir os teus text prompts em vetores matemáticos, chamados embeddings. É aqui que a coisa fica interessante. Estes dois fluxos de dados distintos têm de ser combinados. O YOLO-World lida com isto usando uma estrutura chamada RepVL-PAN. Que significa Reparameterizable Vision-Language Path Aggregation Network. A sigla é densa, mas a função é simples. O RepVL-PAN funde as features da imagem e do texto. Injeta o significado semântico do teu text prompt diretamente no visual feature map a múltiplas escalas. À medida que a rede processa os píxeis, é ativamente guiada pelo text embedding. O modelo aprende a fazer isto durante a sua fase inicial de treino através de um mecanismo chamado region-text contrastive loss. O modelo gera bounding boxes e extrai visual features dessas regiões. De seguida, compara essas visual features com os text embeddings. A contrastive loss penaliza o modelo severamente se as visual features de uma box não estiverem alinhadas com o text embedding correto. E recompensa o modelo quando coincidem. Isto força a rede a alinhar a sua representação visual precisamente com conceitos linguísticos em datasets massivos de pares imagem-texto. Aprende o que azul, hydroflask e garrafa significam como conceitos gerais, em vez de memorizar uma única categoria rígida. Quando corres o modelo em produção, o workflow é incrivelmente limpo. Primeiro, defines uma lista de vocabulário personalizada com os teus objetos-alvo. Passas essa lista pelo text encoder uma vez para gerar os teus text embeddings. Depois, passas os teus live video frames para o visual backbone. A arquitetura RepVL-PAN funde os dados visuais recebidos com os teus text embeddings pré-computados. Por fim, o modelo devolve bounding boxes e confidence scores com base na precisão com que as regiões visuais correspondem às tuas palavras. O verdadeiro poder do YOLO-World é desacoplar o detetor de um dataset rígido, permitindo-te usar linguagem natural como uma query executável em tempo real para o mundo físico. Obrigado por ouvires. Até à próxima!

Olá, daqui fala o Alex da DEV STORIES DOT EU. OpenCV: Deep Dive em Computer Vision, episódio 11 de 20. Para uma IA moderna, a tua identidade não é definida pelo formato do teu nariz ou pela distância entre os teus olhos. Em vez disso, a tua identidade é definida pela tua posição exata num espaço geométrico de 128 dimensões. Classic to Deep: A Evolução do Reconhecimento Facial explica como chegámos a este modelo. Primeiro, precisamos de separar dois conceitos que frequentemente se confundem. Face detection consiste em encontrar onde está um rosto numa imagem. Desenha uma bounding box à volta dos píxeis que se parecem com uma cabeça humana. Face recognition é identificar de quem é o rosto dentro dessa caixa. Este episódio concentra-se estritamente no reconhecimento. Durante décadas, a abordagem standard foi estatística. Se construíste um sistema no início dos anos 2000, provavelmente usaste uma técnica chamada Eigenfaces. As Eigenfaces baseiam-se num algoritmo chamado Principal Component Analysis, ou PCA. Começas com um dataset de imagens de rostos e fazes o flatten de cada imagem para um enorme array unidimensional de intensidades de píxeis raw. O PCA depois analisa todo este dataset para encontrar as direções de variância máxima. Encontra os padrões matemáticos subjacentes que diferenciam um rosto de outro. Quando visualizas estes principal components, eles parecem rostos fantasmagóricos e desfocados. Para reconhecer uma nova pessoa usando Eigenfaces, o sistema projeta a nova imagem raw neste subspace de principal components e calcula a distância até aos rostos conhecidos na base de dados. Isto funciona em ambientes altamente controlados, mas falha no mundo real. Uma sombra numa bochecha ou uma ligeira inclinação da cabeça alteram completamente os valores raw dos píxeis. O algoritmo vê um padrão de luz diferente e não te consegue reconhecer. Aqui está o insight principal. O deep learning descartou completamente a ideia de comparar a variância de píxeis raw. Os sistemas modernos usam Convolutional Neural Networks para gerar embeddings. Um embedding é um vetor denso de números que representa as features de alto nível de um rosto. Estas redes são treinadas com milhões de imagens usando penalizações matemáticas avançadas, como a ArcFace loss. Durante o treino, a rede é forçada a aproximar os vetores de embedding da mesma pessoa no espaço geométrico, enquanto afasta os vetores de pessoas diferentes. Imagina uma fechadura de segurança numa porta de escritório equipada com uma câmara. Quando um visitante se aproxima, o sistema deteta e faz crop do rosto, e depois passa essa imagem cropped pela neural network. A rede faz output de um único array de 128 números de floating-point. Esse é o vetor de embedding. O sistema depois calcula a distância euclidiana simples entre esse vetor do visitante e uma base de dados de vetores de funcionários autorizados. Não compara píxeis nem iluminação. Mede apenas a distância em linha reta entre dois pontos num espaço de 128 dimensões. Se a distância até ao vetor de um funcionário estiver abaixo de um threshold predefinido, a porta destranca. O sistema é robusto porque a rede aprendeu a ignorar sombras, óculos e ligeiras rotações de cabeça durante o treino. A evolução das Eigenfaces para deep embeddings é a mudança entre analisar como a luz incide num rosto e mapear a identidade conceptual de uma pessoa para um sistema de coordenadas mensurável. Se quiseres ajudar a manter o café a fluir e apoiar o podcast, podes procurar por DevStoriesEU no Patreon. Por este episódio é tudo. Obrigado por ouvires, e continua a desenvolver!

Olá, daqui é o Alex do DEV STORIES DOT EU. OpenCV: Computer Vision Deep Dive, episódio 12 de 20. Correr uma neural network pesada em cada frame de um vídeo de alta resolução é um desperdício computacional. Sistemas inteligentes detetam um objeto uma única vez e, a seguir, usam equações de física super rápidas para prever para onde ele se vai mover a seguir. Este é o domínio da Persistent Perception: algoritmos de Object Tracking. Imagina um sistema de monitorização de trânsito numa smart city. Precisas de contar os veículos únicos que passam por um cruzamento movimentado. Um modelo de object detection olha para um único momento congelado no tempo. Se correres pure detection num vídeo a trinta frames por segundo, um carro parado num semáforo vermelho durante dez segundos gera trezentas bounding boxes separadas e desconectadas. Sem lógica de tracking, o teu sistema conta trezentos carros. A detection encontra o objeto. O tracking associa matematicamente esse objeto ao seu passado ao longo do tempo. Para corrigir a câmara de trânsito, precisas de um multi-object tracker para manter um ID persistente para cada veículo. Os trackers modernos, como os implementados com Roboflow e OpenCV, dividem este problema em duas fases matemáticas distintas. A primeira fase é a prediction, e a segunda fase é a association. Quando um carro entra no feed da câmara, o detector inicial desenha uma bounding box. O tracker extrai as coordenadas do centro, a largura e a altura dessa box, e atribui-lhe um integer único, como o ID 42. Quando o próximo frame de vídeo chega, o tracker não faz logo o scan da imagem. Em vez disso, usa um modelo matemático, normalmente um Kalman Filter, para fazer state estimation. Ao avaliar como o ID 42 se moveu nos frames anteriores, o filter calcula a velocidade do veículo. De seguida, projeta essas propriedades físicas para prever exatamente onde a bounding box do ID 42 deverá estar no novo frame. Agora tens dois sets de dados para o frame atual. Tens as predicted boxes geradas pelo state estimator, e as boxes reais acabadas de encontrar pelo detector. Aqui está o insight principal. O tracker tem de reconciliar estes dois sets para manter os IDs consistentes sem analisar os píxeis reais novamente. Ele constrói uma matriz que compara cada predicted box com cada box recém-detetada. A métrica principal usada para esta comparação é a Intersection over Union, ou IoU. Isto mede o quanto a área geométrica prevista se sobrepõe à área geométrica detetada. Se a localização prevista para o ID 42 se sobrepuser bastante a uma bounding box recém-detetada, o sistema conclui que são o mesmo veículo. Um método de otimização, normalmente o Hungarian algorithm, resolve esta matriz para encontrar os emparelhamentos one-to-one mais lógicos em toda a interseção. A nova detection herda o ID 42, e o tracker atualiza o seu modelo de velocidade com as novas coordenadas confirmadas. Este loop de prediction e association lida inerentemente com obstruções visuais temporárias. Se um autocarro bloquear a visão do nosso carro durante alguns frames, o detector não o consegue encontrar. No entanto, o state estimator continua a prever o movimento do carro atrás do autocarro com base na sua última trajetória conhecida. O ID é mantido vivo num estado pending. Quando o carro emerge e o detector sinaliza uma bounding box que se alinha com a blind prediction contínua do tracker, o ID é instantaneamente re-linked. Ao fazer a ponte entre frames independentes, o multi-object tracking transforma um stream de imagens estáticas num mapa coeso de entidades em movimento. O tracking permite que a tua aplicação pare de perguntar o que está no frame, e comece a entender como as coisas se comportam ao longo do tempo. É tudo por este episódio. Obrigado por ouvires, e continua a programar!

Olá, daqui é o Alex da DEV STORIES DOT EU. OpenCV: Computer Vision Deep Dive, episódio 13 de 20. Passámos anos a treinar IA para desenhar bounding boxes à volta de objetos, mas as caixas são pouco precisas e cheias de ruído de fundo. O verdadeiro objetivo é pedir a um sistema, em linguagem natural, que pinte uma silhueta pixel-perfect à volta dos contornos exatos de um objeto, mesmo que nunca tenha sido explicitamente treinado nesse objeto antes. Isto leva-nos aos Vision-Language Models para segmentação. Os modelos tradicionais de segmentação de imagem são rígidos. Mapeiam pixels para uma lista fixa e fechada de categorias, como carro, pessoa ou árvore. Se quiseres segmentar algo fora dessa lista, tens de recolher um dataset enorme e treinar um modelo completamente novo. Os Vision-Language Models, ou VLMs, quebram esta limitação ao fundir large language models com visual encoders para fazer open-world segmentation. Dás input de uma imagem e de uma string de texto arbitrária, e o modelo devolve uma máscara densa, ao nível do pixel, de tudo o que descreveste. Imagina um drone agrícola automatizado a sobrevoar uma vinha. Um agricultor não quer caixas genéricas à volta das plantas. Precisa de um mapa preciso da infeção. Ele dá um prompt ao drone com a string de texto folhas de videira doentes. O VLM processa o feed visual e o text prompt em conjunto. Ele compreende o significado semântico de doentes e folhas de videira a partir do seu treino de linguagem, alinha esse significado com as visual features da imagem e gera o output de uma máscara. Esta máscara isola apenas a folhagem infetada até ao pixel exato, ignorando completamente folhas saudáveis, solo e sombras. Isto leva-nos à forma como o modelo realmente executa esta lógica. A abordagem de base é o text prompting de zero-prediction, frequentemente chamado de zero-shot. Neste modo, o modelo depende inteiramente do vasto dataset com o qual foi originalmente treinado. O text prompt passa por um text encoder, transformando-se numa representação matemática do teu pedido. Simultaneamente, a imagem passa por um vision encoder, dividindo a imagem numa grelha de visual features. O modelo depois calcula a similaridade entre a tua representação de texto e cada visual feature nessa grelha. Scores de similaridade altos tornam-se a tua máscara. O ponto crucial aqui é que os weights do modelo permanecem completamente frozen. Estás a extrair uma máscara de pixels complexa usando apenas o poder do language alignment. Aqui está o ponto-chave. O zero-prediction é poderoso, mas depende de um treino amplo e de propósito geral. Às vezes, o domínio visual é simplesmente demasiado especializado. Se uma doença específica da folha de videira for idêntica a uma deficiência nutricional inofensiva, o VLM frozen pode ter dificuldades em diferenciá-las puramente a partir de uma descrição de texto. É aqui que mudas para o visual fine-tuning. Em vez de mudares apenas o text prompt, atualizas os weights reais dos componentes visuais do modelo usando um pequeno dataset de imagens altamente específicas e mascaradas manualmente. Estás a ensinar explicitamente ao vision encoder a textura visual subtil da doença, em vez de confiares apenas na compreensão concetual ampla do language model sobre a palavra doença. O zero-prediction trata o VLM como um reasoning engine out-of-the-box guiado inteiramente por palavras, enquanto o visual fine-tuning o trata como uma foundation poderosa que tu alteras permanentemente para dominar um domínio visual específico. O verdadeiro poder da segmentação moderna já não está em recolher milhões de labeled pixels; está em saber quando guiar um modelo frozen com um text prompt inteligente, e quando gastar o compute para alterar os seus visual weights. É tudo por este episódio. Obrigado por ouvires, e continua a programar!

Olá, daqui fala o Alex da DEV STORIES DOT EU. OpenCV: Computer Vision Deep Dive, episódio 14 de 20. Enquanto os humanos pensam na cor como uma mistura de Red, Green e Blue, tentar programar um computador para fazer o tracking de um objeto usando RGB é um pesadelo no momento em que uma nuvem cobre o sol. A solução está na forma como representamos e combinamos pixels matematicamente. Hoje, vamos olhar para a Pixel Alchemy: Alpha Blending e Color Spaces. O problema central com o color space RGB é que ele acopla a informação de cor diretamente com a luminância. Se uma sombra cai sobre um objeto verde brilhante, os seus valores de pixel red, green e blue alteram-se significativamente. Para um algoritmo de thresholding standard, um objeto verde à sombra parece completamente diferente de um iluminado. Para corrigir isto, transformas a imagem de RGB para o color space HSV. HSV significa Hue, Saturation e Value. O Hue representa a cor base em si como um ângulo num cilindro de cores. A Saturation representa a intensidade dessa cor, e o Value representa o brilho. Ao isolar a informação de cor pura nesse único canal de Hue, o teu pipeline de computer vision torna-se altamente resistente a mudanças de iluminação. Podes configurar a tua lógica para procurar um tom específico de verde, e ela vai encontrá-lo quer a sala esteja bem iluminada ou escura. Esta robustez é crítica quando constróis algo como um sistema automatizado de green-screen para um broadcast. Queres fazer o blend perfeito de um mapa meteorológico dinâmico atrás de um pivô de notícias. Primeiro, pegas no feed da câmara e convertes para HSV. A seguir, defines um range de Hues verdes que correspondem ao fundo físico. Para cada pixel que caia dentro desse range de Hue verde, fazes output de um zero. Para tudo o resto, como o pivô, fazes output de um um. Isto cria uma binary mask. Esta mask atua como o teu alpha channel. Aqui está o insight principal. Os ouvintes costumam falar do alpha como se fosse uma cor, quase como um corante transparente. Não é. O alpha é puramente um peso numérico, um valor escalar entre zero e um que dita a opacidade numa equação de interpolação linear. O image blending é simplesmente aritmética pixel a pixel. Para combinar o pivô em foreground e o mapa meteorológico em background, usas uma equação específica. Para cada pixel, a cor final de output é igual ao pixel de foreground multiplicado pelo valor de alpha, mais o pixel de background multiplicado por um menos o valor de alpha. Pensa na matemática desse cenário de green-screen. Onde o pivô está, o alpha é um. O pixel de foreground é multiplicado por um, preservando o pivô perfeitamente. O pixel do mapa meteorológico de background é multiplicado por um menos um, que é zero. O mapa meteorológico desaparece exatamente nesse ponto. Por outro lado, onde está o green-screen, o alpha é zero. O pixel verde de foreground é multiplicado por zero, apagando completamente o ecrã físico. O pixel do mapa meteorológico de background é multiplicado por um menos zero, que é um, tornando o mapa meteorológico totalmente visível. Se quiseres uma borda suave e com anti-aliasing à volta do pivô, usas valores de alpha fracionários, como zero vírgula cinco, ao longo da fronteira. Isto faz a média dos pixels de foreground e background em conjunto, para evitar contornos duros e irregulares. A coisa mais útil a lembrar é que as imagens em memória são apenas matrizes, e a manipulação de pixels é apenas aritmética de matrizes; escolher o sistema de coordenadas certo, como o HSV, torna essa aritmética robusta e previsível, em vez de frágil. Obrigado por passares uns minutos comigo. Até à próxima, fica bem.

Olá, daqui é o Alex da DEV STORIES DOT EU. OpenCV: Computer Vision Deep Dive, episódio 15 de 20. Cada fotografia que alguma vez tiraste é uma mentira subtil, distorcida pelo vidro curvo da lente. Em robótica, essa ligeira distorção é a diferença entre apanhar uma bola e falhá-la completamente. Resolver essa discrepância exige Camera Calibration: Navigating Lens Distortion. Montas uma webcam fisheye barata e altamente distorcida num braço robótico. O sistema precisa de calcular a distância exata ao milímetro para agarrar com segurança uma caneca de café frágil. Se processares o raw video feed diretamente, a tua geometria vai estar completamente errada. A lente curva a luz que entra, o que significa que um pixel perto da borda da frame representa uma distância no mundo real drasticamente diferente de um pixel bem no centro. Se o robô confiar nesses raw pixels, vai esmagar a caneca. Temos de corrigir dois tipos principais de lens distortion. O primeiro é a radial distortion. A luz curva-se mais nas bordas de uma lente do que no seu centro. Isto faz com que linhas retas pareçam curvas, muitas vezes a abaular para fora como um barril ou a apertar para dentro. O segundo é a tangential distortion. Isto ocorre durante o fabrico, quando a lente não é montada perfeitamente paralela ao sensor de imagem, fazendo com que algumas áreas da imagem pareçam mais próximas do que outras. Para corrigir isto, precisamos de um ponto de referência geométrico conhecido. O standard da indústria é um simples checkerboard pattern plano impresso numa placa rígida. Um checkerboard fornece linhas de interseção nítidas e de alto contraste, tornando extremamente fácil para um algoritmo de deteção identificar os cantos internos exatos. Mais importante ainda, como fomos nós a imprimi-lo, sabemos as dimensões físicas exatas dos quadrados. Os developers frequentemente confundem intrinsic e extrinsic parameters ao lidar com dados de calibração. É fácil agrupá-los como meras camera settings. Aqui está a ideia principal. Os extrinsic parameters não descrevem o hardware da câmara de todo. Eles definem a localização física e a rotação da câmara no mundo 3D em relação à cena. Os intrinsic parameters, por outro lado, definem as propriedades físicas internas da lente e do sensor. Eles encapsulam a focal length e o optical center. A intrinsic matrix é exclusiva dessa câmara física específica e permanece constante, independentemente de para onde o braço robótico se mova. O processo de calibração funciona ao mapear pontos 3D conhecidos para pixels 2D observados. Primeiro, tiras uma dúzia ou mais de fotos do checkerboard de diferentes ângulos e distâncias usando a tua webcam. A seguir, corres uma função de corner detection nessas imagens. Crias uma lista de onde essas coordenadas de pixels 2D calham nas imagens, e emparelhas com um array das coordenadas 3D do mundo real desses mesmos cantos. As coordenadas 3D são apenas uma flat grid baseada no tamanho conhecido do teu quadrado, com o Z-axis definido a zero. Passas ambos os conjuntos de coordenadas para a função de camera calibration. O algoritmo calcula a transformação matemática necessária para mapear os pontos 3D nas tuas imagens 2D. Ele devolve a tua intrinsic camera matrix, os extrinsic rotation and translation vectors para cada imagem, e um conjunto de distortion coefficients. Estes coeficientes lidam com o radial e tangential warp. Assim que tiveres estes coeficientes e a intrinsic matrix, passas tudo para uma função de undistortion. Cada nova frame que o teu robô vê é matematicamente esticada e puxada de volta para uma verdadeira projeção retilínea. Linhas retas voltam a ser retas. O teu braço robótico agora pode medir milímetros exatos, estender-se e agarrar a caneca com segurança. A intrinsic matrix é a camada fundamental da geometria de computer vision, transformando um array de pixels distorcido num sistema de coordenadas matematicamente fiável. É tudo por este episódio. Obrigado por ouvires, e continua a construir!

Olá, daqui fala o Alex da DEV STORIES DOT EU. OpenCV: Computer Vision Deep Dive, episódio 16 de 20. Ao utilizar o mesmo truque biológico que os nossos dois olhos humanos usam para perceber o espaço tridimensional, um computador consegue calcular instantaneamente a distância até um objeto usando apenas geometria básica. Isto é Stereo Vision: Encontrar Profundidade com Duas Câmaras. Uma única dashcam grava uma projeção plana bidimensional do mundo. Perde completamente a informação de profundidade. Sem contexto, não consegue determinar com precisão se o carro da frente é pequeno e está perto, ou se é grande e está longe. Para construíres um Advanced Driver Assistance System, ou ADAS, que consiga realmente evitar uma colisão com um carro a travar, precisas da distância física real. Podes conseguir isto montando duas dashcams perfeitamente alinhadas. A distância física entre as lentes chama-se baseline. Para descobrires a distância até ao carro da frente, o sistema tem de encontrar exatamente o mesmo ponto nesse carro, tanto na imagem da câmara esquerda como na imagem da câmara direita. Procurar um ponto da imagem da esquerda em toda a imagem da direita é demasiado lento para condução em real-time. É aqui que entra a geometria epipolar. Ao transformares matematicamente, ou retificares, as duas imagens para que as lentes fiquem virtualmente alinhadas exatamente no mesmo plano, simplificas a pesquisa. Um farolim traseiro específico encontrado na linha duzentos da imagem da esquerda, agora só vai existir na linha duzentos da imagem da direita. Este caminho de pesquisa horizontal chama-se epipolar line. O sistema só tem de fazer o scan para a esquerda e para a direita ao longo de uma linha. Quando o sistema encontra o pixel correspondente ao longo dessa linha, mede a diferença nas suas posições horizontais. Esta diferença chama-se disparity. As pessoas costumam confundir disparity com depth, mas são inversamente proporcionais. Os objetos que mudam drasticamente de posição entre as duas vistas da câmara estão fisicamente mais próximos das lentes. Se o carro da frente a travar saltar quarenta pixels entre as vistas da esquerda e da direita, está muito perto. Se uma montanha no horizonte se deslocar apenas um pixel, está longe. Alta disparity significa baixa depth. O ponto chave é este. Tu não queres apenas a distância até um farolim traseiro. Queres um disparity map denso, ou seja, um valor de depth para quase todos os pixels da frame. O OpenCV lida com isto usando block matching, especificamente um algoritmo chamado Semi Global Block Matching. Em vez de tentar fazer o match de um único pixel ambíguo, pega num pequeno bloco de pixels da imagem da esquerda. Depois, desliza esse bloco ao longo da epipolar line horizontal na imagem da direita, comparando as intensidades dos pixels até encontrar o melhor match matemático. Faz isto em toda a imagem, aplicando penalizações para saltos repentinos na disparity, para manter o mapa resultante suave e fisicamente realista. Assim que tiveres o disparity map, convertê-lo em depth do mundo real é um cálculo único. Multiplicas a distância focal das câmaras pela distância física da baseline entre elas, e divides esse resultado pelo valor de disparity do pixel. A matemática é absoluta. Não estás a adivinhar com base em sombras ou no tamanho do objeto. Desde que as tuas câmaras permaneçam rigidamente calibradas e alinhadas, este cálculo geométrico dá-te a distância precisa até ao veículo da frente em milissegundos. A beleza de um stereo rig calibrado é que contorna a necessidade de identificar o que um objeto é antes de saber onde ele está. Ficamos por aqui neste episódio. Obrigado por ouvires, e continua a construir!

Olá, daqui é o Alex do DEV STORIES DOT EU. OpenCV: Computer Vision Deep Dive, episódio 17 de 20. Durante décadas, os engenheiros de computer vision acreditaram que precisavas de duas câmaras para calcular a distância real. Precisavas de visão estereoscópica para triangular pontos no espaço. Hoje, os modelos de IA conseguem perceber a distância física a partir de uma única imagem plana, interpretando sombras, textura e escala, tal como um pintor faz. Esta inovação chama-se Deep Monocular Metric Depth. As pessoas costumam confundir relative depth com metric depth. Relative depth é simplesmente saber que um sofá está à frente de uma parede. É uma ordenação de camadas visuais. Metric depth significa saber que o sofá está exatamente a 2,4 metros da lente da câmara. Até há pouco tempo, extrair medidas métricas absolutas de uma única imagem era considerado matematicamente impossível. Uma única imagem bidimensional perde toda a escala inerente. Um objeto pode ser pequeno e estar perto da lente, ou ser enorme e estar longe. Os modelos de deep learning contornam completamente o problema da geometria clássica. Em vez de triangular pontos entre duas lentes, redes como o DepthPro aprendem a partir de datasets massivos que contêm milhões de imagens emparelhadas com ground-truth 3D depth maps. Quando passas uma única imagem standard para a rede, ela não procura por stereo disparities. Ela avalia monocular cues. Analisa texture gradients, notando onde as superfícies parecem mais suaves quanto mais longe estão. Processa iluminação contextual, oclusão e a escala física conhecida de objetos reconhecíveis. O modelo constrói então uma previsão densa, pixel a pixel, da distância absoluta. Aqui está o ponto chave. As arquiteturas modernas conseguem isto sem conhecer as camera intrinsics da tua câmara. Não precisas de passar à rede a focal length, o field of view ou o tamanho do sensor da câmara que tirou a foto. A rede infere a focal length diretamente do conteúdo visual da própria imagem. Isto cria uma solução zero-shot. Entregas ao modelo uma foto tirada por qualquer lente aleatória e não calibrada, e ele gera um absolute depth map preciso. Pensa numa aplicação de augmented reality num smartphone standard. Um utilizador quer ver se uma nova mesa de jantar cabe na sua casa. Fica no meio de uma divisão vazia e aponta a sua única câmara traseira para o chão. A AR clássica exige que movas o telemóvel para gerar parallax e construir lentamente um spatial map. Com deep monocular metric depth, a aplicação processa uma única frame estática instantaneamente. A neural network calcula o volume e as dimensões exatas do espaço do chão em milissegundos. A aplicação renderiza então uma mesa virtual no camera feed, perfeitamente escalada para o mundo real, assente no chão na depth exata. Internamente, conseguir isto requer receptive fields massivos na arquitetura da neural network. O modelo usa Vision Transformers para capturar o contexto global. Olha para a imagem inteira de uma só vez para entender a geometria geral da divisão. Combina depois esta visão ampla com processamento local de alta resolução. Esta abordagem dupla permite que o modelo produza depth boundaries nítidas à volta de edges complexas, como as pernas finas de uma cadeira ou as folhas de uma planta. Evita completamente os artefactos desfocados e de bleeding edge que afetavam os modelos anteriores de depth estimation. A mudança fundamental é a capacidade de extrair medidas espaciais absolutas de uma única image frame, completamente não calibrada. É tudo por este episódio. Obrigado por ouvires, e continua a desenvolver!

Olá, daqui fala o Alex da DEV STORIES DOT EU. OpenCV: Deep Dive em Computer Vision, episódio 18 de 20. Os deploys de inteligência artificial mais impressionantes da atualidade não estão a correr em enormes server farms com ar condicionado. Estão a correr em chips de silício de dois dólares, alimentados por uma pilha de relógio, no meio do nada. Mover redes neuronais complexas para estes dispositivos minúsculos exige uma abordagem completamente diferente, o que nos leva a AI no Edge: Fazer Deploy para Microcontroladores. Os microcontroladores são incrivelmente limitados. Estamos a falar de dispositivos com kilobytes de RAM, alguns megabytes de armazenamento flash e limites de energia rigorosos. Os modelos standard de computer vision usam números floating-point de 32 bits para os seus weights e activations. Um modelo típico precisa de centenas de megabytes apenas para ser carregado na memória. Se tentares correr isso num microcontrolador básico, ele vai crashar imediatamente por falta de memória. Imagina uma câmara de vida selvagem alimentada a bateria e recarregada por energia solar, instalada no meio de uma floresta. A sua função é detetar um leopardo-das-neves, uma espécie ameaçada. Se a câmara acordar o seu transmissor de rádio para enviar cada foto disparada por movimento para um cloud server para análise, a bateria esgota-se num dia. O dispositivo tem de correr o object detector localmente. Tem de processar o video feed diretamente no silício e apenas acordar o transmissor, que consome muita energia, para enviar um alerta quando identificar especificamente o leopardo. Para encaixar um vision model num chip tão pequeno, tens de o reduzir agressivamente. Fazes isso principalmente através de duas técnicas: pruning e quantization. O pruning é exatamente o que parece. Analisas a neural network treinada e removes as ligações que têm o menor impacto na prediction final. Estás essencialmente a cortar o peso morto da network architecture para que ocorram menos cálculos por frame. A segunda técnica, a quantization, é onde acontece a verdadeira redução de tamanho. Esta é a parte que importa. A quantization reduz a precisão numérica do modelo. Em vez de armazenar cada weight como um float de 32 bits, mapeias esses valores para um integer de 8 bits, geralmente chamado de INT8 conversion. O principal trade-off aqui é simples. Estás a descartar intencionalmente a precisão numérica. Para fazer isto corretamente, corres um calibration dataset pelo modelo para rastrear os valores mínimo e máximo dos weights. A seguir, fazes scale a esse range de floating-point para caber exatamente dentro dos 256 valores possíveis de um integer de 8 bits. Isto troca uma pequena fração da accuracy do modelo por uma redução enorme no memory footprint e no execution time. Um modelo INT8 ocupa exatamente um quarto do storage de um modelo de 32 bits. Além disso, os microcontroladores lidam com integer math muito mais depressa e com significativamente menos energia do que com floating-point math. Muitos microcontroladores de baixo consumo não possuem de todo hardware dedicado para floating-point operations. Isto significa que a floating-point math tem de ser emulada em software, o que é incrivelmente lento e drena a bateria. Com um modelo INT8 agressivamente quantized, quando a câmara de vida selvagem captura uma imagem, a neural network multiplica e soma pequenos valores integer em single hardware clock cycles. O microcontrolador consegue avaliar a imagem em milissegundos, confirmar que não há nenhum leopardo-das-neves e voltar instantaneamente para um estado de deep sleep para conservar energia. O processo de deploy propriamente dito começa num computador desktop normal. Treinas o teu modelo num dataset standard. Depois de treinado, corres um converter script que aplica o pruning e a INT8 quantization. O output é geralmente um flat byte array exportado como um bloco de código de C header contendo os weights comprimidos. Compilas isto diretamente no firmware do teu microcontrolador, juntamente com os drivers da tua câmara. Não há sistema operativo nem file system para carregar modelos em runtime. É pura lógica compilada a executar diretamente no bare metal. A limitação extrema neste ambiente muda a forma como avalias o sucesso. Num microcontrolador, a tua métrica principal já não é a peak precision, é o número de inferences precisas que consegues correr por milijoule de energia da bateria. Se quiseres ajudar a manter o programa a andar, podes apoiar-nos ao pesquisar por DevStoriesEU no Patreon. É tudo por este episódio. Obrigado por ouvires, e continua a desenvolver!

Olá, daqui fala o Alex da DEV STORIES DOT EU. OpenCV: Computer Vision Deep Dive, episódio 19 de 20. Os videojogos tradicionais renderizam mundos ao desenhar milhões de pequenos triângulos planos. A mais recente revolução em computer vision descarta os triângulos por completo, e renderiza a realidade como uma densa cloud de milhões de blobs matemáticos brilhantes e sobrepostos. Isto é Radiance Fields: 3D Gaussian Splatting. Um agente imobiliário caminha por uma casa a gravar um vídeo normal com um smartphone. Precisas de processar esse vídeo raw num virtual tour 3D totalmente navegável e fotorrealista, com reflexos e iluminação dinâmicos. Durante alguns anos, a abordagem standard foram os Neural Radiance Fields, ou NeRFs. Um NeRF mapeia o espaço usando uma neural network implícita. Para gerar uma imagem, dispara um raio matemático através da cena e faz uma query à neural network em centenas de pontos ao longo desse raio para perguntar que cor e densidade existem ali. Produz resultados belíssimos, mas fazer queries a uma deep neural network para milhões de píxeis é extremamente lento. O 3D Gaussian Splatting abandona a neural network implícita. Em vez disso, utiliza uma estrutura explícita semelhante a uma point cloud. O pipeline começa com um algoritmo standard de structure-from-motion a analisar o vídeo do smartphone para fazer o tracking da posição da câmara e construir uma point cloud 3D esparsa da casa. O algoritmo depois substitui cada ponto dessa cloud por um 3D Gaussian. Podes imaginar um 3D Gaussian como um elipsoide colorido e semitransparente. Cada Gaussian possui um conjunto específico de parâmetros. Tem uma coordenada central no espaço 3D. Tem uma covariance matrix, que dita a sua escala e rotação, esticando-o num disco plano ou num charuto comprido, dependendo da geometria que representa. Tem um valor de opacidade. Por fim, armazena dados de cor usando Spherical Harmonics. Aqui está o insight principal. Os Spherical Harmonics são funções matemáticas que fazem o encode da cor direcionalmente. Quando olhas para o Gaussian de um ângulo, ele pode refletir uma janela brilhante. De outro ângulo, mostra a textura escura de um soalho. É isto que dá ao virtual tour final a sua iluminação fotorrealista e view-dependent. A point cloud inicial é desorganizada, por isso o sistema entra num loop de otimização. Ele projeta, ou faz splat, destes 3D Gaussians numa view de câmara 2D para renderizar uma imagem. Subtrai esta imagem renderizada da fotografia real tirada pelo agente imobiliário para calcular o erro. O algoritmo depois usa esse erro para atualizar os parâmetros dos Gaussians. Durante esta otimização, o sistema gere ativamente a população de Gaussians. Se um blob cresce demais e se sobrepõe a demasiados detalhes, o algoritmo divide-o em pedaços menores. Se uma área com texturas complexas precisa de mais resolução, o algoritmo clona Gaussians existentes para aumentar a densidade. Se um blob se torna completamente transparente ou irrelevante, o sistema elimina-o. Como a cena final é composta inteiramente por data points explícitos, renderizá-la é excecionalmente rápido. O hardware gráfico simplesmente ordena os elipsoides de trás para a frente e faz blend das suas cores para formar a imagem final. O grande breakthrough do 3D Gaussian Splatting é provar que uma cloud caótica de blobs matemáticos explícitos consegue capturar luz e geometria complexas muito mais rapidamente do que uma neural network densa. Obrigado por ouvirem. Fiquem bem, pessoal.

Olá, daqui fala o Alex da DEV STORIES DOT EU. OpenCV: Deep Dive em Computer Vision, episódio 20 de 20. Durante décadas, os algoritmos de computer vision foram inteiramente passivos. Conseguiam desenhar uma bounding box à volta de uma chávena numa mesa, mas ficavam-se por aí. Hoje, o sistema não vê apenas a chávena — usa esses dados visuais para chegar até ela e agarrá-la. A ponte entre ver e fazer é o Vision-Action Loop, impulsionado por Agentic AI. Antes de irmos à mecânica da coisa, temos de traçar uma linha bem definida entre duas tecnologias que parecem semelhantes, mas fazem trabalhos completamente diferentes. Um Vision-Language Model standard, ou VLM, é descritivo. Dás-lhe um screenshot, e ele faz output de texto a dizer-te o que está no ecrã. Um modelo Vision-Language-Action, ou VLA, é executivo. Dás a um VLA um screenshot e um objetivo, e ele faz output de comandos executáveis. Ele não descreve apenas a user interface; interage ativamente com ela. A Agentic AI transforma um vision pipeline num órgão sensorial para um engine de tomada de decisão. Isto opera num ciclo contínuo de perceção, raciocínio e ação. Primeiro, o sistema faz uma observação visual do seu ambiente atual. Isto pode ser o camera feed de um robô ou uma captura em tempo real do desktop de um computador. A seguir, o agente processa este estado visual juntamente com um prompt ou objetivo específico. Analisa as relações espaciais, lê texto e identifica elementos interativos. Quando o modelo identifica um elemento, mapeia a compreensão semântica — saber que um retângulo verde específico é um botão de submit — para um espaço de coordenadas geométricas. Finalmente, em vez de devolver uma descrição, o modelo gera um action payload. Este é muitas vezes um comando estruturado que contém coordenadas exatas do ecrã, um ajuste de motor de hardware ou uma API call. Assim que a ação é executada, o ambiente muda. O agente faz uma nova observação visual, verifica se a ação anterior teve sucesso e calcula o próximo passo. Aqui está o insight principal. Os dados visuais já não são um beco sem saída; são o mecanismo de grounding para o uso autónomo de ferramentas. Vamos analisar um cenário concreto de um assistente digital de contabilidade automatizado. O objetivo é autorizar um pagamento. O agente começa por capturar o ecrã. O vision model processa uma fatura em PDF digitalizada, e extrai o nome do fornecedor e o valor total. O reasoning engine sabe que precisa de fazer log destes dados. Gera uma ação para mover o rato até ao ícone do software de contabilidade na taskbar e clicar nele. O ecrã atualiza. O agente faz outra observação visual para verificar se a aplicação está aberta. Faz scan da nova interface, localiza o campo de autorização de pagamento, mapeia a localização visual para as coordenadas do ecrã, digita o valor e clica no botão de submit. O vision pipeline envia constantemente atualizações de estado de volta para o agente, para que ele saiba exatamente quando executar a próxima ação e, mais importante, quando parar. A computer vision evoluiu de uma ferramenta de análise standalone para a camada sensorial de sistemas autónomos. Se o teu pipeline apenas analisa uma imagem e para, estás a utilizar apenas metade da tecnologia. Como este é o nosso episódio final, encorajo-te a explorares a documentação oficial dos modelos VLA, a tentares construir um feedback loop básico hands-on, ou a visitares devstories dot eu para sugerires tópicos para a nossa próxima série. É tudo por este episódio. Obrigado por ouvires, e continua a construir!