MapAnything : Reconstruction 3D Métrique Feed-Forward — Pourquoi NeRF Est Déjà Obsolète

La Reconstruction 3D Change de Paradigme

Pendant des années, reconstruire une scène en 3D à partir de photos signifiait attendre. Attendre que COLMAP aligne les caméras. Attendre que NeRF optimise des centaines de milliers d’itérations. Attendre que le Gaussian Splatting converge. Chaque scène exigeait sa propre optimisation, de quelques minutes à plusieurs heures selon la complexité.

MapAnything, développé par Meta et Carnegie Mellon University, casse ce paradigme. Un seul modèle transformer, entraîné une fois, qui prend des images en entrée et produit directement la géométrie 3D métrique en sortie. Pas d’optimisation par scène. Pas de fine-tuning. Une seule passe forward.

Ce n’est pas un gain incrémental. C’est un changement de catégorie : on passe d’un problème d’optimisation à un problème de prédiction.

Architecture : Un Transformer Multi-Vue avec UniCeption

Le coeur de MapAnything repose sur une architecture modulaire construite avec UniCeption, une bibliothèque de composants interchangeables pour les réseaux end-to-end de vision 3D. Le modèle est défini dans mapanything/models/mapanything/model.py et hérite de PyTorchModelHubMixin pour une intégration directe avec Hugging Face :

from uniception.models.encoders import encoder_factory, ViTEncoderInput
from uniception.models.info_sharing.alternating_attention_transformer import (
    MultiViewAlternatingAttentionTransformer,
)
from uniception.models.prediction_heads.adaptors import (
    PointMapPlusRayDirectionsPlusDepthWithConfidenceAndMaskAdaptor,
    CamTranslationPlusQuatsAdaptor,
)

L’architecture se décompose en trois étages :

1. Encodeur Vision (DINOv2)

Chaque image est encodée indépendamment par un ViT pré-entraîné (DINOv2), résolution d’entrée 518x518 pixels. L’encodeur extrait des features denses par patch de 14x14 pixels. C’est la partie “perception” : transformer les pixels en représentations sémantiques.

2. Partage d’Information Multi-Vue

C’est ici que MapAnything se distingue des approches monoculaires. Les features de toutes les vues sont fusionnées via un transformer à attention alternée (MultiViewAlternatingAttentionTransformer). Trois variantes de partage d’information sont disponibles dans le code :

• Attention alternée : self-attention intra-vue puis cross-attention inter-vues, en alternance
• Cross-attention pure : chaque vue attend sur toutes les autres
• Attention globale : concaténation de toutes les vues, attention dense

L’attention alternée est le choix par défaut et le plus efficace en mémoire. Elle permet au modèle de raisonner sur la cohérence géométrique entre les vues sans exploser le budget mémoire.

3. Têtes de Prédiction

Le modèle prédit simultanément une batterie de sorties géométriques via des adaptateurs spécialisés :

• PointMapAdaptor : points 3D dans le repère monde (H x W x 3 par vue)
• CamTranslationPlusQuatsAdaptor : pose caméra en translation + quaternion
• PointMapPlusRayDirectionsPlusDepthWithConfidenceAndMaskAdaptor : la version complète avec directions de rayons, profondeur, confiance par pixel et masque de validité

Le résultat est un nuage de points 3D dense, métrique (en mètres, pas en unités arbitraires), avec des poses caméra cohérentes entre toutes les vues.

Feed-Forward vs NeRF : Ce Qui Change Vraiment

Le Problème avec l’Optimisation Par Scène

NeRF et ses dérivés (Instant-NGP, 3D Gaussian Splatting) fonctionnent ainsi : pour chaque nouvelle scène, on initialise un modèle vierge et on l’optimise pendant N itérations pour qu’il reproduise les images d’entrée. C’est élégant mathématiquement, mais catastrophique en pratique :

• Temps : 5 à 60 minutes par scène, même avec les accélérations modernes
• Données : il faut typiquement 50 à 200 images bien réparties
• Poses caméra : nécessaires a priori (COLMAP en pré-traitement, encore 10-30 minutes)
• Pas de généralisation : le modèle optimisé pour la scène A ne sait rien de la scène B

L’Approche Feed-Forward

MapAnything apprend la géométrie 3D de manière générale à l’entraînement, puis l’applique en inférence sans optimisation. Voici l’API d’inférence réelle :

from mapanything.models import MapAnything
from mapanything.utils.image import load_images

model = MapAnything.from_pretrained("facebook/map-anything").to("cuda")
views = load_images("path/to/your/images/")

