Vision 3D on Boris Dupoux

De la vidéo tournée à la main à la photogrammétrie et au Gaussian Splatting

Thu, 01 Oct 2026 00:00:00 +0000

Contexte

Les sites intérieurs sont souvent documentés avec une caméra sur stabilisateur tenue à la main plutôt qu’avec un scanner de qualité topographique. L’objectif était de transformer ces vidéos en livrables 3D exploitables (nuage dense, maillage texturé, orthovues en plan et en élévation, scène Gaussian Splatting et exports web légers), sans aucune étape manuelle entre la captation et le résultat. La chaîne de traitement s’exécute nativement sous Windows sur une RTX 5090 (Blackwell, sm_120) partagée avec d’autres charges GPU de longue durée ; elle ne doit donc jamais les préempter.

Approche

flowchart TB
 A["inbox/projet/vidéos + fichier GO"] --> B["Extraction d'images clés
recouvrement par flot optique + netteté"]
 B --> C["SfM COLMAP 4.2.1
SIFT, mapper global"]
 C --> D{"Contrôle qualité : enregistrement, reprojection,
continuité de trajectoire"}
 D -- échec --> C2["Repli : mapper incrémental"] --> D
 D -- succès --> E["OpenMVS 2.4 (build sm_120)
densification, maillage, raffinement, texture"]
 E --> F["Alignement ortho
gravité, sol par RANSAC, lacet Manhattan"]
 F --> G["Rendus Blender
orthos, axonométries, orbite"]
 E --> H["Entraînement gsplat
stratégie MCMC ou par défaut"]
 G --> I["Exports web
Potree, GLB, SOG"]
 H --> I
 I --> J["outbox : livrables, report.json, STATUS"]

Méthodes

Sélection d’images clés guidée par le recouvrement. Un suivi KLT associé à une similitude estimée par RANSAC évalue le recouvrement avec la dernière image clé. Une image est émise lorsque le recouvrement descend sous 0,80, que le suivi est perdu ou qu’une limite de temps est atteinte. Le candidat le plus net (variance du laplacien) est celui retenu.
SfM avec contrôle qualité explicite. Le mapper global de COLMAP est rapide mais non déterministe. Lors des essais, il a produit des reconstructions qui satisfaisaient les critères d’enregistrement et de reprojection tout en étant géométriquement incohérentes. Un contrôle de continuité de trajectoire (sauts supérieurs à 25 fois le pas médian de la caméra) déclenche un repli automatique sur le mapper incrémental. En dessous de 20 points par image, l’étape échoue.
Fiabilisation du MVS. Le binaire Windows officiel d’OpenMVS ne contient que des noyaux sm_89 ; il a donc été recompilé pour sm_120. La ROI objet est désactivée pour les pièces car elle rognait le nuage. Le raffinement est abandonné lorsqu’il diverge, et le nivellement des coutures (qui noircissait des faces) est désactivé.
Orthovues prêtes pour la métrique. L’axe vertical est déduit des orientations des caméras. Un plan de sol estimé par RANSAC fixe z = 0 et un histogramme des azimuts des normales aux murs (modulo 90°) fixe le lacet Manhattan. Une référence optionnelle à deux points fixe l’échelle. La transformation 4×4 est conservée afin d’être réappliquée au maillage et au splat.
Gaussian Splatting. gsplat 1.6.0 a été compilé pour sm_120 avec CUDA 13 sous MSVC, ce qui a nécessité des correctifs locaux. L’entraînement utilise la stratégie MCMC avec un budget de gaussiennes et se replie sur la stratégie 3DGS par défaut lorsque MCMC diverge.
Exploitation. Les projets démarrent en mode dossier surveillé dès qu’un fichier GO apparaît. Les étapes peuvent être reprises ou refaites. Une garde GPU attend qu’une quantité suffisante de VRAM soit libre pendant une période stable, sérialise les étapes GPU via un fichier verrou et enregistre le pic de VRAM par étape dans report.json. Un contrôle qualité dégradé produit un statut DONE_WITH_ALERTS plutôt qu’un succès silencieux.

Résultats

Premier déploiement réel : cinq emplacements dans un showroom commercial, une vidéo 4K tournée à la main par emplacement, traitée sans intervention en environ 30 minutes par emplacement.

Emplacement	Images	SfM enregistrées / points / reproj.	Nuage dense	PSNR / SSIM du splat
1	116	116/116 · 21 458 · 1,49 px	1,40 M	23,2 / 0,86
2	103	103/103 · 18 972 · 1,75 px	1,23 M	20,6 / 0,81
3	47	47/47 · 13 167 · 1,17 px	1,26 M	23,1 / 0,86
4	121	121/121 · 11 970 · 1,34 px	1,99 M	21,9 / 0,85 (stratégie par défaut)
5	64	64/64 · 12 106 · 1,48 px	0,91 M	21,8 / 0,83

Toutes les images ont été enregistrées pour chaque emplacement. L’erreur de reprojection était de 1,17–1,75 px.
Pics de VRAM mesurés : SIFT +1,3 Go, appariement +1,6 Go, texturation +0,5 Go, Blender +5,4 Go, et splatting avec 3 M de gaussiennes à 1920 px +25,2 Go.
Le build OpenMVS sm_120 a densifié le test de validation rapide synthétique en 17 s. Le repli CPU a pris environ 40 min.
L’analyse des métadonnées a révélé des vitesses d’obturation de 1/50–1/100 s (environ 14 px de flou de bougé en 4K) ainsi qu’une sensibilité ISO et une balance des blancs automatiques. La compensation d’exposition de gsplat (ppisp) n’a apporté aucun gain (PSNR 20,5 contre 20,6). La limite de qualité tient à la captation, pas au solveur.

Limites & suite

Un PSNR d’à peine plus de 20 reflète le flou de bougé et l’exposition automatique. Le protocole de captation impose désormais une vitesse d’obturation de 1/250–1/500 s, une exposition et une balance des blancs verrouillées, ainsi qu’un passage dédié au sol.
La fusion de vidéos provenant d’emplacements différents a provoqué de faux appariements et un modèle incohérent ; chaque emplacement est donc traité séparément.
Les sols carrelés sombres et brillants se reconstruisent mal. L’alignement Manhattan n’est pas encore fiable en présence de mobilier et de vitrages.
Les étapes CPU constituent le goulot d’étranglement sur une machine virtuelle à 4 vCPU.
Prévu : comparaison avec une suite de photogrammétrie commerciale sur les mêmes images, et nouvel essai du raffinement de maillage avec le build sm_120.

Stack technique

Python 3.11 · OpenCV · Open3D · NumPy · COLMAP 4.2.1 · OpenMVS 2.4 · gsplat 1.6.0 · PyTorch 2.14 (CUDA 13) · Blender 5.2 · FFmpeg · PotreeConverter · glTF-Transform · splat-transform

Analyse vidéo géolocalisée et mesure des distances entre objets

Thu, 01 Jan 2026 00:00:00 +0000

Contexte

Les sites industriels sont souvent couverts par des caméras fixes dont les images ne sont consultées qu’après un incident et ne produisent aucune donnée exploitable. L’objectif était de transformer les caméras existantes, ainsi que des prises de vue ponctuelles par drone, en instrument de mesure : pour chaque objet détecté, une position en latitude/longitude et des distances métriques plutôt qu’une boîte en pixels.

La difficulté tient à trois raisons. Une caméra unique ne donne pas de profondeur, si bien que l’échelle de la scène doit être inférée. La méthode de géoréférencement habituelle, une homographie du plan du sol, suppose un sol plat et échoue silencieusement pour les objets surélevés ou les terrains irréguliers. Enfin, la vidéo haute résolution est coûteuse à traiter, et le raccourci courant consistant à réduire l’image à 640 px élimine le détail géométrique dont dépendent les positions au sol.

Approche

flowchart TB
 A["Source vidéo
fichier · RTSP · séquence drone (jusqu'à 3840×2160)"] --> B["Détecteur d'objets en résolution native
détection · segmentation · pose · OBB"]
 A --> C["Modèle de profondeur monoculaire métrique
carte de profondeur"]
 B --> D["Suivi multi-objets
modèle de mouvement + association"]
 B --> E["Profondeur par objet
pixels du masque, rejet des aberrants"]
 C --> E
 E --> F["Lancer de rayon
rayon pixel + profondeur métrique + pose caméra"]
 F --> G["Position WGS84
MNT optionnel pour l'altitude du sol"]
 E --> H["Distances 3D
entre masques · le long des trajectoires"]
 D --> H
 G --> I["Stockage SQLite
détections · pistes · trajectoires GPS"]
 H --> I
 I --> J["Analyses
zones · flux · superposition sur orthophoto"]

Méthodes

Détection. Un détecteur de la famille YOLO, en plusieurs tailles de modèle, dans quatre modes (détection, segmentation, pose, boîtes orientées). L’inférence s’exécute en résolution native, sans imgsz imposé. La segmentation est le mode par défaut, car les masques fournissent des échantillons de profondeur plus propres que les boîtes. Les poids PyTorch, ONNX, TensorRT et CoreML sont acceptés (CUDA et Apple MPS).
Profondeur monoculaire. Un modèle de profondeur monoculaire métrique prédit une carte de profondeur, rééchantillonnée à la taille de l’image. La profondeur de chaque objet est une estimation robuste sur les pixels de son masque, après rejet des valeurs aberrantes. Une étape de validation compare la profondeur prédite à des zones de référence dont la distance est connue, afin de détecter une dérive de calibration.
Géolocalisation par lancer de rayon. Un rayon est lancé depuis le centre de la caméra à travers le pixel de l’objet et arrêté à la profondeur métrique de celui-ci. Le point obtenu est converti du repère caméra vers un repère local Nord-Est-Bas, puis en WGS84. Contrairement à une homographie, cette méthode ne suppose pas un sol plat. Un MNT optionnel fournit l’altitude du sol. Les positions peuvent être superposées à une orthophoto géoréférencée pour un contrôle visuel.
Suivi. Un module de suivi multi-objets sur mesure, avec un modèle de mouvement, une association tenant compte de la confiance et une étape de fusion des pistes qui relie les fragments selon des seuils d’intervalle, de cap et de vitesse. Lorsque la profondeur est disponible, chaque piste conserve une trajectoire 3D, dont sont déduites la distance parcourue et la vitesse en m/s.
Distances entre objets. Fonction consolidée ultérieurement dans une bibliothèque de vision réutilisable. Deux objets segmentés sont rétroprojetés en 3D, et la distance minimale point à point est retournée. Des masques qui se chevauchent sont considérés comme en contact. Une simulation de Monte-Carlo perturbe la profondeur, la focale et les positions des pixels pour fournir un écart-type et un intervalle à 95 %. L’appartenance à une zone repose sur la part du masque située dans la zone, avec hystérésis, plutôt que sur un test du point central.
Ingénierie. La configuration permet une répartition sur deux GPU (détection sur un périphérique, estimation de la profondeur sur l’autre), la découverte et l’enregistrement de flux RTSP, ainsi que le traitement de plusieurs caméras en parallèle.

Résultats

Mesures effectuées sur une seule NVIDIA RTX 5090. Le banc d’essai de détection ne couvre que la détection et le suivi, profondeur désactivée.

Configuration	Vidéo	Débit	Sortie
Plus gros détecteur, batch 1	3840×2160, 50 fps, 3 301 images	5,1 fps	320 217 détections, 1 941 pistes
Plus petit détecteur, batch 1	3840×2160, 50 fps	13,0 fps	158 989 détections, 908 pistes
Plus gros détecteur, batch 1	2304×1296, 15 fps, 5 000 images	17,9 fps	73 502 détections, 2 706 pistes
Plus petit détecteur, batch 1	2304×1296, 15 fps	39,0 fps	51 890 détections, 1 499 pistes
Chaîne complète (détection + profondeur + suivi + stockage)	2304×1296, 300 images	2,02 fps	12,3 détections par image

Sur l’exécution de la chaîne complète, l’estimation de la profondeur a pris 117,6 s sur 148,3 s au total (environ 80 %), et la détection 20,9 s. Le goulot d’étranglement est l’estimation de la profondeur, et non le détecteur. Sur des vidéos 4K, le plus gros détecteur tourne environ dix fois plus lentement que le temps réel. Cela convient à l’usage visé, à savoir l’analyse d’archives enregistrées et non l’alerte en direct.

Limites & suite

Aucune précision de géolocalisation n’a encore été mesurée par rapport à une vérité terrain levée. L’étape de lancer de rayon a été ajoutée après les mesures de temps ci-dessus ; son coût n’y est donc pas inclus.
L’échelle métrique dépend du modèle de profondeur ainsi que de la pose et des paramètres intrinsèques de la caméra. Les erreurs d’inclinaison ou de focale se répercutent directement sur les positions au sol.
Le modèle de profondeur prédit à sa propre résolution interne : le détail fin de la profondeur reste limité, même lorsque la détection s’exécute en 4K.
Suite : une étude de précision avec des cibles levées au GNSS, le profilage de la répartition sur deux GPU, et la mesure de la justesse des intervalles de distance Monte-Carlo sur des objets à écartements connus.

Stack technique

Python · PyTorch · OpenCV · NumPy · SciPy · pyproj · rasterio · SQLite · CUDA · Apple MPS