OpenCV: Computer Vision Deep Dive

Bonjour, c'est Alex de DEV STORIES DOT EU. OpenCV : Computer Vision Deep Dive, épisode 1 sur 20. La plupart des développeurs considèrent une image comme un fichier compressé stocké sur un disque dur. Mais dès que tu passes ce fichier à une library de Computer Vision, il abandonne son format de fichier et devient une immense grille de nombres qui n'attend plus que des calculs matriciels. Comprendre exactement comment ces nombres sont structurés, c'est l'âme d'OpenCV : les pixels en tant que matrices. Quand tu charges une image avec OpenCV, la fonction read récupère le fichier sur le disque et le convertit instantanément en un array NumPy multidimensionnel. C'est ça le plus important. En Python, OpenCV n'utilise pas d'objet image propriétaire. Il repose entièrement sur NumPy. Vu qu'une image est juste un array standard, chaque opération mathématique que tu peux appliquer à un array peut être appliquée directement à ton image. Regardons la structure de cet array. Si tu charges une image couleur standard, tu obtiens une matrice en trois dimensions. La première dimension, c'est la hauteur, qui représente le nombre de lignes. La deuxième dimension, c'est la largeur, qui représente le nombre de colonnes. La troisième dimension contient les channels de couleur. Si tu as une image de 800 pixels de large et 600 pixels de haut, la shape de ton array sera de 600 lignes, 800 colonnes et 3 channels. Chaque intersection d'une ligne et d'une colonne contient un pixel. Et pour les images standards, chaque channel de couleur à l'intérieur de ce pixel contient une valeur integer allant de 0 à 255, qui représente l'intensité de cette couleur. Il y a un piège très classique ici. La plupart des logiciels graphiques et des navigateurs web représentent les couleurs au format Red, Green, Blue, connu sous le nom de RGB. Pas OpenCV. Pour des raisons historiques qui remontent aux premiers hardwares de caméras, OpenCV stocke les channels de couleur dans l'ordre inverse : Blue, Green, Red, ou BGR. Si tu essaies d'afficher une image OpenCV dans une autre library sans inverser ces channels, tes rouges paraîtront bleus et tes bleus paraîtront rouges. Ce n'est pas un bug dans ton code. Rappelle-toi juste que la valeur au channel d'index 0 est le bleu, l'index 1 est le vert, et l'index 2 est le rouge. Vu que les images sont juste des arrays NumPy, les manipuler repose sur la syntaxe Python standard. Tu n'as pas besoin de fonctions OpenCV spécialisées pour crop une image. Tu as juste à slice l'array. Imagine que tu as un flux de caméra de sécurité en haute définition, et que tu t'intéresses uniquement à une région de 100 par 100 pixels où se trouve une porte. Tu extrais une Region of Interest, ou ROI, en utilisant le slicing d'array standard. Tu spécifies la ligne de départ et la ligne de fin, suivies de la colonne de départ et de la colonne de fin. En termes mathématiques, tu slice l'axe Y en premier, puis l'axe X. Ça te retourne instantanément un array NumPy plus petit qui contient uniquement les données des pixels de la porte. Une fois que tu as appliqué un slice à ton array ou modifié ses pixels, tu veux généralement sauvegarder le résultat. OpenCV gère ça avec une simple fonction write. Tu fournis un chemin de fichier de destination et tu lui passes ton array NumPy. OpenCV lit l'extension de fichier que tu as demandée, comme point JPG, et gère automatiquement la compression complexe nécessaire pour transformer cette matrice de nombres à nouveau en un fichier image standard. La chose la plus utile que tu puisses faire quand tu apprends la Computer Vision, c'est d'arrêter de voir les images comme des toiles visuelles, et de commencer à les traiter comme des systèmes de coordonnées remplis de données numériques brutes. Si tu aimes ces deep dives, tu peux soutenir l'émission en cherchant DevStoriesEU sur Patreon. C'est tout pour cet épisode. Merci d'avoir écouté, et continue à développer !

Salut, c'est Alex de DEV STORIES DOT EU. OpenCV : Computer Vision Deep Dive, épisode 2 sur 20. Appliquer un filtre de blur à une photo donne l'impression d'un effet visuel complexe, mais d'un point de vue informatique, ça consiste simplement à remplacer chaque pixel par la moyenne mathématique de ses voisins immédiats. C'est ce mécanisme qu'on va voir aujourd'hui : les Convolution Kernels : Filtering et Edge Detection. Quand tu entends le mot convolution, tu penses peut-être tout de suite aux Convolutional Neural Networks. Il faut séparer ces concepts tout de suite. Dans un réseau de deep learning, un modèle détermine les valeurs à l'intérieur de ses filtres pendant un processus de training massif. Aujourd'hui, on parle de convolution 2D classique. Ces kernels sont des matrices mathématiques fixes et hardcodées qui existent depuis des décennies. Ils n'apprennent pas. Ils font juste des calculs. Un kernel, c'est simplement une toute petite grille de nombres. Une taille classique, c'est un carré de trois par trois. La convolution, c'est le fait de prendre cette petite grille et de la faire glisser sur toute ton image, un pixel à la fois. À chaque arrêt, tu alignes le centre de ton kernel avec un pixel précis de l'image. Ensuite, tu multiplies chaque nombre de ton kernel par la valeur du pixel de l'image juste en dessous. Tu additionnes ces neuf résultats, et cette somme finale devient la nouvelle valeur unique pour le pixel central de ton image en output. Tu fais ça pour chaque pixel. Les nombres que tu mets dans cette petite grille dictent exactement ce qui arrive à toute l'image. Si tu remplis le kernel avec des fractions dont la somme fait un, tu obtiens un blur. Un Gaussian blur est un type spécifique de kernel où la valeur centrale a le plus de poids, et les valeurs diminuent au fur et à mesure que tu vas vers les bords de la grille. Ça crée une moyenne pondérée localisée. C'est ça qui est important. On n'applique pas un blur sur les images pour faire artistique. On le fait pour détruire le noise. Le capteur d'une caméra enregistre de minuscules fluctuations aléatoires de lumière. Si tu essaies d'analyser la structure rigide d'une image avec ce static, tes algorithmes vont planter. Le Gaussian blur lisse ce noise erratique tout en préservant les formes générales. Une fois que le noise a disparu, tu veux généralement trouver les vrais objets dans la frame. Prends l'exemple d'un système de caméra conçu pour lire les plaques d'immatriculation. Avant de pouvoir lire les caractères, tu dois isoler la plaque rectangulaire sur le pare-chocs de la voiture. Pour un ordinateur, un edge, c'est simplement une transition soudaine de pixels sombres à des pixels clairs, ou vice versa. Pour trouver ces transitions nettes, on remplace la matrice de blur par une matrice d'Edge Detection, comme le kernel de Sobel. Un kernel de Sobel vertical est conçu spécifiquement pour trouver les edges verticaux. C'est une grille de trois par trois qui contient une colonne de nombres négatifs à gauche, une colonne de zéros au milieu, et une colonne de nombres positifs à droite. Quand ce kernel glisse sur une zone de couleur unie, comme un pare-chocs gris lisse, les nombres négatifs et positifs se multiplient par la même valeur de gris. Ils s'annulent. La somme est zéro, ce qui se traduit par un pixel noir dans l'image en output. Les zones unies disparaissent. Mais quand le kernel atterrit pile sur la limite verticale entre ce pare-chocs sombre et une plaque d'immatriculation bien blanche, les maths changent. Les nombres négatifs se multiplient avec les pixels sombres, ce qui produit une petite valeur. Les nombres positifs se multiplient avec les pixels très blancs, ce qui produit une valeur énorme. Ils ne s'annulent plus. La somme finale est un nombre positif très élevé, ce qui crée un pixel blanc éclatant dans ton image en output, exactement là où se trouve l'edge. En exécutant cette opération sur toute l'image, le pare-chocs disparaît dans le noir, laissant derrière lui un contour blanc très net de la plaque d'immatriculation. Tu viens de transformer des données de couleur brutes en géométrie structurelle. Ce qu'il faut retenir, c'est qu'un convolution kernel classique n'est rien d'autre qu'une règle mathématique locale appliquée globalement, qui dicte comment chaque pixel doit réagir à ses voisins immédiats. Merci d'avoir passé quelques minutes avec moi. À la prochaine, à plus.

