Idole : d’une image unique aux splats gaussiens 3D
Idol de Speridlabs convertit des images uniques en splats gaussiens 3D orientables, prédit les faces non visibles et exporte des fichiers PLY standard avec une densité réglable.
Points forts et résultats
Idol, de Speridlabs, transforme une photographie, un rendu ou une image générée d’un objet en un Gaussian splat 3D orientable. Il prédit les faces invisibles de l’objet et exporte un fichier PLY 3DGS standard contenant de 32 768 à 1 048 576 Gaussiens. Son intérêt pratique réside dans un SDK d’inférence public offrant une densité de sortie contrôlable et des exigences de mémoire compatibles avec les GPU grand public, plutôt que dans l’obligation d’une session de capture multi-vues. Page de recherche officielle.
La comparaison des auteurs utilise un H100 par modèle. Avec 50 étapes d’échantillonnage et 262 144 Gaussiens, Idol rapporte 6,8 secondes par requête, un SSIM de 0,726 pour la vue d’entrée et une similarité DINOv2 de 0,781 pour sept nouvelles vues, contre 0,716 et 0,754 pour TRELLIS avec son réglage indiqué de 50 + 50 étapes. LGM est plus rapide, avec 1,1 seconde : Idol n’est donc pas en tête pour toutes les métriques. Ces résultats sont rapportés par les auteurs ; la comparaison affichée n’identifie ni jeu de données de référence nommé ni nombre d’échantillons. Benchmark.
Un tableau de temps distinct rapporte 19,1 secondes sur un RTX 4090 avec le même réglage de 50 étapes et 262 144 Gaussiens, en prenant la médiane sur huit images. La fiche du modèle indique 7,2 Go de mémoire maximale. Son titre « moins de deux secondes » ne doit donc pas être interprété comme le temps d’exécution mesuré pour cette configuration standard sur 4090. Fiche du modèle et paramètres matériels.

Fonctionnement
Le chemin d’inférence est le suivant : préparation de l’image → encodage double de l’image → échantillonnage conjoint du flux objet-caméra → placement des ancres de l’octree → décodage gaussien → exportation du PLY et de la caméra. BiRefNet supprime l’arrière-plan, et l’objet est cadré sur 1 024 × 1 024 pixels. Les modes photo et synthétique utilisent des marges de recadrage différentes, respectivement 1,7 et 1,2. Pipeline.
DINOv3 fournit les tokens de caractéristiques visuelles, tandis que le VAE FLUX.2 fournit des informations d’image compressées. Après projection dans la dimension de travail du transformeur, leurs embeddings sont additionnés pour former le conditionnement de l’image. La génération commence à partir de deux tenseurs aléatoires : un latent objet de 8 192 tokens de 16 canaux et un token caméra à cinq canaux. Les flux sont affinés séparément avant que l’attention conjointe ne traite ensemble les tokens latent, image et caméra. Le modèle prédit les vitesses de l’objet et de la caméra, faisant du point de vue une partie de la génération plutôt qu’une entrée supposée indépendamment. Implémentation du transformeur.
L’échantillonneur intègre le flux rectifié du bruit à t = 1 vers les données à t = 0 avec des étapes d’Euler. Les valeurs par défaut sont de 50 étapes, un paramètre de guidage w = 3 et un décalage temporel de 3. L’équation réelle de guidage est v = (1 + w)v_cond − wv_uncond ; la grille temporelle décalée alloue davantage d’étapes lorsque le bruit est élevé. Ces opérations modifient le latent compact et l’état de la caméra, et non des millions de Gaussiens explicites à chaque itération. Échantillonneur de flux.
Le décodage développe spatialement ce résultat compact. Un décodeur octree se conditionne sur le latent objet et distribue un nombre demandé d’ancres entre huit cellules filles à chaque niveau. Un décodeur gaussien lit le même latent via l’attention croisée et émet 32 Gaussiens par ancre, en prédisant les décalages de position, la couleur, l’échelle, la rotation et l’opacité. Ainsi, 262 144 Gaussiens nécessitent 8 192 ancres. La densité de sortie est contrôlée lors du décodage ; il ne s’agit ni du nombre de tokens latents ni d’un niveau de subdivision de maillage. Décodeurs.
Le débruiteur contient 370,6 M de paramètres et les deux décodeurs environ 288,1 M, soit environ 0,66 Md pour ces composants principaux. En incluant les encodeurs d’image et la suppression de l’arrière-plan, la requête complète atteint environ 1,80 Md de paramètres. Le SDK renvoie le splat, l’image d’entrée traitée et les paramètres de caméra prédits. Les optimisations GPU compilent le débruiteur et regroupent les passes conditionnelles et inconditionnelles, avec un coût de démarrage supplémentaire lors de la première génération. Comptabilisation des composants et exécution.
Applications, disponibilité et orientations futures
La sortie convient aux aperçus d’objets fondés sur des splats, aux présentations interactives et aux expériences de génération d’image vers 3D. Un PLY gaussien n’est ni un maillage polygonal étanche, ni un solide CAO, ni un personnage automatiquement équipé. Les surfaces cachées sont inférées plutôt que mesurées. Le SDK et les poids sont publiés sous l’étiquetage Apache-2.0, tandis que les composants d’encodeur DINOv3 et FLUX.2 requis nécessitent un accès restreint séparé ainsi que le respect de leurs conditions applicables. Publication et conditions d’accès.
Cette analyse utilise la page de recherche officielle, la fiche du modèle et le commit 4702a7f du SDK, vérifiés le 6 novembre 2026. Aucun article technique autonome ni feuille de route explicite concernant les travaux futurs d’Idol n’a été trouvé dans ces documents. Le dépôt inspecté fournit l’inférence et une démonstration ; ses éléments internes ne permettent donc pas d’établir une recette d’entraînement non divulguée. Aucune inférence du modèle ni aucun benchmark n’ont été relancés pour cet article.
FAQ
Le PLY peut-il être envoyé directement à une imprimante 3D ?
Non. Il stocke des primitives gaussiennes pour le rendu, et non une surface fermée imprimable. La reconstruction de surface et la préparation à l’impression seraient des processus distincts, en dehors des sorties documentées de ce SDK.
Augmenter le nombre de Gauss garantit-il un côté caché plus précis ?
Non. Cela augmente la densité de décodage. La partie invisible provient toujours du modèle génératif conditionné par l’image, donc davantage de primitives ne fournissent pas les mesures manquantes.
À quoi dois-je m’attendre lors de son exécution en local ?
La configuration documentée utilise Python 3.10+, PyTorch 2.5+ et un GPU NVIDIA CUDA, avec accès aux deux encodeurs d’image. Comparez les temps d’exécution avec des paramètres d’échantillonnage identiques et tenez compte des téléchargements et de la compilation lors de la première exécution.




