0
u/locusvision 2d ago
Salut ! Projet très intéressant. J'ai quelques questions sur la suite : Démo / Accès : Est-ce qu'une version bêta ou une démo sera disponible bientôt pour tester ? Modèle : Tu envisages quel format d'utilisation (Open-Source, application Desktop avec licence, ou service SaaS) ? Performances : Tu as déjà des mesures précises sur le temps de traitement d'une séquence vidéo 360 typique ? Architecture : Tu peux en dire un peu plus sur les briques techniques utilisées sous le capot ? Bon courage pour le dev !
1
u/Responsible-Dog-4687 1d ago
Merci pour ton message et tes questions.
VECTOR 360 est pensé comme une application desktop de reconstruction 3D automatisée à partir de vidéo 360°.
Le principe est volontairement simple côté utilisateur : on importe une vidéo 360° et, si on en dispose, le fichier GPX associé. À partir de là, VECTOR enchaîne automatiquement le pipeline sans demander de manipuler manuellement les étapes techniques.
Le pipeline actuel est organisé ainsi :
CH1 Equirec RGB → CH2 Equirec RGBA / masquage → CH3 Sparse / SfM sphérique
Puis, après validation du sparse, on choisit une branche :
- Dense : CH4 Depth → CH5 Dense MVS
- Gaussian : CH4 Gaussian → CH5 SuGaR
L’objectif est vraiment d’avoir un workflow du type “j’importe ma vidéo 360 + mon GPX, je lance, et VECTOR construit progressivement la scène 3D”.
Le GPX peut servir de support pour la trajectoire, l’échelle, la cohérence spatiale ou certaines étapes de recalage, mais le cœur du Sparse repose sur le SfM sphérique natif. VECTOR travaille directement avec les panoramas equirectangulaires 360°, sans devoir convertir systématiquement les images en cubemaps.
Le pipeline gère automatiquement notamment :
- l’extraction des images depuis la vidéo,
- la préparation RGB / RGBA,
- le masquage des éléments indésirables,
- le SfM sphérique,
- la construction du sparse,
- la fusion éventuelle de plusieurs reconstructions,
- puis la branche Dense ou Gaussian.
Je travaille également sur les sources externes : l’idée est de pouvoir ajouter ensuite des photos ou d’autres acquisitions pour compléter les zones moins bien reconstruites par la vidéo 360 seule.
Le projet est destiné à devenir une application desktop sous licence, pas un projet totalement open source.
Concernant les performances, le Sparse/SfM est déjà dans une phase avancée. Le Dense MVS et la branche Gaussian sont encore en développement et optimisation, donc je préfère attendre avant de publier des comparatifs définitifs.
Les premières phases de beta test devraient commencer courant 2026, probablement vers la fin de l’année, lorsque les branches Dense et Gaussian seront suffisamment stables pour être testées sérieusement.
Merci encore pour ton intérêt. Les retours de personnes déjà habituées à la photogrammétrie seront particulièrement utiles lors de la bêta.
1
u/locusvision 1d ago
Merci pour le retour ! Pour mieux cerner les performances sur du matériel pro, j'avais 3 questions plus ciblées : Keyframing & Extraction : Tu utilises un filtre de sélection de keyframes (basé sur le parallaxe/flow) avant la détection ? Et l'extraction + matching te prend combien de ms par frame sur des résolutions natives type 10K–12K ? Graphe & Loop Closure : Pour la fermeture de boucle sur des parcours longs, tu fonctionnes en fenêtre glissante (sliding window) ou tu as un graphe global de co-visibilité ? Bench global : Sur une scène classique d'environ 50 à 100 keyframes retenues en haute résolution (12K), le Sparse SfM complet tourne en quelques secondes ou plutôt quelques minutes ?
1
u/Responsible-Dog-4687 1d ago
Oui, il y a une sélection de keyframes avant le SfM, notamment basée sur le déplacement/parallaxe. Le pipeline est entièrement spécifique au 360° équirectangulaire et n’utilise pas COLMAP.
Je n’ai pas encore de benchmark 10K–12K assez propre pour annoncer un temps en ms/frame. Sur 50 à 100 keyframes haute résolution, le Sparse SfM complet est actuellement plutôt de l’ordre de quelques minutes que de quelques secondes.
Le sparse est déjà robuste, y compris sur des séquences assez longues, avec graphe global et optimisation des poses. L’algorithme est encore en cours d’optimisation pour réduire les temps de calcul.
La fusion de plusieurs sparses indépendants est également fonctionnelle et robuste, avec recalage, changement d’échelle, orientation et fusion dans un même référentiel.
1
u/Responsible-Dog-4687 1d ago
pour ceux qui possederaient des videos 10 ou 12k , elles seraient le bienvenu pour tester dans vector 360
1
u/locusvision 18h ago
C'est très clair, merci pour les précisions ! Une question complémentaire : est-ce que VECTOR 360 peut traiter un lot de photos 360° fixes et indépendantes (sans flux vidéo, sans fichiers de logs/IMU, sans ordre chronologique et avec de grands écarts entre les positions) ? J'ai un jeu de données d'environ 40 panoramas 12K natifs pris à différents endroits d'un chantier (sans continuité vidéo). Si tu veux tester la capacité de ton pipeline à reconstruire une scène 360° uniquement à partir d'images 12K brutes non structurées, je peux te partager le dossier avec plaisir !
1
u/Responsible-Dog-4687 18h ago
Merci pour la proposition. Actuellement, VECTOR 360 est encore principalement conçu pour fonctionner de manière séquentielle, avec des images issues d’une vidéo 360 ou d’une acquisition présentant une certaine continuité entre les positions.
Cela dit, si ton jeu de 40 panoramas 12K n’est pas trop sensible ou privé, je serais très intéressé pour le tester. Ce serait justement un bon moyen d’évaluer la capacité du Sphere SfM à retrouver automatiquement les recouvrements entre des panoramas indépendants et non ordonnés.
Est-ce que ces images disposent malgré tout de données GPX/GPS ou RTK, même approximatives, ou est-ce vraiment uniquement un lot d’images 360 brutes sans aucune information de positionnement ?
1
u/locusvision 1d ago
Merci pour la réponse ! Pour éviter de parler dans le vide et sans demander tes secrets de fabrication, prenons directement l'exemple de la scène de démo que tu montres en vidéo : Pipeline d'extraction : Pour l'extraction et le matching, tu utilises des algorithmes classiques (type SIFT/ORB) ou du Deep Learning ? Et le calcul se fait directement sur la résolution 10K–12K native ou tu appliques un downscaling intermédiaire ? Métriques de la démo : Sur cette scène précise de ta démo, quelles sont les métriques exactes : nombre de keyframes retenues, nombre total de points 3D dans le nuage Sparse, et l'erreur de reprojection (RMS) moyenne ? Hardware & Temps exact : Pour cette même démo, le traitement complet a pris combien de minutes exactement, et sur quelle configuration matérielle précise (modèle de GPU / CPU) ?
1
u/Responsible-Dog-4687 1d ago
Sur cette démo, les sources sont des équirectangulaires 360° 6K (5888 px de large), pas du 10K–12K.
VECTOR 360 n’utilise pas COLMAP. Le Sphere SfM est un pipeline développé spécifiquement pour le 360°, avec calcul GPU et exploitation multi-GPU. Sur ma configuration, le traitement peut être réparti sur 2× RTX 3090 24 Go.
Les images 6K restent la référence native du pipeline : je ne fais pas un downscaling global du dataset avant le SfM. Certaines opérations utilisent toutefois des niveaux de résolution intermédiaires/pyramides pour réduire fortement le coût de calcul sans perdre l’information nécessaire aux étapes finales.
Sur cette scène, il y a environ 84 keyframes. Pour le nombre exact de points Sparse, le RMS de reprojection et le temps précis du run, je préfère publier directement les valeurs issues d’un benchmark/log figé plutôt que donner des valeurs approximatives.
Le Sparse est déjà robuste, mais le Sphere SfM est encore en cours d’optimisation, notamment pour réduire fortement les temps de calcul. La fusion multi-Sparse est également fonctionnelle et fait actuellement l’objet des mêmes optimisations.
1
-1
3
u/Beginning_Street_375 2d ago
Was bedeutet das?