Salut, c'est Alex de DEV STORIES DOT EU. OpenCV : Computer Vision Deep Dive, épisode 3 sur 20. Tu as besoin du contour exact d'un objet sur un tapis roulant. Ton premier réflexe serait peut-être de charger un énorme neural network de semantic segmentation. Mais calculer ce contour avec de la géométrie standard est des ordres de grandeur plus rapide, moins lourd en calcul, et ne demande pas de GPU. C'est exactement ce que te permet de faire Drawing Boundaries: Contours and Geometry. Une erreur classique, c'est de considérer les edges et les contours comme la même chose. Ce sont des data structures fondamentalement différentes. Un edge detector te donne une map binaire de pixels blancs désorganisés et déconnectés, là où l'intensité change. Un contour est une courbe mathématique continue qui relie tous les points consécutifs le long d'une boundary avec la même couleur ou intensité. Les edges sont juste des points isolés sur un écran. Les contours forment des figures fermées et mesurables. Imagine un système de contrôle qualité en usine qui inspecte un engrenage en métal. Tu as déjà converti le flux de la caméra en une image binaire noir et blanc. L'engrenage est blanc uni sur un fond noir. Pour obtenir la boundary mathématique de cet engrenage, tu passes cette image à la fonction de contour finding. OpenCV fait ça en scannant l'image ligne par ligne. Quand l'algorithme tombe sur une boundary entre des pixels noirs et blancs, il trace le long de cette boundary et enregistre les coordonnées dans un array. Pour économiser de la mémoire, il compresse l'output, en stockant uniquement les points de départ et de fin des segments droits au lieu de chaque pixel individuel. Ce process capture aussi les relations spatiales. L'engrenage a un edge extérieur, mais il a aussi un trou au milieu pour l'axe. L'algorithme de contour construit une hiérarchie. Il enregistre la boundary extérieure comme un parent contour, et le trou intérieur comme un child contour. Ça te permet d'analyser ou d'ignorer sélectivement les formes internes selon tes besoins. Maintenant que tu as l'engrenage sous forme de boundary connectée, tu peux extraire sa géométrie. Tu peux calculer la contour area. C'est un calcul mathématique de l'aire totale en pixels à l'intérieur de la courbe fermée. Un engrenage parfaitement fabriqué aura une aire spécifique et connue. Si un engrenage a une dent cassée, l'aire de son contour passe en dessous de ton threshold acceptable. Tu signales le défaut instantanément. Parfois, tu as besoin de comprendre la forme globale d'un objet tout en ignorant ses détails complexes. C'est là que ça devient intéressant. Tu peux calculer le convex hull d'un contour. Vois le convex hull comme un élastique tendu fermement autour de l'extérieur de ton objet. Pour l'engrenage, le contour standard trace parfaitement chaque dent et chaque creux. Le convex hull ignore les creux. Il s'étire tout droit de la pointe d'une dent à la pointe de la suivante. En comparant le contour original au convex hull, tu identifies les anomalies structurelles. Les espaces vides entre l'élastique et le contour réel de l'engrenage s'appellent des convexity defects. Mesurer ces defects t'indique exactement quelle est la profondeur des dents de l'engrenage et si certaines sont usées, tout ça par pur calcul géométrique. Les contours font le pont entre l'image processing de bas niveau et l'analyse d'objet de haut niveau, en transformant une grille de pixels bêtes en formes géométriques structurées que tu peux strictement valider. C'est tout pour cet épisode. Merci d'avoir écouté, et keep building !

Salut, c'est Alex de DEV STORIES DOT EU. OpenCV : Deep Dive en Computer Vision, épisode 4 sur 20. Les visual trackers les plus robustes ne mémorisent pas l'apparence complète d'un objet. Ils se verrouillent plutôt sur des coins mathématiquement distincts et des gradients à fort contraste qui restent constants peu importe l'éclairage. Réussir ça, c'est le domaine des Feature Detectors : les Keypoints et le Neural Matching. Avant de regarder la mécanique, il faut séparer ça de l'object detection. L'object detection applique des catégories sémantiques larges. Elle dessine une bounding box et te dit qu'un bâtiment est dans le cadre. Le feature matching est strictement structurel. Il ne sait pas ce qu'est un bâtiment. Il trouve une intersection spécifique et identique de deux briques sur deux images différentes. Imagine que tu codes une application de panorama stitching. Tu as deux photos d'un mur de briques qui se chevauchent, prises sous des angles légèrement différents. Pour les stitcher de manière invisible, le software doit aligner mathématiquement l'overlap. Il fait ça en trouvant des features locales distinctes dans la première image, en retrouvant ces mêmes features dans la deuxième image, et en les pairant. La première étape, c'est la détection. Le système scanne l'image à la recherche de keypoints. Un keypoint, c'est un emplacement de pixel spécifique qui se démarque de son environnement. Les zones plates comme un ciel dégagé ou un mur blanc vide sont inutiles parce que chaque pixel a exactement la même apparence. L'algorithme traque les textures fortes, les coins nets et les lignes qui s'intersectent. Traditionnellement, les algorithmes s'appuyaient sur des formules mathématiques hand-crafted pour trouver ces bords. Les approches modernes utilisent des convolutional neural networks. Tu passes l'image au réseau, et il te sort une probability map qui indique la probabilité qu'un pixel donné soit un keypoint stable. Une fois que le réseau identifie un point, comme le coin d'un cadre de fenêtre spécifique, il a besoin d'un moyen de le décrire. C'est le descriptor. Le neural network génère un vecteur à haute dimension, un embedding, qui capture le pattern visuel des pixels qui entourent immédiatement ce keypoint. Un descriptor robuste reste mathématiquement similaire même si la deuxième photo est prise à une échelle différente, avec une rotation, ou sous des conditions d'éclairage différentes. Voici l'idée clé. Avoir une liste de points et leurs descriptions n'est que la moitié du puzzle. Tu dois encore matcher les points de ta première image avec les points de ta deuxième image. Historiquement, tu calculais juste la distance entre les vecteurs et tu prenais le plus proche. Mais les patterns répétés, comme des centaines de briques identiques sur un mur, causent de graves erreurs de mismatching. C'est là que les modèles de neural matching entrent en jeu. Au lieu d'évaluer un keypoint de manière isolée, un neural matcher regarde les relations spatiales entre tous les keypoints en même temps. Il apprend en gros qu'un coin spécifique peut ressembler à cinquante autres coins de briques, mais que c'est le seul situé exactement entre un cadre de fenêtre et une ombre spécifique. En passant les descriptors et leurs positions géométriques à travers des layers de self-attention, le système rejette les faux positifs et output des paires de matching ultra précises. Dans un pipeline typique, tu passes d'abord les deux images à travers un réseau de feature extraction. Ça te retourne deux sets de keypoints et deux sets de descriptors. Ensuite, tu passes les deux sets de données dans un matching network. Le matching network calcule les similarités contextuelles et retourne une liste de paires valides, en jetant les keypoints qui n'existent pas dans les deux frames. Tu utilises ensuite ces paires de coordonnées matchées pour calculer la transformation géométrique nécessaire pour warper et stitcher les deux photos parfaitement ensemble. Le passage des formules hand-crafted aux neural embeddings signifie que le feature matching peut maintenant gérer des variations extrêmes d'éclairage et des points de vue extrêmes qui cassaient complètement les anciens algorithmes. Merci d'avoir écouté, happy coding tout le monde !

Salut, ici Alex de DEV STORIES DOT EU. OpenCV : Deep Dive en Computer Vision, épisode 5 sur 20. Les apps de document scanner sur mobile ont l'air d'être de la pure magie d'IA complexe. Tu pointes ton téléphone vers un bout de papier, et instantanément, il s'aplatit pour devenir un document numérique parfait. Mais le moteur principal derrière tout ça n'est pas un neural network qui prédit les détails manquants. Il repose sur une astuce mathématique vieille de quinze ans, qui utilise une transformation matrix de trois par trois. Cet épisode parle de géométrie dans le monde réel : construire un document scanner. Imagine un ticket de caisse froissé posé sur la table d'un restaurant. Tu prends une photo avec un angle incliné. À cause de la perspective, le ticket ressemble à un trapèze déformé, entouré par la texture de la table. Pour extraire le document, la première étape, c'est de l'isoler du background. Tu convertis l'image en grayscale et tu appliques un léger blur. Ça adoucit les détails bruités, comme les plis du papier ou le grain du bois de la table, tout en gardant les boundaries principales intactes. Ensuite, tu lances un Canny edge detection. Ça fait ressortir les changements brusques d'intensité, et ça te laisse avec un outline lumineux du ticket sur un background sombre. Ensuite, tu dois transformer ces edges isolés en une forme définie. Tu trouves les contours dans la edge map. L'image va contenir beaucoup de contours, et la plupart sont juste des petits artefacts inutiles. Tu les tries par area, en ne gardant que les plus grands. Ensuite, tu itères sur ces grands contours et tu approximes leur forme polygonale. Tu cherches un indice structurel précis. Si tu trouves une forme qui peut être approximée avec exactement quatre points, tu as trouvé la boundary de ton ticket. Ces quatre points définissent les coins de ton document dans la photo originale en biais. Maintenant, on arrive à l'étape critique du flattening du document. Une idée reçue très courante, c'est que ce process utilise l'intelligence artificielle pour deviner ou halluciner des données manquantes. Ce n'est pas le cas. Une perspective transform est un pur warping mathématique des coordonnées de pixels d'un plan à un autre. Pour exécuter ça, tu as besoin de deux sets de quatre points. Le premier set, ce sont les quatre coins que tu viens de trouver sur le ticket. Le deuxième set représente l'endroit où ces coins devraient être dans l'image finale parfaite. Pour obtenir ce deuxième set, tu calcules la width maximale et la height maximale du ticket déformé en utilisant la formule de distance entre les points d'origine. Ensuite, tu définis un nouveau rectangle parfait qui commence à la coordonnée zéro-zéro, et qui s'étend jusqu'à cette width et height exactes. Avec ces deux sets de points, tu calcules une perspective transformation matrix. Cette matrix définit exactement de combien chaque pixel doit se décaler, s'étirer ou se compresser pour passer de la forme de trapèze incliné à la forme de rectangle plat. Enfin, tu appliques cette matrix à l'image haute résolution d'origine. Les maths tirent littéralement les quatre coins vers l'extérieur et les mettent au carré, en appliquant un warping à tous les pixels intérieurs avec eux. Le résultat, c'est une image en deux dimensions parfaitement vue de haut de ton ticket, prête pour le processing. Voici l'idée clé. Tu n'as pas besoin de deep learning pour corriger la perspective. Tant que tu peux isoler quatre coins, une simple opération de matrix va parfaitement remapper la géométrie de n'importe quelle surface plane. Merci d'avoir écouté. J'espère que tu as appris quelque chose de nouveau.

