Idol: Enskild bild till 3D-gaussiska splats
Idol från Speridlabs konverterar enstaka bilder till roterbara 3D Gaussian splats, förutser osedda sidor och exporterar PLY-filer av standardformat med justerbar täthet.
Höjdpunkter och resultat
Idol från Speridlabs omvandlar ett fotografi, en rendering eller en genererad bild av ett objekt till en roterbar 3D Gaussian-splat. Den förutsäger objektets osynliga sidor och exporterar en standardiserad 3DGS-PLY-fil som innehåller 32 768 till 1 048 576 Gauss-kärnor. Den praktiska fördelen är ett offentligt inferens-SDK med kontrollerbar utdata-täthet och minneskrav som är anpassade för konsument-GPU:er, i stället för en obligatorisk inspelningssession från flera vyer. Officiell forskningssida.
Författarnas jämförelse använder en H100 per modell. Vid 50 samplingsteg och 262 144 Gauss-kärnor rapporterar Idol 6,8 sekunder per begäran, SSIM för indata-vyn på 0,726 och DINOv2-likhet för sju nya vyer på 0,781, jämfört med TRELLIS 0,716 och 0,754 vid dess angivna inställning på 50 + 50 steg. LGM är snabbare med 1,1 sekunder, så Idol leder inte i varje mätvärde. Detta är resultat som rapporterats av författarna; den visade jämförelsen identifierar varken något namngivet benchmark-dataset eller något antal sampel. Benchmark.
En separat tidtabell rapporterar 19,1 sekunder på en RTX 4090 vid samma inställning med 50 steg och 262 144 Gauss-kärnor, där medianen beräknas över åtta bilder. Modellkortet rapporterar 7,2 GB maximalt minne. Rubriken ”under två sekunder” bör därför inte tolkas som den uppmätta körtiden för denna standardkonfiguration på 4090. Modellkort och maskinvaruinställningar.
Så fungerar det
Inferensflödet är bildförberedelse → dubbel bildkodning → gemensam flödessampling för objekt och kamera → placering av oktreensankare → Gauss-avkodning → export av PLY och kamera. BiRefNet tar bort bakgrunden, och objektet placeras i en bildruta på 1 024 × 1 024 pixlar. Foto- och syntetiska lägen använder olika beskärningsmarginaler, 1,7 respektive 1,2. Pipeline.
DINOv3 tillhandahåller visuella funktionstoken, medan FLUX.2 VAE tillhandahåller komprimerad bildinformation. Efter projektion till transformerns arbetsdimension adderas deras embeddingar för att bilda bildkonditionering. Genereringen startar från två slumpmässiga tensorer: en objektlatent med 8 192 token på 16 kanaler och en kameratoken med fem kanaler. Strömmarna förfinas separat innan gemensam attention bearbetar latenta token, bildtoken och kameratoken tillsammans. Modellen förutsäger hastigheter för både objekt och kamera, vilket gör synvinkeln till en del av genereringen i stället för en oberoende antagen indata. Transformerimplementation.
Samplaren integrerar rectified flow från brus vid t = 1 till data vid t = 0 med Euler-steg. Standardvärdena är 50 steg, styrparametern w = 3 och tidsförskjutningen 3. Den faktiska styr-ekvationen är v = (1 + w)v_cond − wv_uncond; det tidsförskjutna rutnätet fördelar fler steg nära högt brus. Dessa operationer förändrar den kompakta latenta representationen och kameratillståndet, inte miljontals explicita Gauss-kärnor vid varje iteration. Flödessampling.
Avkodningen expanderar detta kompakta resultat rumsligt. En oktreenavkodare konditioneras på objektlatenten och fördelar ett begärt antal ankare mellan åtta underceller på varje nivå. En Gauss-avkodare läser samma latent genom cross-attention och genererar 32 Gauss-kärnor per ankare, där den förutsäger positionsförskjutningar, färg, skala, rotation och opacitet. Därför kräver 262 144 Gauss-kärnor 8 192 ankare. Utdata-tätheten styrs vid avkodningen; den är inte antalet latenta token eller en nivå för nätuppdelning. Avkodare.
Denoisern innehåller 370,6 miljoner parametrar och de två avkodarna cirka 288,1 miljoner, vilket ger omkring 0,66 miljarder för dessa kärnkomponenter. Om bildkodare och bakgrundsborttagning inkluderas omfattar hela begäran ungefär 1,80 miljarder parametrar. SDK:t returnerar splatten, den bearbetade indata-bilden och förutsagda kameraparametrar. GPU-optimeringar kompilerar denoisern och batchar villkorade och ovillkorade passeringar, med ytterligare startkostnad vid den första genereringen. Komponentredovisning och körtid.
Tillämpningar, tillgänglighet och framtida riktningar
Utdata lämpar sig för objektförhandsvisningar baserade på splats, interaktiva presentationer och experiment med bild-till-3D-generering. En Gaussian-PLY-fil är inte ett vattentätt polygon-nät, en CAD-solid eller en automatiskt riggad karaktär. Dolda ytor härleds i stället för att mätas. SDK:t och vikterna publiceras med Apache-2.0-licens, medan de nödvändiga komponenterna för DINOv3- och FLUX.2-kodarna kräver separat åtkomst med godkännande och omfattas av sina tillämpliga villkor. Krav för publicering och åtkomst.
Denna granskning använder den officiella forskningssidan, modellkortet och SDK-commiten 4702a7f, kontrollerade den 6 november 2026. Inget fristående tekniskt dokument eller någon uttrycklig färdplan för framtida Idol-arbete hittades i detta material. Det undersökta kodarkivet tillhandahåller inferens och en demo, så dess interna delar fastställer inte någon icke offentlig träningsmetod. Ingen modellinferens eller något benchmark kördes på nytt för denna artikel.
Vanliga frågor
Kan PLY skickas direkt till en 3D-skrivare?
Nej. Det lagrar Gaussiska primitiver för rendering, inte en sluten yta som kan skrivas ut. Ytrekonstruktion och förberedelse för utskrift skulle vara separata processer utanför SDK:ts dokumenterade utdata.
Garanterar ett ökat antal Gauss en mer exakt dold sida?
Nej. Det ökar avkodningstätheten. Den osedda sidan kommer fortfarande från den bildvillkorade generativa modellen, så fler primitiver tillför inga saknade mätvärden.
Vad kan jag förvänta mig när jag kör det lokalt?
Den dokumenterade konfigurationen använder Python 3.10+, PyTorch 2.5+ och en NVIDIA CUDA-GPU, med åtkomst till båda bildkodarna. Jämför tidsåtgången vid matchade samplingsinställningar och ta hänsyn till nedladdningar och kompilering vid första körningen.
