Sebastian Beyer voulait simplement entraîner son premier Gaussian Splat avec un MacBook Air ; le calcul a duré 3,5 heures, et cette attente a suffi à lancer une expérience qui, quatre semaines plus tard, s’appelait Scantic et tenait entièrement dans l’iPhone.12
Le récit se raconte trop facilement comme celui d’un pipeline devenu « 1 000 fois plus rapide » avant d’être miniaturisé dans un téléphone ; les nombres publiés dessinent quelque chose de plus sobre. Entre 3,5 heures et moins d’une minute, le test initial gagne déjà plus de 210×, tandis qu’un autre essai partagé par Beyer demande 76,2 secondes à un iPhone 17 pour 5 000 itérations, 416 282 splats et 202 images.2
Le saut intéressant tient ailleurs : le workflow commencé avec COLMAP et Brush, deux outils du monde desktop, finit comme boucle complète dans la poche, depuis la capture jusqu’à l’inspection de la reconstruction.2
3,5 heures
Le pipeline de départ ressemblait aux essais 3DGS classiques, où les photographies doivent d’abord être reliées aux positions des caméras avant que les Gaussiennes soient ajustées jusqu’à reproduire les vues sources.5
L’implémentation de référence publiée en 2023 par Kerbl, Kopanas, Leimkühler et Drettakis part d’un nuage clairsemé issu de la calibration des caméras ; position, échelle, orientation, opacité et couleur décrivent ensuite chaque Gaussienne, que l’entraînement ajuste jusqu’à rapprocher les images rendues des photos d’entrée.5
Beyer raconte avoir commencé avec COLMAP pour la reconstruction géométrique et Brush pour le splatting, avec ce but volontairement absurde fixé dès le départ : « 1 000× plus vite ».2
Quatre semaines plus tard, il dit avoir remplacé cette chaîne par un pipeline personnalisé exécuté directement dans l’iPhone, sans LiDAR ni cloud.2 La fiche App Store décrit le même périmètre : capture caméra, génération du splat, traitement et exploration 3D restent dans l’appareil, sans compte nécessaire ni calcul distant.1
Il faut lire ces mesures pour ce qu’elles sont, à savoir les relevés du développeur pendant son expérience ; elles ne constituent pas une campagne contrôlée couvrant plusieurs téléphones, scènes et réglages.
Pas le premier
Scantic arrive dans un terrain déjà occupé, puisque le Gaussian Splatting mobile et son entraînement local existaient avant son lancement.
Scaniverse 3.0 effectuait déjà tout le traitement dans l’appareil en mars 2024, à partir de l’iPhone 11.3 Niantic expliquera ensuite avoir ramené l’entraînement autour de la minute alors que son premier pipeline réclamait environ 20 Go de mémoire.4
Cette antériorité change l’angle, car Scantic ne marque pas la disparition soudaine du cloud : Scaniverse avait déjà déplacé cette partie du workflow dans le téléphone deux ans auparavant.36
La comparaison dit autre chose : ce travail d’optimisation, autrefois mené par une équipe de recherche et de produit, peut désormais être repris à une autre échelle par un développeur indépendant, jusqu’à devenir une app gratuite de 18,4 Mo distribuée dans l’App Store.1
Niantic a mieux documenté son propre travail : l’équipe Scaniverse visait environ 1 Go de RAM, réutilisait sa détection de caractéristiques et l’estimation multi-vues de la profondeur afin d’initialiser les Gaussiennes, puis compressait les résultats en SPZ pour diminuer leur poids.4
Côté Scantic, le breakdown public reste bien plus mince : Beyer donne le point de départ, le résultat et plusieurs paramètres de tests, sans publier assez d’algorithmes intermédiaires pour attribuer honnêtement chaque gain à telle ou telle technique. Compléter soi-même la liste reviendrait à fabriquer un postmortem qui n’existe pas.
Tout pendant la capture
Un choix visible réduit toutefois l’espace du problème, puisque la version actuelle de Scantic repose d’abord sur une capture faite dans l’application.
Dans la discussion de lancement, Beyer précise que l’import d’images déjà prises n’est pas encore disponible ; il le juge techniquement possible, probablement plus lent que la capture intégrée, et envisage de l’ajouter plus tard.2
Cette contrainte compte, parce qu’un pipeline général doit retrouver les relations entre des images dont il ignore la trajectoire, tandis que l’app qui contrôle la capture peut préparer dès le départ les informations utiles aux étapes suivantes. Les sources ne permettent pas d’en déduire l’algorithme précis de Scantic ; elles montrent seulement pourquoi entraîner n’importe quel dataset et bâtir un scanner mobile de bout en bout ne posent pas exactement le même problème.
L’absence de LiDAR va dans le même sens : Scantic exploite les images de la caméra, ce qui évite de réserver le procédé aux iPhone Pro équipés du capteur de profondeur.12
Une minute, parfois
La formule « sous une minute » se brouille dès que l’on compare appareils, scènes et paramètres.
Beyer a partagé le cas d’une statue capturée en 202 images : avec le preset rapide, l’iPhone 17 demande 76,2 secondes, effectue 5 000 itérations et produit 416 282 splats.2 Dans le même fil, l’iPhone 13 Pro fonctionne correctement chez un utilisateur, alors qu’un autre, équipé d’un iPhone 12 Pro, voit l’entraînement terminer presque immédiatement sans reconstruction exploitable.2
Beyer attribue ce dernier cas à la mémoire disponible : selon lui, l’iPhone 12 Pro se situe à la limite de ce que la version 1.0 sait gérer fiablement, et le travail en cours porte notamment sur un usage mémoire plus faible.2
Cette limite renseigne mieux que le multiplicateur 1 000× : le goulot d’étranglement mobile s’est déplacé plutôt qu’il n’a disparu. Une fois le cloud écarté, mémoire disponible, taille de scène, nombre d’images et budget d’itérations deviennent des choix de produit visibles.
Le téléphone comme contrainte
Le 3DGS original avait marqué les esprits en combinant représentation explicite, optimisation et rendu temps réel de haute qualité.5 Moins de trois ans après, la question s’est déplacée vers l’ensemble de la reconstruction : combien d’étapes peut-on faire tenir dans les contraintes d’un appareil mobile ?
Scaniverse avait donné une première réponse industrielle en comprimant mémoire, initialisation et stockage jusqu’au téléphone.4 Scantic suit une trajectoire plus artisanale, partie d’un MacBook qui chauffe et arrivée, après abandon progressif du pipeline desktop initial, à un outil distribué dans l’App Store.12
Cette trajectoire constitue peut-être la partie la plus reproductible du projet. Rien ne démontre qu’un iPhone serait mystérieusement 1 000 fois plus rapide qu’un MacBook ; l’expérience montre plutôt qu’en changeant le pipeline entier, Beyer finit par calculer un problème différent de celui qui occupait son Mac au départ.
Les gros gains viennent souvent de ce déplacement, lorsque plusieurs étapes cessent d’être exécutées de la même façon et que l’architecture du workflow change davantage que la vitesse d’une instruction isolée.