Salut, c'est Alex de DEV STORIES DOT EU. OpenCV : Deep Dive dans la Computer Vision, épisode 6 sur 20. Le temps qu'un nouvel algorithme de tracking devienne une fonction standard dans la librairie OpenCV principale, il a souvent passé des années à être battle-testé par des chercheurs dans un espace parallèle. Si tu te contentes uniquement des releases par défaut, tu passes à côté des toutes dernières techniques du domaine. Cet espace parallèle, c'est le repository opencv_contrib. Beaucoup de développeurs voient le mot contrib et pensent que le code est cassé, non testé, ou que c'est strictement un software en bêta. C'est un malentendu. Le code de ce repository est souvent ultra optimisé et activement utilisé dans des environnements exigeants. La différence se situe entièrement au niveau de la stabilité de l'API, pas de la qualité du code. La librairie core d'OpenCV impose des garanties strictes de backward compatibility à long terme. Si une fonction intègre la release principale, ses inputs, ses outputs et son comportement doivent rester stables pendant des années. Mais la recherche en Computer Vision avance à une vitesse folle. Les chercheurs ont besoin d'un endroit pour publier de nouveaux algorithmes, renommer des paramètres et modifier des structures de données en fonction des retours du terrain. Le repository opencv_contrib offre exactement cet environnement. Il sert d'incubateur. Les maintainers de ces modules supplémentaires ont le droit de casser l'API entre les releases. Ils peuvent renommer des fonctions ou changer la façon dont un algorithme s'initialise sans violer les règles strictes de la librairie core. Avec le temps, un module peut s'avérer universellement utile. Son API se stabilise, les edge cases sont corrigés, et la communauté commence à s'appuyer fortement dessus. Quand ça arrive, les maintainers d'OpenCV migrent le code. Ils déplacent physiquement le module hors du repository opencv_contrib et le mergent directement dans le repository OpenCV principal. Ce processus de graduation garantit que la librairie core n'absorbe que des technologies stables et éprouvées. Prenons un scénario concret. Tu développes un projet de réalité augmentée et tu veux utiliser le module de tracking ArUco pour détecter des marqueurs fiduciels carrés dans un flux caméra en direct. Ce module contient des fonctions ultra spécialisées, à la pointe de la technologie. Pour l'utiliser, tu dois builder ton environnement OpenCV depuis les sources. Tu clones le repository principal sur ta machine en local, et ensuite tu clones le repository opencv_contrib juste à côté. Quand tu configures ton outil de build, tu passes une variable de path spécifique qui pointe vers le dossier des modules à l'intérieur du repository contrib. Le système de build lit ce flag et compile la librairie core, mais il va aussi chercher dans le dossier contrib, compile le module ArUco, et le linke directement dans tes binaires finaux. Tu ne te retrouves pas avec deux librairies séparées. Tu obtiens une seule installation OpenCV unifiée qui inclut à la fois la base ultra solide et les modules expérimentaux que tu as choisis. Si tu aimes le podcast et que tu veux soutenir l'émission, tu peux chercher DevStoriesEU sur Patreon, c'est toujours super apprécié. La vraie puissance de cette architecture, c'est de comprendre sa double nature : le repository principal protège tes pipelines de production des breaking changes, pendant que le repository contrib te donne accès dès aujourd'hui à la recherche en Computer Vision de demain. C'est tout pour cet épisode. À la prochaine !

Salut, c'est Alex de DEV STORIES DOT EU. OpenCV : Computer Vision Deep Dive, épisode 7 sur 20. Tu peux arracher le cerveau d'un énorme serveur de training PyTorch, l'exporter sous forme d'un seul fichier, et le faire tourner à une vitesse folle en pur C++ sans installer PyTorch du tout. Quand tu passes du training d'un modèle à son deploy dans le monde réel, tes besoins basculent de la flexibilité à la vitesse brute. C'est exactement là que l'Inference Engine, le module DNN d'OpenCV, prend le relais. Un piège classique dans lequel tombent les ingénieurs, c'est de supposer que si un modèle a été entraîné avec TensorFlow, la machine de deploy cible doit aussi avoir une grosse installation TensorFlow pour le faire tourner. C'est faux. OpenCV exécute l'inférence de façon totalement native. Le module DNN est un moteur d'inférence dédié et ultra-optimisé pour la forward-pass. Il ne fait pas de backpropagation. Il ne calcule pas les gradients. Il n'entraîne pas de modèles. Son seul boulot, c'est de prendre un réseau pré-entraîné, d'ingérer une image, et de te donner une réponse aussi vite que le hardware le permet. OpenCV fournit des loaders natifs pour les formats de modèles standards. Tu peux charger des modèles Caffe, des protocol buffers TensorFlow, des configurations Darknet et des fichiers ONNX directement dans ton application. Voici l'idée clé. Quand tu appelles une fonction comme readNet, OpenCV parse le format de fichier externe et reconstruit le graphe du réseau de neurones en utilisant ses propres implémentations internes de layers en C++. Les dépendances externes sont complètement supprimées. Ton application est uniquement linkée à OpenCV. Prends l'exemple d'une smart camera embarquée en C++, conçue pour détecter les piétons dans la rue. Tu ne veux pas qu'un énorme runtime Python consomme ta mémoire limitée, et tu ne veux certainement pas que des gigaoctets de librairies de deep learning prennent de l'espace de stockage sur un edge device. À la place, tu entraînes ton détecteur de piétons sur un gros cluster GPU et tu exportes les weights finaux vers un fichier ONNX. Tu déposes ce seul fichier sur le stockage de ta caméra. Dans ton application C++, tu utilises le module DNN pour charger le fichier ONNX. Ensuite, tu captures une frame depuis le capteur de la caméra. Les réseaux de neurones ne peuvent pas traiter les images brutes directement. Tu dois convertir cette frame en un array structuré à quatre dimensions, communément appelé un blob. OpenCV fournit une fonction dédiée pour construire ce blob, qui gère le redimensionnement de l'image, le swap des canaux de couleur, et l'application de la mean subtraction ou du scaling spécifique que le modèle d'origine exige. Tu passes ce blob préparé à l'input layer du réseau. Tu appelles ensuite la fonction forward. Le module DNN prend le relais, en poussant les données à travers chaque convolutional layer, fonction d'activation, et pooling layer. Parce qu'OpenCV possède l'intégralité du graphe d'exécution à ce stade, il peut optimiser les calculs de manière agressive. Il fusionne les layers adjacents quand c'est possible pour réduire la bande passante mémoire et cible automatiquement l'accélération hardware native. La fonction forward se termine et renvoie un array final contenant les coordonnées des bounding boxes et les scores de confiance pour les piétons qu'elle a trouvés. Garde tes frameworks lourds au labo pour le training, et utilise le module DNN d'OpenCV pour un deploy léger et sans dépendances en production. Merci d'avoir écouté. J'espère que tu as appris quelque chose de nouveau.

Salut, c'est Alex de DEV STORIES DOT EU. OpenCV : Computer Vision Deep Dive, épisode 8 sur 20. Avant l'arrivée des systèmes modernes, les object detectors devaient scanner une seule image des dizaines de fois à différentes échelles juste pour trouver une cible. C'était atrocement lent et super lourd en calcul. Puis une nouvelle architecture a révolutionné le domaine en faisant tout le boulot en une seule passe mathématique incroyablement rapide. Aujourd'hui, on s'intéresse à la lignée YOLO : Fast Object Detection. Pour comprendre pourquoi You Only Look Once, ou YOLO, a tout changé, regarde le standard précédent. Les anciens pipelines multi-stage reposaient sur des region proposals. Ils généraient des centaines d'hypothèses sur l'endroit où un objet pouvait se trouver, croppaient ces zones, puis faisaient tourner un image classifier sur chaque patch isolé. Tu faisais tourner des réseaux complexes en boucle. C'était déconnecté, difficile à optimiser et fondamentalement lent. Certains devs confondent YOLO avec l'image classification standard, qui assigne simplement un label à une image entière. YOLO fait bien plus que ça. Il sort des bounding boxes spatiales précises avec des class probabilities. Il te dit ce qu'est l'objet et exactement où il se trouve dans l'espace physique. YOLO a réussi ça en repensant complètement l'object detection. Au lieu d'un pipeline multi-stage, il a transformé la détection en un seul problème de régression. La logique passe directement des pixels bruts de l'image aux coordonnées des bounding boxes et aux class probabilities en une seule étape continue. Voici l'idée clé. YOLO prend l'image en input et la divise en une grille uniforme. Si le centre d'un objet tombe dans une cellule spécifique de la grille, cette cellule exacte devient responsable de la détection de l'objet. Chaque cellule de la grille prédit simultanément un nombre fixe de bounding boxes. Pour chaque box, elle sort les coordonnées du centre, la largeur et la hauteur. Elle sort aussi un confidence score, qui dit au système à quel point il est sûr que la box contient vraiment un objet. Simultanément, la cellule prédit les class probabilities. Elle calcule si l'objet est une voiture, un camion ou une personne. Le neural network multiplie ensuite la box confidence par la class probability. Cette seule opération mathématique filtre toutes les hypothèses faibles sur toute la grille, pour ne garder que les bounding boxes ultra précises. Prends l'exemple d'une caméra de péage d'autoroute à grande vitesse. Les voitures roulent à 130 km/h. Tu as besoin d'un réseau single-pass pour dessiner des bounding boxes autour des plaques d'immatriculation avant que la voiture ne quitte la frame. Un détecteur multi-stage ramerait, en croppant et en analysant des patches d'asphalte isolés pendant que la voiture s'éloigne à toute vitesse. YOLO traite toute la frame d'un coup. Il applique la grille, prédit la géométrie et calcule les probabilités en une seule forward pass du neural network. Parce que YOLO traite toute l'image en une seule passe, il comprend intrinsèquement le contexte global de la scène. Les anciens modèles confondaient souvent des patches de background avec des objets parce qu'ils ne voyaient que des crops isolés. En formulant la détection comme un seul problème de régression sur une grille, YOLO force le réseau à apprendre des représentations généralisées des objets dans leur contexte complet. Merci d'avoir passé quelques minutes avec moi. À la prochaine, prends soin de toi.

