Insights

Idol: Single Image to 3D Gaussian Splats

Idol by Speridlabs converts single images into rotatable 3D Gaussian splats, predicting unseen sides and exporting standard PLY files with adjustable density.

Highlights and Results

Idol, from Speridlabs, transforms a photograph, render, or generated image of one object into a rotatable 3D Gaussian splat. It predicts the object’s unseen sides and exports a standard 3DGS PLY containing 32,768 to 1,048,576 Gaussians. Its practical appeal is a public inference SDK with controllable output density and consumer-GPU memory requirements, rather than a mandatory multi-view capture session. Official research page.

The authors’ comparison uses one H100 per model. At 50 sampling steps and 262,144 Gaussians, Idol reports 6.8 seconds per request, input-view SSIM of 0.726, and seven-new-view DINOv2 similarity of 0.781, compared with TRELLIS’s 0.716 and 0.754 under its listed 50 + 50-step setting. LGM is faster at 1.1 seconds, so Idol does not lead every metric. These are author-reported results; the displayed comparison does not identify a named benchmark dataset or sample count. Benchmark.

A separate timing table reports 19.1 seconds on an RTX 4090 at the same 50-step, 262,144-Gaussian setting, taking the median over eight images. The model card reports 7.2 GB peak memory. Its “under two seconds” headline should therefore not be read as the measured runtime of this standard 4090 configuration. Model card and hardware settings. https://external-v2fun-data-hk-1.oss-accelerate.aliyuncs.com/temp/2026/11/11/idol-armchair_1794377040335.webp

How It Works

The inference path is image preparation → dual image encoding → joint object-and-camera flow sampling → octree anchor placement → Gaussian decoding → PLY and camera export. BiRefNet removes the background, and the object is framed at 1024 × 1024 pixels. Photo and synthetic modes use different crop margins, 1.7 and 1.2 respectively. Pipeline.

DINOv3 supplies visual feature tokens, while the FLUX.2 VAE supplies compressed image information. After projection into the transformer’s working dimension, their embeddings are added to form image conditioning. Generation starts from two random tensors: an object latent with 8,192 tokens of 16 channels, and a five-channel camera token. The streams are refined separately before joint attention processes latent, image, and camera tokens together. The model predicts velocities for both object and camera, making viewpoint part of generation rather than an independently assumed input. Transformer implementation.

The sampler integrates rectified flow from noise at t = 1 to data at t = 0 with Euler steps. Defaults are 50 steps, guidance parameter w = 3, and time shift 3. The actual guidance equation is v = (1 + w)v_cond − wv_uncond; the shifted time grid allocates more steps near high noise. These operations alter the compact latent and camera state, not millions of explicit Gaussians at each iteration. Flow sampler.

Decoding expands that compact result spatially. An octree decoder conditions on the object latent and distributes a requested number of anchors among eight child cells at each level. A Gaussian decoder reads the same latent through cross-attention and emits 32 Gaussians per anchor, predicting position offsets, color, scale, rotation, and opacity. Thus 262,144 Gaussians require 8,192 anchors. Output density is controlled in decoding; it is not the latent-token count or a mesh subdivision level. Decoders.

The denoiser contains 370.6M parameters and the two decoders approximately 288.1M, giving about 0.66B for those core components. Including image encoders and background removal brings the full request to roughly 1.80B parameters. The SDK returns the splat, the processed input image, and predicted camera parameters. GPU optimizations compile the denoiser and batch conditional/unconditional passes, with additional startup cost on the first generation. Component accounting and runtime.

Applications, Availability, and Future Directions

The output suits splat-based object previews, interactive presentations, and experiments in image-to-3D generation. A Gaussian PLY is not a watertight polygon mesh, CAD solid, or automatically rigged character. Hidden surfaces are inferred rather than measured. The SDK and weights are published with Apache-2.0 labeling, while the required DINOv3 and FLUX.2 encoder components need separate gated access and their applicable terms. Release and access requirements.

This review uses the official research page, model card, and SDK commit 4702a7f, checked November 6, 2026. No standalone technical paper or explicit Idol-specific future-work roadmap was found in those materials. The inspected repository supplies inference and a demo, so its internals do not establish an undisclosed training recipe. No model inference or benchmark was rerun for this article.

FAQ

Can the PLY be sent straight to a 3D printer?

No. It stores Gaussian primitives for rendering, not a closed printable surface. Surface reconstruction and print preparation would be separate processes outside this SDK’s documented output.

Does increasing Gaussian count guarantee a more accurate hidden side?

No. It increases decoding density. The unseen side still comes from the image-conditioned generative model, so more primitives do not supply missing measurements.

What should I expect when running it locally?

The documented setup uses Python 3.10+, PyTorch 2.5+, and an NVIDIA CUDA GPU, with access to both image encoders. Compare timings at matched sampling settings and allow for first-run downloads and compilation.

Related Articles