predictions = model.infer(
    views,
    memory_efficient_inference=True,
    use_amp=True,
    amp_dtype="bf16",
    apply_mask=True,
    mask_edges=True,
)

Quelques secondes, pas quelques heures. Et les sorties sont immédiatement exploitables :

for pred in predictions:
    pts3d = pred["pts3d"]           # (B, H, W, 3) — points 3D monde
    depth_z = pred["depth_z"]       # (B, H, W, 1) — profondeur Z
    intrinsics = pred["intrinsics"] # (B, 3, 3) — calibration récupérée
    camera_poses = pred["camera_poses"]  # (B, 4, 4) — poses cam2world
    confidence = pred["conf"]       # (B, H, W) — confiance par pixel

La Flexibilité Multi-Modale

Ce qui rend MapAnything particulièrement intéressant, c’est sa capacité à ingérer n’importe quelle combinaison d’entrées. Chaque vue peut avoir des informations différentes :

views_example = [
    {"img": image},                                    # Vue 0 : image seule
    {"img": image, "intrinsics": K},                   # Vue 1 : image + calibration
    {"img": image, "intrinsics": K, "depth_z": depth}, # Vue 2 : image + calib + profondeur
    {"img": image, "intrinsics": K, "depth_z": depth,
     "camera_poses": pose, "is_metric_scale": True},   # Vue 3 : tout
]

Le modèle supporte 64 combinaisons d’entrées différentes. En pratique, cela signifie qu’on peut mélanger des images de smartphone (sans calibration ni profondeur) avec des scans LiDAR (profondeur métrique + pose) dans la même reconstruction. C’est un cas d’usage réel dans la cartographie indoor ou la réalité augmentée.

Le Framework Unifié : 14 Modèles, Une Seule Interface

MapAnything n’est pas qu’un modèle unique. Le repository fournit un framework complet avec une model_factory qui permet d’utiliser 14 modèles différents de manière interchangeable :

from mapanything.models import model_factory, get_available_models

print(get_available_models())
# ['mapanything', 'vggt', 'dust3r', 'mast3r', 'must3r',
#  'pi3', 'pi3x', 'pow3r', 'moge', 'da3', ...]

model = model_factory("vggt", name="vggt", torch_hub_force_reload=False)

Tous les modèles produisent des sorties dans un format unifié (pts3d, cam_trans, cam_quats, conf, etc.), ce qui permet des comparaisons justes et un swapping trivial. C’est un choix d’architecture que je trouve excellent : plutôt que de créer un modèle monolithique, Meta a construit un écosystème modulaire.

Les modèles disponibles couvrent tout le spectre :

Profilage : Les Chiffres Qui Comptent

Le repository inclut des scripts de profilage complets dans scripts/profile_memory_runtime.py. Les résultats publiés montrent que MapAnything domine en efficacité :

Mode standard : le modèle traite les vues en un seul batch. Rapide, mais limité en nombre de vues par la mémoire GPU.

Mode memory-efficient (memory_efficient_inference=True) : les vues sont traitées en mini-batches dynamiques. Le trade-off vitesse est négligeable, mais le gain mémoire est massif : jusqu’à 2000 vues sur 140 Go de VRAM.

python scripts/profile_memory_runtime.py 
    --output_dir results/ 
    --num_views 2 4 8 16 32 64 
    --external_models vggt pi3x must3r

Les résultats de profilage sont sauvegardés en JSON avec des courbes comparatives automatiques (mémoire et vitesse vs nombre de vues). D’après les benchmarks publiés, MapAnything maintient une fréquence d’inférence quasi-linéaire même à 100+ vues, là où DUSt3R et MASt3R s’effondrent à cause de leur optimisation globale quadratique.

Pipeline de Données : WAI Format

L’entraînement de MapAnything repose sur 13 datasets différents, unifiés par le format WAI (WorldAI Data). Le module data_processing/ fournit les outils de conversion. Le format WAI standardise :

• Images RGB avec métadonnées EXIF
• Profondeur (Z-depth ou along-ray)
• Poses caméra en convention OpenCV (cam2world)
• Intrinsèques caméra (matrice 3x3)
• Masques de validité

Cette standardisation est ce qui permet d’entraîner un seul modèle sur des données aussi hétérogènes que ScanNet (indoor), CO3D (objets), Waymo (conduite), et TartanAir (synthétique).

Export COLMAP et Gaussian Splatting

Un aspect très pragmatique de MapAnything : les prédictions sont directement exportables en format COLMAP, ce qui les rend compatibles avec l’écosystème Gaussian Splatting existant.