Salut, c'est Alex de DEV STORIES DOT EU. OpenCV : Deep Dive en Computer Vision, épisode 9 sur 20. Pendant une décennie, le plus gros bottleneck dans la détection d'objets en temps réel n'était pas le réseau de neurones lui-même. C'était l'algorithme lourd, codé à la main, utilisé pour nettoyer ses prédictions brouillonnes qui se chevauchaient. La solution à ça, c'est YOLOv26, et plus précisément son architecture de détection end-to-end NMS-free. Pour comprendre ce changement, tu dois regarder comment les détecteurs traditionnels terminent leur job. Ils s'appuient sur la Non-Maximum Suppression, ou NMS. La NMS est une étape de post-processing lente. Quand un modèle standard regarde un objet, il ne prédit pas juste une seule bounding box. Il prédit des dizaines de boxes qui se chevauchent autour du même objet. La NMS intervient pour scorer ces boxes, calculer leur overlap, supprimer les doublons et ne garder que le meilleur fit. Ce processus de nettoyage est intrinsèquement séquentiel et tourne presque toujours sur le CPU. Imagine que tu déploies un modèle de vision sur un NVIDIA Jetson Orin pour un robot de tri en entrepôt. Tu dois détecter des centaines de colis qui bougent vite à 60 frames par seconde. Le GPU fonce à travers les layers du réseau de neurones. Puis, le pipeline bloque. Le CPU s'étouffe en essayant de faire tourner la NMS sur des milliers de coordonnées brutes de boxes qui se chevauchent. Ton framerate s'effondre à cause du nettoyage, pas de l'inférence. YOLOv26 élimine complètement ce bottleneck en fournissant une inférence NMS-free native. Tu passes une image au réseau, et le réseau te sort exactement une box par objet. Le script de post-processing a disparu. Pour rendre ça possible, l'architecture YOLOv26 abandonne un composant appelé Distribution Focal Loss, ou DFL. Dans les itérations précédentes, la DFL était utilisée pour modéliser les bords d'une bounding box comme une distribution statistique continue. Ça aidait le modèle à deviner où pouvaient se trouver les bords flous ou masqués, mais ça encourageait naturellement le réseau à sortir plusieurs prédictions qui se chevauchaient. Retirer la DFL change fondamentalement le comportement du réseau. Sans elle, le modèle est lourdement pénalisé pendant le training s'il prédit plus d'une box par objet. Ça force le réseau à être absolument décisif. Cependant, retirer la DFL crée un nouveau problème. Forcer le réseau à sortir exactement une hard boundary rend le processus de training très instable. Le loss landscape devient abrupt et chaotique. Pour corriger ça, YOLOv26 intègre l'optimizer MuSGD dans son pipeline de training. MuSGD stabilise le processus d'apprentissage en ajustant dynamiquement le momentum en fonction de la variance des gradients. Quand le training atteint une partie abrupte et chaotique du loss landscape, MuSGD amortit les updates des weights pour que le modèle ne déraille pas. Quand le chemin du gradient est stable, il accélère. C'est cet optimizer spécifique qui permet à l'architecture de converger vers une prédiction unique et stricte sans s'effondrer. Le résultat au deploy est massif. Quand tu exportes un modèle YOLOv26 vers TensorRT pour ce robot d'entrepôt, tout le pipeline reste sur le GPU. Le réseau traite la frame et sort directement les coordonnées finales du colis. Le CPU est complètement libéré pour d'autres tâches de contrôle robotique. Voici l'idée clé. Le code le plus rapide, c'est le code qui ne tourne jamais. En déplaçant la charge de la déduplication d'un script de post-processing au runtime vers la phase d'optimisation du training, YOLOv26 débloque une efficacité matérielle qui était auparavant impossible. C'est tout pour cet épisode. Merci de ton écoute, et continue de builder !

Salut, c'est Alex de DEV STORIES DOT EU. OpenCV : Computer Vision Deep Dive, épisode 10 sur 20. Les détecteurs d'objets traditionnels souffrent d'une forme sévère de vision en tunnel. Ils peuvent parfaitement tracker des voitures, des personnes et des vélos, mais demande-leur de trouver une tasse de café renversée, et ils sont complètement aveugles, limités à la poignée de classes sur lesquelles ils ont été explicitement entraînés en labo. Pour corriger ça, tu n'as pas besoin de labelliser des milliers de tasses renversées. Il te faut YOLO-World et l'Open-Vocabulary Zero-Shot Detection. Prends un scénario spécifique. Tu gères le système de sécurité d'un magasin. Tu dois chercher une bouteille Hydroflask bleue ou un golden retriever perdu dans des flux vidéo en direct. Avec un détecteur standard à vocabulaire fixe, tu devrais arrêter le système, collecter des images de golden retrievers dans ton magasin, dessiner manuellement des bounding boxes autour, réentraîner le modèle, et faire un redeploy. Avec YOLO-World, tu tapes juste le text prompt dans le système. Il trouve l'objet instantanément, en zero-shot. Ce n'est pas un modèle génératif text-to-image. Il ne crée pas d'images. C'est aussi très différent du simple ajout d'une nouvelle classe à un dataset existant. L'open-vocabulary detection repose sur une compréhension sémantique profonde du langage. Elle mappe directement les text prompts linguistiques à des bounding boxes visuelles. Le système prend deux inputs : une image et un ensemble de text prompts. Il utilise un vision backbone pour extraire les features visuelles de l'image. En même temps, il utilise un text encoder pour traduire tes text prompts en vecteurs mathématiques, appelés embeddings. C'est là que ça devient intéressant. Ces deux flux de données distincts doivent être combinés. YOLO-World gère ça en utilisant une structure appelée RepVL-PAN. Ça veut dire Reparameterizable Vision-Language Path Aggregation Network. L'acronyme est lourd, mais la fonction est simple. RepVL-PAN fusionne les features de l'image et du texte. Il injecte le sens sémantique de ton text prompt directement dans la feature map visuelle à plusieurs échelles. Pendant que le réseau traite les pixels, il est activement guidé par le text embedding. Le modèle apprend à faire ça pendant sa phase de training initiale grâce à un mécanisme appelé region-text contrastive loss. Le modèle génère des bounding boxes et extrait les features visuelles de ces régions. Il compare ensuite ces features visuelles aux text embeddings. La contrastive loss pénalise lourdement le modèle si les features visuelles d'une box ne s'alignent pas avec le bon text embedding. Elle récompense le modèle quand ça matche. Ça force le réseau à aligner précisément sa représentation visuelle avec les concepts linguistiques sur des datasets massifs de paires image-texte. Il apprend ce que bleu, hydroflask et bouteille veulent dire en tant que concepts généraux, plutôt que de mémoriser une seule catégorie rigide. Quand tu fais tourner le modèle en production, le workflow est incroyablement propre. D'abord, tu définis une liste de vocabulaire custom contenant tes objets cibles. Tu passes cette liste dans le text encoder une fois pour générer tes text embeddings. Ensuite, tu envoies tes frames vidéo en direct dans le visual backbone. L'architecture RepVL-PAN fusionne les données visuelles entrantes avec tes text embeddings précalculés. Enfin, le modèle renvoie des bounding boxes et des confidence scores basés sur la correspondance entre les régions visuelles et tes mots. La vraie puissance de YOLO-World, c'est de découpler le détecteur d'un dataset rigide, ce qui te permet d'utiliser le langage naturel comme une query exécutable en temps réel pour le monde physique. Merci d'avoir écouté. À la prochaine !

Salut, c'est Alex de DEV STORIES DOT EU. OpenCV : Deep Dive en Computer Vision, épisode 11 sur 20. Pour une IA moderne, ton identité ne se définit pas par la forme de ton nez ni par l'écart entre tes yeux. Elle est plutôt définie par tes coordonnées exactes dans un espace géométrique à 128 dimensions. L'épisode Classic to Deep : l'évolution de la reconnaissance faciale explique comment on est arrivés à ce modèle. D'abord, on doit séparer deux concepts qui sont souvent confondus. La face detection, c'est trouver où est un visage dans une image. Ça dessine une bounding box autour des pixels qui ressemblent à une tête humaine. La face recognition, c'est identifier à qui appartient le visage à l'intérieur de cette box. Cet épisode se concentre strictement sur la recognition. Pendant des décennies, l'approche standard était statistique. Si tu as développé un système au début des années 2000, tu as sûrement utilisé une technique appelée Eigenfaces. Les Eigenfaces reposent sur un algorithme appelé Principal Component Analysis, ou PCA. Tu commences avec un dataset d'images de visages et tu flatten chaque image en un immense array à une dimension d'intensités de pixels brutes. La PCA analyse ensuite tout ce dataset pour trouver les directions de variance maximale. Elle trouve les patterns mathématiques sous-jacents qui différencient un visage d'un autre. Quand tu visualises ces principal components, ils ressemblent à des visages fantomatiques et flous. Pour reconnaître une nouvelle personne avec les Eigenfaces, le système projette la nouvelle image brute dans ce subspace de principal components et calcule la distance par rapport aux visages connus dans la database. Ça marche dans des environnements très contrôlés, mais ça plante dans le monde réel. Une ombre sur une joue ou une légère inclinaison de la tête modifie complètement les valeurs brutes des pixels. L'algorithme voit un pattern de lumière différent et n'arrive pas à te reconnaître. Voici l'idée clé. Le deep learning a complètement abandonné l'idée de comparer la variance des pixels bruts. Les systèmes modernes utilisent des Convolutional Neural Networks pour générer des embeddings. Un embedding est un vecteur dense de nombres qui représente les features de haut niveau d'un visage. Ces réseaux sont entraînés sur des millions d'images en utilisant des pénalités mathématiques avancées, comme la loss ArcFace. Pendant le training, le réseau est forcé de rapprocher les vecteurs d'embeddings d'une même personne dans l'espace géométrique, tout en éloignant les vecteurs de personnes différentes. Imagine une serrure de porte de bureau sécurisée équipée d'une caméra. Quand un visiteur s'approche, le système détecte et crop le visage, puis passe cette image croppée dans le neural network. Le réseau output un seul array de 128 nombres en floating-point. C'est ça, le vecteur d'embedding. Le système calcule ensuite la simple distance euclidienne entre ce vecteur visiteur et une database de vecteurs d'employés autorisés. Il ne compare pas les pixels ou l'éclairage. Il mesure juste la distance en ligne droite entre deux points dans un espace à 128 dimensions. Si la distance par rapport à un vecteur d'employé est en dessous d'un threshold prédéfini, la porte se déverrouille. Le système est robuste parce que le réseau a appris à ignorer les ombres, les lunettes et les légères rotations de la tête pendant le training. L'évolution des Eigenfaces vers les deep embeddings, c'est le passage de l'analyse de la façon dont la lumière frappe un visage au mapping de l'identité conceptuelle d'une personne dans un système de coordonnées mesurable. Si tu veux aider à faire couler le café à flots et soutenir l'émission, tu peux chercher DevStoriesEU sur Patreon. C'est tout pour cet épisode. Merci pour ton écoute, et continue de builder !

Salut, c'est Alex de DEV STORIES DOT EU. OpenCV : Computer Vision Deep Dive, épisode 12 sur 20. Faire tourner un gros neural network sur chaque frame d'une vidéo haute résolution est un énorme gaspillage de ressources. Les systèmes intelligents détectent un objet une seule fois, puis utilisent des équations physiques ultra-rapides pour prédire où il va se déplacer. C'est le domaine de la Persistent Perception : les algorithmes d'Object Tracking. Imagine un système de surveillance du trafic dans une smart city. Tu dois compter les véhicules uniques qui traversent une intersection très fréquentée. Un modèle d'object detection regarde un seul instant figé dans le temps. Si tu fais tourner une détection pure sur une vidéo à trente frames par seconde, une voiture arrêtée à un feu rouge pendant dix secondes génère trois cents bounding boxes séparées et déconnectées. Sans logique de tracking, ton système compte trois cents voitures. La détection trouve l'objet. Le tracking associe mathématiquement cet objet à son état passé au fil du temps. Pour corriger la caméra de circulation, tu as besoin d'un multi-object tracker pour maintenir un ID persistant pour chaque véhicule. Les trackers modernes, comme ceux implémentés avec Roboflow et OpenCV, divisent ce problème en deux phases mathématiques distinctes. La première phase est la prédiction, et la deuxième phase est l'association. Quand une voiture entre dans le flux de la caméra, le détecteur initial dessine une bounding box. Le tracker extrait les coordonnées du centre, la largeur et la hauteur de cette box, et lui assigne un entier unique, comme l'ID 42. Quand la frame vidéo suivante arrive, le tracker ne scanne pas immédiatement l'image. À la place, il utilise un modèle mathématique, typiquement un Kalman Filter, pour faire de la state estimation. En évaluant comment l'ID 42 s'est déplacé sur les frames précédentes, le filtre calcule la vélocité du véhicule. Il projette ensuite ces propriétés physiques vers l'avant pour prédire exactement où la bounding box de l'ID 42 devrait se trouver dans la nouvelle frame. Maintenant, tu as deux ensembles de données pour la frame actuelle. Tu as les boxes prédites générées par le state estimator, et les boxes réelles qui viennent d'être trouvées par le détecteur. Voici le point clé. Le tracker doit réconcilier ces deux ensembles pour garder les IDs cohérents sans analyser à nouveau les pixels réels. Il construit une matrice qui compare chaque box prédite avec chaque box nouvellement détectée. La métrique principale utilisée pour cette comparaison est l'Intersection over Union, ou IoU. Ça mesure à quel point la zone géométrique prédite chevauche la zone géométrique détectée. Si l'emplacement prédit pour l'ID 42 chevauche fortement une bounding box nouvellement détectée, le système conclut que c'est le même véhicule. Une méthode d'optimisation, typiquement le Hungarian algorithm, résout cette matrice pour trouver les paires one-to-one les plus logiques sur toute l'intersection. La nouvelle détection hérite de l'ID 42, et le tracker met à jour son modèle de vélocité avec les nouvelles coordonnées confirmées. Cette boucle de prédiction et d'association gère de manière inhérente les obstructions visuelles temporaires. Si un bus bloque la vue de notre voiture pendant quelques frames, le détecteur ne parvient pas à la trouver. Cependant, le state estimator continue de prédire le mouvement de la voiture derrière le bus en se basant sur sa dernière trajectoire connue. L'ID est maintenu en vie dans un pending state. Quand la voiture réapparaît et que le détecteur signale une bounding box qui s'aligne avec la prédiction à l'aveugle du tracker, l'ID est instantanément reconnecté. En faisant le pont entre des frames indépendantes, le multi-object tracking transforme un flux d'images statiques en une carte cohérente d'entités en mouvement. Le tracking permet à ton application d'arrêter de se demander ce qu'il y a dans la frame, et de commencer à comprendre comment les choses se comportent au fil du temps. C'est tout pour cet épisode. Merci de ton écoute, et continue à builder !

Salut, c'est Alex de DEV STORIES DOT EU. OpenCV : Deep Dive en Computer Vision, épisode 13 sur 20. On a passé des années à entraîner l'IA à dessiner des bounding boxes autour des objets, mais ces boxes sont imprécises et pleines de bruit de fond. Le vrai but, c'est de demander à un système en langage naturel de peindre une silhouette pixel-perfect autour des contours exacts d'un objet, même s'il n'a jamais été explicitement entraîné sur cet objet avant. C'est là qu'interviennent les Vision-Language Models pour la segmentation. Les modèles de segmentation d'images traditionnels sont rigides. Ils mappent les pixels à une liste fixe et fermée de catégories comme voiture, personne ou arbre. Si tu veux segmenter quelque chose en dehors de cette liste, tu dois collecter un dataset massif et entraîner un tout nouveau modèle. Les Vision-Language Models, ou VLMs, cassent cette limitation en fusionnant des large language models avec des visual encoders pour faire de la segmentation open-world. Tu passes en input une image et une string arbitraire, et le modèle te retourne un mask dense, au niveau du pixel, de ce que tu as décrit. Prends l'exemple d'un drone agricole automatisé qui survole un vignoble. Un agriculteur ne veut pas de simples boxes génériques autour de ses plants. Il a besoin d'une carte précise de l'infection. Il fait un prompt au drone avec la string « feuilles de vigne malades ». Le VLM traite le flux visuel et le text prompt en même temps. Il comprend le sens sémantique de « malades » et « feuilles de vigne » grâce à son entraînement linguistique, il aligne ce sens avec les visual features de l'image, et il génère un mask. Ce mask isole uniquement le feuillage infecté au pixel près, en ignorant complètement les feuilles saines, le sol et les ombres. Ce qui nous amène à la façon dont le modèle exécute concrètement cette logique. L'approche de base, c'est le text prompting en zero-prediction, souvent appelé zero-shot. Dans ce mode, le modèle s'appuie entièrement sur le vaste dataset sur lequel il a été entraîné à l'origine. Le text prompt passe par un text encoder, pour se transformer en une représentation mathématique de ta requête. En même temps, l'image passe par un vision encoder, qui découpe la photo en une grille de visual features. Le modèle calcule ensuite la similarité entre ta représentation textuelle et chaque visual feature de cette grille. Les scores de similarité élevés deviennent ton mask. Le point crucial ici, c'est que les weights du modèle restent complètement frozen. Tu extrais un pixel mask complexe en utilisant uniquement la puissance de l'alignement linguistique. Voici l'idée clé. La zero-prediction est puissante, mais elle repose sur un entraînement large et généraliste. Parfois, le domaine visuel est tout simplement trop spécialisé. Si une maladie spécifique des feuilles de vigne ressemble trait pour trait à une carence nutritionnelle inoffensive, le VLM frozen risque d'avoir du mal à les différencier uniquement à partir d'une description textuelle. C'est là que tu passes au visual fine-tuning. Au lieu de juste changer le text prompt, tu mets à jour les weights réels des composants visuels du modèle en utilisant un petit dataset d'images très spécifiques, masquées manuellement. Tu apprends explicitement au vision encoder la texture visuelle nuancée de la maladie, au lieu de te reposer uniquement sur la compréhension conceptuelle globale du mot « maladie » par le language model. La zero-prediction traite le VLM comme un moteur de raisonnement out-of-the-box piloté entièrement par les mots, tandis que le visual fine-tuning le traite comme une fondation puissante que tu altères de façon permanente pour maîtriser un domaine visuel spécifique. La vraie puissance de la segmentation moderne, ce n'est plus de collecter des millions de pixels labellisés ; c'est de savoir quand guider un modèle frozen avec un text prompt malin, et quand dépenser du compute pour modifier ses visual weights. C'est tout pour cet épisode. Merci d'avoir écouté, et continue à développer !