python scripts/demo_colmap.py 
    --images_dir /YOUR/IMAGES/ 
    --output_dir /YOUR/OUTPUT/ 
    --save_glb 
    --voxel_fraction 0.002

La sortie contient cameras.bin, images.bin, points3D.bin et un fichier .ply directement utilisables par gsplat ou d’autres pipelines de rendu :

cd gsplat/
python examples/simple_trainer.py default 
    --data_factor 1 
    --data_dir /YOUR/OUTPUT/ 
    --result_dir /YOUR/RESULTS/

Ce pont entre reconstruction feed-forward et Gaussian Splatting est probablement le cas d’usage le plus immédiatement utile en production : utiliser MapAnything pour l’initialisation rapide (poses + points 3D en quelques secondes), puis affiner avec du Gaussian Splatting si la qualité de rendu est critique.

Benchmarks : Trois Axes d’Évaluation

Le repository fournit trois benchmarks distincts dans benchmarking/ :

1. Dense Up-to-N-View Reconstruction

Évalue la qualité de reconstruction dense multi-vue. C’est le benchmark principal qui mesure la précision métrique des points 3D prédits.

2. Single-View Image Calibration

Évalue la capacité du modèle à prédire les intrinsèques caméra (focale, point principal) à partir d’une seule image. C’est un sous-produit utile : MapAnything peut servir de calibrateur automatique.

3. RobustMVD (Multi-View Depth)

Benchmark standardisé de profondeur multi-vue, qui mesure la cohérence des cartes de profondeur entre les vues.

Les configurations de benchmark sont stockées en YAML dans configs/ avec Hydra pour la composition :

# configs/dense_n_view_benchmark.yaml
# Configuration pour le benchmark de reconstruction dense

Limitations Réelles

Après avoir travaillé avec le code, voici les limitations concrètes que je retiens :

Résolution Fixe

Le modèle opère à 518x518 pixels (ou 512 pour les variantes DUSt3R). Les images d’entrée sont redimensionnées et les sorties interpolées. Pour des applications nécessitant une reconstruction haute résolution (photogrammétrie architecturale, par exemple), c’est une contrainte significative.

Pas de Textures

MapAnything produit de la géométrie, pas du rendu. Les points 3D n’ont pas de couleur associée directement exploitable pour du rendu photoréaliste. Il faut passer par Gaussian Splatting ou une autre méthode de rendu ensuite.

Coût d’Entraînement

Le modèle nécessite 13 datasets et un entraînement massif. La version Apache 2.0 (facebook/map-anything-apache) utilise un sous-ensemble de données pour la licence commerciale, avec une légère dégradation de qualité par rapport à la version CC-BY-NC.

Scènes Extérieures à Grande Échelle

Le modèle a été entraîné principalement sur des scènes indoor et des objets. Les scènes extérieures avec de grandes variations d’échelle (bâtiment entier, paysage) peuvent donner des résultats moins précis, surtout en profondeur absolue.

Dépendance au Backbone

Le ViT DINOv2 en backbone impose une contrainte forte sur les types de scènes bien gérées. DINOv2 excelle sur les scènes naturelles mais peut peiner sur des images très spécialisées (médicales, microscopiques, radar).

Mon Avis

MapAnything représente l’avenir de la reconstruction 3D pour 90% des cas d’usage. La boucle “COLMAP + NeRF/3DGS” est encore pertinente quand on veut le maximum de qualité de rendu, mais pour obtenir rapidement une géométrie 3D métrique exploitable (navigation robotique, AR, cartographie), le feed-forward est imbattable.

Le choix architectural de Meta de construire un framework modulaire plutôt qu’un modèle monolithique est particulièrement clairvoyant. Pouvoir swapper VGGT contre MapAnything contre DUSt3R en une ligne de code, avec les mêmes formats d’entrée/sortie, c’est le genre d’infrastructure qui accélère la recherche et facilite le déploiement.

Ce qui me plaît le moins : la résolution fixe à 518px et l’absence d’un mécanisme de raffinement progressif. Un mode “coarse-to-fine” où le modèle opérerait d’abord à basse résolution pour les poses, puis à haute résolution pour la géométrie dense, rendrait le système beaucoup plus compétitif face aux pipelines classiques pour les cas exigeants.

Le code est propre, bien structuré, et la licence Apache 2.0 sur le modèle commercial ouvre la porte à des intégrations industrielles. C’est probablement le projet de reconstruction 3D le plus significatif de 2025-2026 en termes d’impact pratique.

Un projet similaire ? Contactez Loïck Briot : contact@brio-novia.eu