Salut, c'est Alex de DEV STORIES DOT EU. OpenCV : Deep Dive en Computer Vision, épisode 14 sur 20. Même si les humains voient la couleur comme un mélange de rouge, de vert et de bleu, essayer de programmer un ordinateur pour tracker un objet en utilisant le RGB est un cauchemar dès qu'un nuage cache le soleil. La solution se trouve dans la façon dont on représente et on combine mathématiquement les pixels. Aujourd'hui, on s'intéresse à l'alchimie des pixels : l'Alpha Blending et les Color Spaces. Le vrai problème avec le Color Space RGB, c'est qu'il couple directement l'information de couleur avec la luminance. Si une ombre tombe sur un objet vert vif, les valeurs de ses pixels rouge, vert et bleu changent toutes considérablement. Pour un algorithme de thresholding standard, un objet vert dans l'ombre a l'air complètement différent d'un objet éclairé. Pour corriger ça, tu transformes l'image du RGB vers le Color Space HSV. HSV signifie Hue, Saturation, et Value. Le Hue représente la couleur de base elle-même sous forme d'angle sur un cylindre de couleur. La Saturation représente l'intensité de cette couleur, et la Value représente la luminosité. En isolant l'information de couleur pure dans ce seul channel Hue, ton pipeline de Computer Vision devient hyper résistant aux changements d'éclairage. Tu peux configurer ta logique pour chercher une nuance de vert spécifique, et elle la trouvera que la pièce soit très éclairée ou sombre. Cette robustesse est critique quand tu construis un truc comme un système de green-screen automatisé pour un broadcast. Tu veux faire un blend parfait d'une carte météo dynamique derrière un présentateur. D'abord, tu prends le feed de la caméra et tu le convertis en HSV. Ensuite, tu définis une plage de Hues verts qui correspond au fond physique. Pour chaque pixel qui tombe dans cette plage de Hue vert, tu sors un zéro. Pour tout le reste, comme le présentateur, tu sors un un. Ça crée un mask binaire. Ce mask te sert d'alpha channel. Voici le point clé. Les auditeurs parlent souvent de l'alpha comme si c'était une couleur, presque comme une teinture transparente. Ce n'est pas le cas. L'alpha est purement un poids numérique, une valeur scalaire entre zéro et un qui dicte l'opacité dans une équation d'interpolation linéaire. L'image blending, c'est simplement de l'arithmétique pixel par pixel. Pour combiner le présentateur en foreground et la carte météo en background, tu utilises une équation spécifique. Pour chaque pixel, la couleur d'output finale est égale au pixel du foreground multiplié par la valeur alpha, plus le pixel du background multiplié par un moins la valeur alpha. Réfléchis aux maths de ce scénario de green-screen. Là où se trouve le présentateur, l'alpha est à un. Le pixel du foreground est multiplié par un, ce qui préserve parfaitement le présentateur. Le pixel de la carte météo en background est multiplié par un moins un, ce qui fait zéro. La carte météo disparaît à cet endroit exact. À l'inverse, là où se trouve le green-screen, l'alpha est à zéro. Le pixel vert du foreground est multiplié par zéro, ce qui efface complètement l'écran physique. Le pixel de la carte météo en background est multiplié par un moins zéro, ce qui fait un, rendant la carte météo totalement visible. Si tu veux un bord lisse et anti-aliased autour du présentateur, tu utilises des valeurs alpha fractionnaires comme zéro virgule cinq le long de la bordure. Ça fait la moyenne entre les pixels du foreground et du background pour éviter les contours durs et en escalier. Le truc le plus utile à retenir, c'est que les images en mémoire sont juste des matrices, et que la manipulation de pixels, c'est juste de l'arithmétique matricielle ; choisir le bon système de coordonnées, comme le HSV, rend cette arithmétique robuste et prévisible au lieu d'être fragile. Merci d'avoir passé quelques minutes avec moi. À la prochaine, prends soin de toi.

Salut, c'est Alex de DEV STORIES DOT EU. OpenCV : Computer Vision Deep Dive, épisode 15 sur 20. Chaque photo que tu as prise est un subtil mensonge, déformée par le verre incurvé de l'objectif. En robotique, cette légère déformation fait toute la différence entre attraper une balle et la rater complètement. Combler cet écart nécessite la Camera Calibration : Navigating Lens Distortion. Tu montes une webcam fisheye pas chère et très déformée sur un bras robotisé. Le système doit calculer la distance exacte au millimètre près pour attraper une tasse à café fragile en toute sécurité. Si tu traites directement le flux vidéo raw, ta géométrie est complètement fausse. L'objectif courbe la lumière entrante, ce qui veut dire qu'un pixel près du bord de la frame représente une distance réelle radicalement différente d'un pixel en plein centre. Si le robot se fie à ces pixels raw, il va écraser la tasse. On doit corriger deux grands types de distorsion de l'objectif. Le premier, c'est la radial distortion. La lumière se courbe plus sur les bords d'un objectif qu'en son centre. Ça donne aux lignes droites un aspect courbé, souvent bombé vers l'extérieur comme un tonneau, ou pincé vers l'intérieur. Le deuxième, c'est la tangential distortion. Ça arrive pendant la fabrication quand l'objectif n'est pas monté de façon parfaitement parallèle au capteur d'image, ce qui fait que certaines zones de l'image ont l'air plus proches que d'autres. Pour corriger ça, on a besoin d'un point de référence géométrique connu. Le standard de l'industrie, c'est un simple pattern de checkerboard plat, imprimé sur un support rigide. Un checkerboard offre des lignes d'intersection nettes et très contrastées, ce qui permet à un algorithme de détection de repérer super facilement les coins intérieurs exacts. Plus important encore, comme on l'a imprimé, on connaît les dimensions physiques exactes des carrés. Les développeurs confondent souvent les paramètres intrinsic et extrinsic quand ils manipulent des données de calibration. C'est facile de tout regrouper en se disant que ce sont juste des settings de la caméra. Voici le truc à retenir. Les paramètres extrinsic ne décrivent pas du tout le hardware de la caméra. Ils définissent la position physique et la rotation de la caméra dans le monde 3D par rapport à la scène. Les paramètres intrinsic, par contre, définissent les propriétés physiques internes de l'objectif et du capteur. Ils encapsulent la focal length et l'optical center. L'intrinsic matrix est unique à cette caméra physique spécifique et reste constante, peu importe où le bras robotisé se déplace. Le process de calibration fonctionne en mappant des points 3D connus sur des pixels 2D observés. D'abord, tu prends une douzaine de photos ou plus du checkerboard sous différents angles et distances avec ta webcam. Ensuite, tu lances une fonction de corner detection sur ces images. Tu construis une liste de l'endroit où ces coordonnées de pixels 2D tombent dans les images, et tu les associes à un array des coordonnées 3D réelles de ces mêmes coins. Les coordonnées 3D sont juste une grille plate basée sur la taille connue de ton carré, avec le Z-axis défini à zéro. Tu passes ces deux sets de coordonnées dans la fonction de camera calibration. L'algorithme calcule la transformation mathématique requise pour mapper les points 3D sur tes images 2D. Il te retourne ton intrinsic camera matrix, les vecteurs de rotation et de translation extrinsic pour chaque image, et un set de distortion coefficients. Ces coefficients gèrent le warp radial et tangential. Une fois que tu as ces coefficients et l'intrinsic matrix, tu les passes dans une fonction d'undistortion. Chaque nouvelle frame que ton robot voit est mathématiquement étirée et ramenée à une vraie projection rectiligne. Les lignes droites redeviennent droites. Ton bras robotisé peut maintenant mesurer les millimètres exacts, tendre le bras et attraper la tasse en toute sécurité. L'intrinsic matrix est la couche fondatrice de la géométrie en Computer Vision, transformant un array de pixels déformé en un système de coordonnées mathématiquement fiable. C'est tout pour cet épisode. Merci d'avoir écouté, et keep building !

Salut, c'est Alex de DEV STORIES DOT EU. OpenCV : Computer Vision Deep Dive, épisode 16 sur 20. En empruntant exactement la même astuce biologique que nos deux yeux humains utilisent pour percevoir l'espace en trois dimensions, un ordinateur peut calculer instantanément la distance d'un objet en n'utilisant que de la géométrie de base. C'est la Stereo Vision : trouver la profondeur avec deux caméras. Une simple dashcam enregistre une projection plate en deux dimensions du monde. Elle perd complètement l'information de profondeur. Sans contexte, elle ne peut pas dire de façon fiable si la voiture de devant est petite et proche, ou grande et éloignée. Pour construire un Advanced Driver Assistance System, ou ADAS, qui peut vraiment éviter une collision avec une voiture qui freine, tu as besoin de la vraie distance physique. Tu peux l'obtenir en montant deux dashcams parfaitement alignées. La distance physique entre leurs objectifs s'appelle la baseline. Pour trouver la distance avec la voiture de devant, le système doit trouver exactement le même point sur cette voiture, à la fois dans l'image de la caméra gauche et dans l'image de la caméra droite. Chercher un point de l'image gauche dans toute l'image droite est beaucoup trop lent pour de la conduite en temps réel. C'est là qu'intervient la géométrie épipolaire. En transformant mathématiquement, ou en rectifiant, les deux images pour que leurs objectifs soient virtuellement alignés sur exactement le même plan, tu simplifies la recherche. Un feu arrière spécifique trouvé sur la ligne deux cents de l'image gauche n'existera désormais que sur la ligne deux cents de l'image droite. Ce chemin de recherche horizontal s'appelle la ligne épipolaire. Le système n'a plus qu'à scanner de gauche à droite le long d'une seule ligne. Quand le système trouve le pixel correspondant sur cette ligne, il mesure la différence de leurs positions horizontales. Cette différence s'appelle la disparité. Les gens confondent souvent la disparité avec la profondeur, mais elles sont inversement proportionnelles. Les objets qui changent radicalement de position entre les deux vues de caméra sont physiquement plus proches des objectifs. Si la voiture qui freine devant toi saute de quarante pixels entre les vues gauche et droite, elle est très proche. Si une montagne à l'horizon ne se décale que d'un pixel, elle est très loin. Une disparité élevée signifie une faible profondeur. Voici l'idée clé. Tu ne veux pas juste la distance d'un seul feu arrière. Tu veux une disparity map dense, c'est-à-dire une valeur de profondeur pour presque chaque pixel de la frame. OpenCV gère ça en utilisant le block matching, plus précisément un algorithme appelé Semi Global Block Matching. Au lieu d'essayer de matcher un seul pixel ambigu, il prend un petit bloc de pixels de l'image gauche. Il fait ensuite glisser ce bloc le long de la ligne épipolaire horizontale dans l'image droite, en comparant les intensités des pixels jusqu'à trouver le meilleur match mathématique. Il fait ça sur toute l'image, en appliquant des pénalités pour les sauts soudains de disparité afin de garder la map résultante lisse et physiquement réaliste. Une fois que tu as la disparity map, la convertir en profondeur dans le monde réel est un simple calcul. Tu multiplies la focal length des caméras par la distance physique de la baseline entre elles, et tu divises ce résultat par la valeur de disparité du pixel. Les maths sont absolues. Tu ne devines pas en te basant sur les ombres ou la taille des objets. Tant que tes caméras restent rigidement calibrées et alignées, ce calcul géométrique te donne la distance précise avec le véhicule de devant en quelques millisecondes. La beauté d'un stereo rig calibré, c'est qu'il contourne le besoin d'identifier ce qu'est un objet avant de savoir où il est. C'est tout pour cette fois. Merci d'avoir écouté, et continue de builder !

Salut, c'est Alex de DEV STORIES DOT EU. OpenCV : Computer Vision Deep Dive, épisode 17 sur 20. Pendant des décennies, les ingénieurs en computer vision pensaient que tu avais besoin de deux caméras pour calculer la distance réelle. Tu avais besoin de la vision stéréoscopique pour trianguler des points dans l'espace. Aujourd'hui, les modèles d'IA peuvent percevoir la distance physique à partir d'une seule image plane en interprétant les ombres, la texture et l'échelle, exactement comme le fait un peintre. Cette avancée s'appelle la Deep Monocular Metric Depth. On confond souvent la relative depth et la metric depth. La relative depth, c'est simplement savoir qu'un canapé se trouve devant un mur. C'est un tri de layers visuels. La metric depth, c'est savoir que le canapé est exactement à deux virgule quatre mètres de l'objectif de la caméra. Jusqu'à récemment, extraire des mesures métriques absolues à partir d'une seule image était considéré comme mathématiquement impossible. Une seule image en deux D perd toute notion d'échelle inhérente. Un objet pourrait être petit et proche de l'objectif, ou massif et très éloigné. Les modèles de deep learning contournent complètement ce problème de géométrie classique. Au lieu de trianguler des points entre deux objectifs, les réseaux comme DepthPro apprennent à partir de datasets massifs contenant des millions d'images associées à des depth maps en trois D de ground-truth. Quand tu passes une seule image standard au réseau, il ne cherche pas de disparités stéréo. Il évalue des indices monoculaires. Il analyse les gradients de texture, en notant où les surfaces paraissent plus lisses plus elles sont éloignées. Il traite l'éclairage contextuel, l'occlusion et l'échelle physique connue des objets reconnaissables. Le modèle construit ensuite une prédiction dense, pixel par pixel, de la distance absolue. Voici le point clé. Les architectures modernes y parviennent sans connaître les camera intrinsics de ton appareil photo. Tu n'as pas besoin de passer au réseau la focal length, le field of view ou la taille du capteur de la caméra qui a pris la photo. Le réseau déduit la focal length directement à partir du contenu visuel de l'image elle-même. Ça crée une solution zero-shot. Tu passes au modèle une photo prise par n'importe quel objectif non calibré au hasard, et il sort une depth map absolue et précise. Pense à une application de réalité augmentée sur un smartphone standard. Un utilisateur veut voir si une nouvelle table à manger rentre chez lui. Il se tient dans une pièce vide et pointe sa seule caméra arrière vers le sol. L'AR classique t'oblige à bouger le téléphone pour générer de la parallaxe et construire lentement une spatial map. Avec la Deep Monocular Metric Depth, l'application traite une seule frame statique instantanément. Le neural network calcule le volume et les dimensions exactes de l'espace au sol en quelques millisecondes. L'application rend ensuite une table virtuelle dans le camera feed, parfaitement mise à l'échelle par rapport au monde réel, plantée sur le sol exactement à la bonne depth. Sous le capot, pour y arriver, il faut des receptive fields massifs dans l'architecture du neural network. Le modèle utilise des Vision Transformers pour capturer le contexte global. Il regarde l'image entière d'un coup pour comprendre la géométrie globale de la pièce. Il combine ensuite cette vue large avec un processing local en haute résolution. Cette double approche permet au modèle de produire des depth boundaries nettes autour de bords complexes, comme les pieds fins d'une chaise ou les feuilles d'une plante d'intérieur. Il évite complètement les artefacts flous de bleeding edge qui gâchaient les anciens modèles de depth estimation. Le changement fondamental, c'est la capacité d'extraire des mesures spatiales absolues à partir d'une seule frame d'image, complètement non calibrée. C'est tout pour cet épisode. Merci d'avoir écouté, et continue de build !

Salut, c'est Alex de DEV STORIES DOT EU. OpenCV : Computer Vision Deep Dive, épisode 18 sur 20. Les déploiements d'intelligence artificielle les plus impressionnants d'aujourd'hui ne tournent pas dans d'immenses fermes de serveurs climatisées. Ils tournent sur des puces en silicium à deux dollars, alimentées par une pile de montre, au milieu de nulle part. Transférer des réseaux de neurones complexes sur ces minuscules appareils demande une approche complètement différente, ce qui nous amène à l'AI on the Edge : le deploy sur microcontrôleurs. Les microcontrôleurs sont extrêmement limités. On parle d'appareils avec quelques kilo-octets de RAM, quelques mégaoctets de stockage flash et des limites d'énergie très strictes. Les modèles de Computer Vision standards utilisent des nombres en floating-point 32 bits pour leurs weights et leurs activations. Un modèle typique a besoin de centaines de mégaoctets juste pour être chargé en mémoire. Si tu essaies de faire tourner ça sur un microcontrôleur basique, il va planter immédiatement avec une erreur out of memory. Imagine une caméra pour la faune sauvage, sur batterie et rechargée par des panneaux solaires, déployée au fin fond d'une forêt. Son job est de repérer un léopard des neiges, une espèce menacée. Si la caméra réveille son émetteur radio pour envoyer chaque photo déclenchée par le mouvement vers un serveur cloud pour être analysée, la batterie va se vider en un jour. L'appareil doit faire tourner l'object detector en local. Il doit traiter le flux vidéo directement sur le silicium et ne réveiller l'émetteur, qui est très gourmand en énergie, que pour envoyer une alerte quand il identifie spécifiquement le léopard. Pour faire tenir un vision model sur une puce aussi petite, tu dois le réduire de façon agressive. Tu fais ça principalement via deux techniques : le pruning et la quantization. Le pruning porte bien son nom. Tu analyses le réseau de neurones entraîné et tu supprimes les connexions qui ont le moins d'impact sur la prédiction finale. En gros, tu coupes le bois mort de l'architecture du réseau pour qu'il y ait moins de calculs par frame. La deuxième technique, la quantization, c'est là que se fait la vraie réduction de taille. C'est la partie qui compte. La quantization réduit la précision numérique du modèle. Au lieu de stocker chaque weight comme un float 32 bits, tu mappes ces valeurs sur un integer 8 bits, ce qu'on appelle couramment la conversion INT8. Le compromis de base ici est simple. Tu sacrifies volontairement de la précision numérique. Pour faire ça correctement, tu fais passer un dataset de calibration dans le modèle pour traquer les valeurs minimum et maximum des weights. Ensuite, tu mets à l'échelle cette plage de floating-points pour qu'elle rentre exactement dans les 256 valeurs possibles d'un integer 8 bits. Ça échange une infime fraction de la précision du modèle contre une réduction massive du memory footprint et du temps d'exécution. Un modèle INT8 prend exactement un quart de l'espace de stockage d'un modèle 32 bits. En plus, les microcontrôleurs gèrent les calculs sur des integers beaucoup plus vite et avec beaucoup moins d'énergie que les calculs en floating-point. Beaucoup de microcontrôleurs basse consommation n'ont tout simplement pas de hardware dédié pour les opérations en floating-point. Ça veut dire que les calculs en floating-point doivent être émulés en software, ce qui est incroyablement lent et vide la batterie. Avec un modèle INT8 agressivement quantizé, quand la caméra pour la faune sauvage capture une image, le réseau de neurones multiplie et additionne de petites valeurs d'integers en de simples hardware clock cycles. Le microcontrôleur peut évaluer l'image en quelques millisecondes, confirmer qu'il n'y a pas de léopard des neiges, et repasser instantanément dans un état de deep sleep pour économiser l'énergie. Le process de deploy en lui-même commence sur une machine de bureau normale. Tu entraînes ton modèle sur un dataset standard. Une fois entraîné, tu lances un converter script qui applique le pruning et la quantization INT8. L'output est généralement un byte array plat, exporté sous forme d'un bloc de code de header C contenant les weights compressés. Tu compiles ça directement dans le firmware de ton microcontrôleur, avec les drivers de ta caméra. Il n'y a pas d'operating system ni de file system pour charger les modèles au runtime. C'est de la pure logique compilée qui s'exécute directement sur le bare metal. La contrainte ultime dans cet environnement change ta façon d'évaluer le succès. Sur un microcontrôleur, ta métrique principale n'est plus la précision maximale, c'est le nombre d'inferences précises que tu peux exécuter par millijoule d'énergie de la batterie. Si tu veux aider à faire vivre l'émission, tu peux nous soutenir en cherchant DevStoriesEU sur Patreon. C'est tout pour cet épisode. Merci d'avoir écouté, et continue de builder !

Salut, c'est Alex de DEV STORIES DOT EU. OpenCV : Computer Vision Deep Dive, épisode 19 sur 20. Les jeux vidéo traditionnels font le render de leurs mondes en dessinant des millions de minuscules triangles plats. La dernière révolution en computer vision abandonne complètement les triangles, et fait le render de la réalité sous la forme d'un point cloud dense de millions de blobs mathématiques lumineux qui se superposent. C'est les Radiance Fields : le 3D Gaussian Splatting. Un agent immobilier se promène dans une maison en enregistrant une vidéo standard au smartphone. Tu dois processer cette vidéo brute pour créer une visite virtuelle 3D photoréaliste et entièrement navigable, avec des reflets et un éclairage dynamiques. Pendant quelques années, l'approche standard, c'était les Neural Radiance Fields, ou NeRFs. Un NeRF cartographie l'espace en utilisant un neural network implicite. Pour générer une image, il lance un rayon mathématique à travers la scène et fait une query au neural network sur des centaines de points le long de ce rayon pour demander quelle couleur et quelle densité s'y trouvent. Ça donne de superbes résultats, mais faire une query sur un deep neural network pour des millions de pixels, c'est extrêmement lent. Le 3D Gaussian Splatting abandonne le neural network implicite. À la place, il utilise une structure explicite de type point cloud. Le pipeline commence avec un algorithme standard de structure-from-motion qui analyse la vidéo du smartphone pour tracker la position de la caméra et construire un point cloud 3D sparse de la maison. L'algorithme remplace ensuite chaque point de ce cloud par un 3D Gaussian. Tu peux voir un 3D Gaussian comme un ellipsoïde coloré et semi-transparent. Chaque Gaussian contient un set spécifique de paramètres. Il a une coordonnée centrale dans l'espace 3D. Il a une matrice de covariance, qui dicte son scale et sa rotation, l'étirant en un disque plat ou en un long cigare selon la géométrie qu'il représente. Il a une valeur d'opacité. Enfin, il stocke les données de couleur en utilisant les Spherical Harmonics. Voici l'idée clé. Les Spherical Harmonics sont des fonctions mathématiques qui encodent la couleur de manière directionnelle. Quand tu regardes le Gaussian sous un certain angle, il peut refléter une fenêtre lumineuse. Sous un autre angle, il montre la texture sombre d'une lame de parquet. C'est ce qui donne à la visite virtuelle finale son éclairage photoréaliste, dépendant du point de vue. Le point cloud initial est brouillon, donc le système entre dans une boucle d'optimisation. Il projette, ou splat, ces 3D Gaussians sur une vue caméra 2D pour faire le render d'une image. Il soustrait ce render de la vraie photo prise par l'agent immobilier pour calculer l'erreur. L'algorithme utilise ensuite cette erreur pour mettre à jour les paramètres des Gaussians. Pendant cette optimisation, le système gère activement la population de Gaussians. Si un blob devient trop grand et recouvre trop de détails, l'algorithme le split en plus petits morceaux. Si une zone avec des textures complexes a besoin de plus de résolution, l'algorithme clone les Gaussians existants pour augmenter la densité. Si un blob devient complètement transparent ou inutile, le système le supprime. Parce que la scène finale est entièrement composée de data points explicites, son render est exceptionnellement rapide. Le hardware graphique trie simplement les ellipsoïdes de l'arrière vers l'avant et blend leurs couleurs pour former l'image finale. La grande percée du 3D Gaussian Splatting, c'est de prouver qu'un cloud chaotique de blobs mathématiques explicites peut capturer une lumière et une géométrie complexes bien plus vite qu'un neural network dense. Merci de m'avoir écouté. Prenez soin de vous tous.

Bonjour, c'est Alex de DEV STORIES DOT EU. OpenCV : Computer Vision Deep Dive, épisode 20 sur 20. Pendant des décennies, les algorithmes de computer vision étaient totalement passifs. Ils pouvaient tracer une bounding box autour d'une tasse sur une table, mais ça s'arrêtait là. Aujourd'hui, le système ne se contente pas de voir la tasse : il utilise ces données visuelles pour l'atteindre et l'attraper. Le pont entre la vision et l'action, c'est la Vision-Action Loop, pilotée par l'Agentic AI. Avant de rentrer dans la mécanique, on doit tracer une ligne claire entre deux technos qui se ressemblent mais qui font un job totalement différent. Un Vision-Language Model standard, ou VLM, est descriptif. Tu lui donnes une capture d'écran, et il te sort du texte pour te dire ce qu'il y a à l'écran. Un modèle Vision-Language-Action, ou VLA, est exécutif. Tu donnes au VLA une capture d'écran et un goal, et il te sort des commandes exécutables. Il ne se contente pas de décrire l'UI ; il interagit activement avec. L'Agentic AI transforme un pipeline de vision en un organe sensoriel pour un moteur de prise de décision. Ça tourne dans un cycle continu : percevoir, raisonner et agir. D'abord, le système prend une observation visuelle de son environnement actuel. Ça peut être le flux vidéo d'un robot ou une capture en temps réel d'un bureau d'ordinateur. Ensuite, l'agent traite cet état visuel avec un prompt ou un goal spécifique. Il analyse les relations spatiales, lit le texte et identifie les éléments interactifs. Quand le modèle identifie un élément, il mappe la compréhension sémantique — le fait de savoir qu'un rectangle vert spécifique est un bouton submit — vers un espace de coordonnées géométriques. Enfin, au lieu de renvoyer une description, le modèle génère un payload d'action. C'est souvent une commande structurée qui contient des coordonnées d'écran exactes, un ajustement de moteur hardware, ou un API call. Une fois l'action exécutée, l'environnement change. L'agent prend une nouvelle observation visuelle, vérifie si l'action précédente a réussi, et calcule la prochaine étape. Voici le point clé. Les données visuelles ne sont plus une voie sans issue ; c'est le mécanisme de grounding pour l'utilisation autonome d'outils. Prenons un scénario concret avec un assistant comptable numérique automatisé. Le goal, c'est d'autoriser un paiement. L'agent commence par capturer l'écran. Le modèle de vision traite une facture PDF scannée, en extrayant le nom du fournisseur et le montant total. Le moteur de raisonnement sait qu'il doit logger ces données. Il génère une action pour déplacer la souris vers l'icône du logiciel de compta sur la barre des tâches et cliquer dessus. L'écran se met à jour. L'agent prend une autre observation visuelle pour vérifier que l'application est bien ouverte. Il scanne la nouvelle interface, localise le champ d'autorisation de paiement, mappe l'emplacement visuel vers les coordonnées de l'écran, tape le montant, et clique sur le bouton submit. Le pipeline de vision renvoie constamment des mises à jour d'état à l'agent pour qu'il sache exactement quand exécuter la prochaine action, et surtout, quand s'arrêter. La computer vision a évolué, passant d'un outil d'analyse standalone à la couche sensorielle pour les systèmes autonomes. Si ton pipeline se contente d'analyser une image et s'arrête, tu n'utilises que la moitié de la techno. Comme c'est notre dernier épisode, je t'encourage à explorer la documentation officielle des modèles VLA, à essayer de builder une feedback loop basique hands-on, ou à visiter devstories dot eu pour suggérer des sujets pour notre prochaine série. C'est tout pour aujourd'hui. Merci d'avoir écouté, et keep building !