ZipSplat: Fewer Gaussians, Better Splats
Abstract: Feed-forward 3D Gaussian Splatting methods reconstruct a scene from posed or pose-free images in a single forward pass, yet current approaches predict one Gaussian per input pixel, tying the representation budget to camera resolution rather than scene complexity. A flat wall and a richly textured object thus produce equally many Gaussians despite very different geometric needs. We propose ZipSplat, a token-based feed-forward model that decouples Gaussian placement from the pixel grid. A multi-view backbone extracts dense visual tokens, and k-means clustering compresses them into a compact set of scene tokens. Cross- and self-attention refine these tokens, and a lightweight MLP decodes each into a group of Gaussians with unconstrained 3D positions. Because clustering is applied at inference, a single trained model spans the quality-efficiency curve without retraining. ZipSplat operates without ground-truth poses or intrinsics, yet sets a new state of the art on DL3DV and RealEstate10K with ${\sim}6{\times}$ fewer Gaussians than pixel-aligned methods, surpassing the best pose-free baseline by 2.1dB and 1.2dB PSNR, respectively. It further generalizes zero-shot to Mip-NeRF360 and ScanNet++, outperforming all comparable baselines. Our project page is at ${\href{https://veichta.com/zipsplat}{https://veichta.com/zipsplat}}$.
Paper Prompts
Sign up for free to create and run prompts on this paper using GPT-5.
Top Community Prompts
Explain it Like I'm 14
Overview
This paper introduces ZipSplat, a new way to build 3D scenes from a few photos very quickly. Instead of placing one 3D “blob” (called a Gaussian splat) for every pixel in the pictures, ZipSplat figures out where blobs are really needed and uses far fewer of them while keeping or even improving image quality. Think of it as getting better-looking 3D with less “stuff.”
What problem are they solving?
Most fast 3D methods place one blob per pixel along the camera’s viewing direction. That sounds simple, but it causes three big issues:
- A plain wall and a detailed statue get the same number of blobs, even though the statue needs more detail and the wall needs less.
- If you have many overlapping photos, you create duplicate blobs for the same surface, wasting memory and time.
- Because blobs are stuck to the viewing rays, it’s hard to fill in areas you didn’t directly see.
ZipSplat wants to break this pixel-to-blob rule so the system can put blobs where the scene actually needs them.
How does ZipSplat work?
Here’s the approach in everyday terms:
- Step 1: Gather “tokens” from the images Imagine each photo being turned into lots of small summaries called tokens, which capture what’s in different parts of the scene (edges, colors, shapes) across multiple views.
- Step 2: Group similar tokens together (k-means clustering) Clustering is like sorting similar Lego pieces into bins. If multiple photos see the same wall, their tokens look similar and get grouped as one scene token. This cuts down duplicates and keeps the important stuff.
- Step 3: Refine tokens with attention Attention is a way for each scene token to “look back” at all the original image tokens and pull in the fine details it might have lost during clustering. Self-attention helps tokens understand the whole scene and how parts relate.
- Step 4: Decode tokens into 3D blobs with a small neural network (MLP) Each refined scene token is fed into a tiny network that outputs a small group of 3D blobs (their positions, sizes, colors, and transparency). These blobs are placed freely in 3D—no longer stuck to camera rays—so the system can concentrate blobs where geometry is complicated and use fewer blobs on flat, simple areas.
- Step 5: A “quality knob” you can turn at runtime Because the clustering happens at the end, you can choose how many tokens (and thus blobs) you want when you run the model. Lower number = lighter, faster scene; higher number = more detailed scene. No retraining needed.
- Extra help for training
- Geometry guidance: a loss that gently pulls blobs toward real surfaces using depth information, like a magnet guiding them to the right place.
- Smart initialization: starting blobs faint and in reasonable spots, so early mistakes don’t block the view.
- Progressive schedules: slowly increasing the number of input views and the amount of compression during training, so the model learns in stages.
What did they find?
- Fewer blobs, better or equal quality: ZipSplat matches or beats other methods while using around 6× fewer blobs, and in some cases up to 33× fewer. That’s a huge memory and speed win.
- Strong scores: On standard benchmarks (DL3DV and RealEstate10K), ZipSplat reaches state-of-the-art quality without needing camera poses (“pose-free”). It improves a key image-quality score (PSNR) by about 2.1 dB on DL3DV and 1.2 dB on RealEstate10K compared to the best pose-free baseline.
- Scales nicely with more views: As you add more photos, ZipSplat stays sharp, while pixel-per-ray methods often get blurrier and more redundant.
- Generalizes to new datasets: Even without retraining (“zero-shot”), it works well on Mip-NeRF360 and ScanNet++.
Why these results matter:
- PSNR, SSIM, and LPIPS are common metrics for image quality. Higher PSNR/SSIM and lower LPIPS mean the rendered views look closer to the real photos.
- Using fewer blobs means faster rendering and less memory, which is great for real-time applications.
Why does this matter?
- Faster and lighter 3D: ZipSplat makes instant 3D reconstruction more practical on everyday devices. This is useful for AR/VR, robotics, videos, and virtual tours.
- Smarter resource use: It spends 3D detail where it’s needed (like on edges, textures, and complex shapes) instead of wasting it on flat areas.
- Flexible quality control: You can dial in how detailed you want the scene without retraining the model, saving time and computing power.
- Works even when camera info is missing: Not needing exact camera positions makes it easier to use on casual videos or mixed photo sets.
Takeaway
ZipSplat changes the rule from “one blob per pixel” to “blobs where they matter.” By summarizing views into tokens, grouping similar ones, and placing blobs freely in 3D, it builds cleaner, sharper 3D scenes with far fewer parts. It’s a practical step toward fast, high-quality 3D for the real world.
Knowledge Gaps
Knowledge gaps, limitations, and open questions
Below is a focused list of what remains missing, uncertain, or unexplored, framed to guide future research.
- Training relies on ground-truth camera poses to generate pseudo depth for the geometric loss, whereas inference is pose-free; the feasibility and performance of fully pose-free training (without GT poses/intrinsics or teacher depth) remain untested.
- Sensitivity to the quality and bias of the teacher depth (DA3-Giant) is not analyzed; it is unclear how errors in pseudo depth affect convergence, placement stability, and final quality.
- The evaluation aligns predicted Gaussians to ground-truth target views before computing metrics; the exact alignment procedure is not specified, and performance without such alignment (i.e., in true pose-free deployment where absolute scale/pose are needed) is unknown.
- Absolute scale and global orientation are not addressed in the pose-free case; how ZipSplat resolves scale ambiguity and maintains consistent world coordinates across scenes is unclear.
- The method fixes the per-token Gaussian count to G=32; there is no study of adaptive per-token budgets (learned or content-aware) nor an analysis of how G trades off with quality, coverage, and efficiency.
- The inference-time compression ratio r is user-set; there is no automatic policy to choose r to satisfy a target quality, latency, or memory budget, and no analysis of per-scene adaptivity.
- Token compression is via k-means on features; alternatives (e.g., learned clustering, token selection, differentiable/progressive sparsification) are not compared, and the sensitivity to distance metric, initialization, and number of iterations is not reported.
- Potential failure modes where k-means merges semantically/visually similar but spatially disjoint regions (leading to ghosting or misplaced Gaussians) are not characterized; no safeguards or diagnostics are presented.
- Cross-attending compressed tokens to the full visual token set may scale poorly as the number of views/resolution grows; there is no complexity, memory, or runtime scaling analysis with respect to tokens T, clusters K, views N, and r.
- The computational cost of k-means at inference (and its variance across r, T, and scene content) is not quantified; latency breakdowns for clustering, attention, decoding, and rendering are missing.
- Runtime and memory are reported primarily in terms of “number of Gaussians”; full model footprint (including token features, SH coefficients, rotations, scales) and end-to-end latency/FPS comparisons to baselines across r and N are not provided.
- Results are trained and evaluated at relatively low resolution (252×252); behavior at higher input/output resolutions (image quality, thin-structure fidelity, runtime) is not explored.
- The paper focuses on 2D image metrics (PSNR/SSIM/LPIPS); 3D geometric accuracy/completeness (e.g., Chamfer, normal error, surface recall/precision) and coverage of occluded/unobserved regions are not evaluated.
- Generalization is claimed to Mip-NeRF360 and ScanNet++, but systematic out-of-distribution stress tests (e.g., extreme FOVs, fisheye lenses, heavy motion blur, texture-light scenes) and detailed quantitative breakdowns are not shown.
- Robustness to calibration noise (imperfect intrinsics), rolling shutter effects, and view selection outliers is not assessed.
- The approach assumes static scenes; handling non-rigid/deforming scenes and time-varying lighting is not discussed or evaluated.
- View-dependent effects are modeled via SH colors; limitations on specular/high-frequency reflectance and the impact of SH order on quality are not analyzed.
- There is no analysis of inter-token redundancy or overlap (e.g., measuring how often different tokens’ Gaussians cover the same surfaces) or regularization to discourage duplicate coverage.
- The one-directional Chamfer loss may pull Gaussians toward erroneous depth points; robustness to depth outliers and occlusion handling (e.g., masking, confidence weighting) are not examined.
- The training schedules (progressive N and r) are heuristic; ablations on their necessity, stability ranges, and sensitivity to hyperparameters (e.g., loss weights, opacity initialization) are not reported.
- The method depends on a large foundation backbone (DA3-Giant); the impact of smaller backbones, backbone choice, and possible distillation/compression for practical deployment is not studied.
- Inference-time “under a second” is stated but not systematically profiled across scenes, r values, and view counts; hardware dependence and reproducibility of latency gains are unclear.
- Comparison to post-hoc compaction/pruning baselines under matched memory/latency budgets (not just matched Gaussian counts) is limited; rate–distortion trade-offs in bytes (including attributes) are not reported.
- Integration with streaming or incremental capture (online view addition) is not discussed; k-means over all tokens suggests a batch, non-incremental pipeline.
- The method uses a non-differentiable clustering step; the implications for end-to-end training signals (e.g., whether training also uses clustering and how gradients are handled) are not clarified.
Practical Applications
Immediate Applications
Below are specific, deployable use cases that leverage ZipSplat’s token-based, pose-free, and compression-controllable 3D Gaussian Splatting. Each item includes likely sectors, concrete tools/workflows, and feasibility notes.
- 3D capture for mobile AR/VR content creation
- Sectors: software, media/entertainment, retail/e-commerce
- What: Turn short phone videos of products, rooms, or objects into 3D splat scenes in under a second without calibrated cameras; fewer Gaussians enable on-device preview and fast sharing.
- Tools/products/workflows:
- Mobile scan apps that export splat assets with a “quality slider” (inference-time compression ratio r).
- AR try-on and product viewers that stream compact 3DGS over the web.
- Assumptions/dependencies: GPU/NN accelerator on-device or cloud offload; static scenes; reliance on a robust multi-view backbone (e.g., DA3-class) packaged for mobile; SH-based appearance is view-dependent/baked lighting.
- Real-estate and interior walkthroughs from casual videos
- Sectors: real estate, AEC (architecture/engineering/construction), insurance
- What: Generate navigable interiors from handheld phone tours without pose/intrinsics; fewer Gaussians reduce storage and bandwidth for listing portals.
- Tools/products/workflows:
- Realtor apps that auto-produce 3D tours with adjustable fidelity per viewer/device.
- Claims assessment portals that reconstruct a site from claimant video uploads.
- Assumptions/dependencies: Indoor-static environments; performance tied to training distribution (e.g., household scenes); privacy and consent workflows for captured spaces.
- Drone-based quick 3D inspection with sparse views
- Sectors: energy/utilities, construction, agriculture
- What: Rapid 3D recon of assets (towers, roofs, facades) from few fly-by images without precise calibration; compact splats enable field-side review on laptops/tablets.
- Tools/products/workflows:
- Inspection kits that accept short image bursts and produce splats for defect triage.
- Progressive delivery: start with low r for instant preview; increase r when connectivity allows.
- Assumptions/dependencies: Mostly static targets; sufficient visual texture; backbone generalization to outdoor/industrial scenes; edge GPU or cloud link.
- VFX/film on-set previsualization and scene continuity checks
- Sectors: media/entertainment
- What: Instant 3D previews of a set from a few takes; fewer Gaussians allow fast re-renders for blocking and continuity decisions.
- Tools/products/workflows:
- On-set tool that ingests multi-cam stills and renders navigable previews without running a full photogrammetry pipeline.
- Assumptions/dependencies: Controlled lighting preferred; static sets; dedicated workstation GPU.
- Rapid scene digitization for cultural heritage and museums
- Sectors: cultural heritage, education
- What: Digitize artifacts/exhibits with minimal equipment and limited shots; compact outputs ease archival and web display.
- Tools/products/workflows:
- Museum capture kits that produce splats with a curator-facing “detail vs. size” control.
- Assumptions/dependencies: Static scenes; domain shift (non-consumer objects) may require fine-tuning or backbone selection.
- Embedded/web viewers with adaptive fidelity streaming
- Sectors: software, CDN/streaming
- What: Serve splat scenes with a runtime-controlled Gaussian budget; adapt to device capabilities and network conditions.
- Tools/products/workflows:
- WebGL/WebGPU 3DGS viewers exposing an adaptive r slider or dynamic ABR (adaptive bitrate) policy.
- Assumptions/dependencies: Browser GPU support; gsplat-like rasterization on the platform.
- Fast photogrammetry acceleration and “previews” in AEC
- Sectors: AEC, facilities management, surveying
- What: Provide immediate 3D previews from sparse captures while a heavier reconstruction runs in the background.
- Tools/products/workflows:
- Dual-pipeline: ZipSplat for near-instant preview, followed by NeRF/MVS refinement; switch between low/high r to guide recapture.
- Assumptions/dependencies: Static indoor/outdoor scans; integration into existing AEC workflows.
- Forensics and security scene reconstruction from uncalibrated images
- Sectors: public safety, legal, insurance
- What: Build quick 3D overviews from collections of photos/videos where camera metadata is unknown.
- Tools/products/workflows:
- Investigator tools that accept heterogeneous uploads and produce navigable splats for context.
- Assumptions/dependencies: Accuracy limits vs. survey-grade pipelines; static scenes; chain-of-custody policies and bias mitigation.
- Academic baselines and dataset-efficient training
- Sectors: academia/ML research
- What: Use token-based decoders and inference-time clustering to study capacity vs. quality curves without retraining; fewer Gaussians reduce compute for ablations.
- Tools/products/workflows:
- Research code that swaps backbones, adjusts r, and logs PSNR/LPIPS vs. Gaussian count.
- Assumptions/dependencies: Availability/licensing of foundation backbones and datasets; reproducible training with depth supervision.
- Game engine plugins for rapid environment capture
- Sectors: gaming/software
- What: Import ZipSplat outputs into Unity/Unreal for instant level blockouts and photoreal set dressing; compact assets render faster.
- Tools/products/workflows:
- Editor plugins converting splats to engine-native components with runtime LOD tied to r.
- Assumptions/dependencies: Engine-side 3DGS support or conversion layers; static environments preferred.
Long-Term Applications
These applications are plausible but require additional R&D (e.g., dynamic scenes, stronger backbones, hardware acceleration, standardization) or scaling efforts.
- Real-time 3D reconstruction on AR glasses and phones (on-device)
- Sectors: AR/VR, consumer electronics
- What: Continuous, pose-free 3D recon as a user moves; adaptive Gaussian budgets for thermal/power limits.
- Tools/products/workflows:
- AR OS pipeline with hardware-accelerated token clustering and splat rendering; background refinement with higher r when idle.
- Assumptions/dependencies: Efficient on-device backbones; hardware rasterization for 3DGS; robust handling of motion blur and rolling shutter.
- 6DoF video streaming with variable-rate splat transmission
- Sectors: communications, media/entertainment
- What: Live telepresence where scene tokens and Gaussians stream over the network at adaptive rates; clients render with different r.
- Tools/products/workflows:
- Protocols and codecs for token/Gaussian streaming akin to video ABR; edge servers handling clustering and re-encoding.
- Assumptions/dependencies: Standards for 3DGS transport; low-latency inference; privacy and security for scene transmission.
- Robotics navigation and mapping with compact splat maps
- Sectors: robotics, logistics, manufacturing
- What: Use token-based splats as memory-efficient scene maps for planning and perception; quickly update with new viewpoints.
- Tools/products/workflows:
- Splat-SLAM hybrids that maintain token sets and local Gaussians, integrating with occupancy/semantic layers.
- Assumptions/dependencies: Robustness to non-static elements; integration with odometry/IMU; multi-sensor fusion (e.g., LiDAR).
- City-scale and facility digital twins with scalable budget control
- Sectors: smart cities, AEC, GIS
- What: Build large-scale reconstructions where Gaussian budgets adapt per-region complexity; streaming LOD via r.
- Tools/products/workflows:
- Cloud pipelines chunking scenes into token tiles; CDN serving per tile at different r based on demand.
- Assumptions/dependencies: Distributed clustering and storage; cross-chunk consistency; governance for public-space scans.
- Medical and industrial imaging adaptation
- Sectors: healthcare, manufacturing
- What: Extend token-based 3D recon to endoscopy, microscopy, or borescope inspections where camera calibration is unreliable.
- Tools/products/workflows:
- Domain-adapted backbones; physics-informed losses; regulatory-grade validation.
- Assumptions/dependencies: Strong domain generalization; patient safety/regulatory approvals; dynamic/deformable tissues remain challenging.
- Generative and editable 3D media using token primitives
- Sectors: creative tools, media/entertainment
- What: Treat scene tokens as edit units for relighting, object manipulation, or style transfer; couple with generative priors.
- Tools/products/workflows:
- Token-level editors (select/move/recolor); diffusion models operating in token space to hallucinate occluded regions.
- Assumptions/dependencies: Reliable token-to-object association; disentangled appearance/geometry; UI/UX design for token editing.
- Hardware acceleration and silicon IP for tokenized 3DGS
- Sectors: semiconductors, mobile
- What: Dedicated blocks for k-means clustering, attention over visual tokens, and Gaussian rasterization; power-efficient on-device recon/render.
- Tools/products/workflows:
- SoC IP with kernels for clustering and splat blending; driver support in mobile OSes.
- Assumptions/dependencies: Market adoption of 3DGS; standard APIs; cost/benefit vs. mesh/raster pipelines.
- Standards and policy for efficient 3D content capture and streaming
- Sectors: policy, standards bodies, sustainability
- What: Best-practice guidelines and codecs for 3DGS-based experiences with energy-aware adaptive budgets.
- Tools/products/workflows:
- Industry working groups (e.g., MPEG-like) defining splat/token containers and ABR rules tied to device energy profiles.
- Assumptions/dependencies: Cross-industry consensus; metrics for quality vs. energy; privacy compliance for reconstructed spaces.
Cross-cutting assumptions and dependencies
- Backbone availability and licensing: ZipSplat relies on strong multi-view foundation models (e.g., DA3-class); deployment requires access and suitable licensing.
- Static-scene assumption: Current performance is best on static content; dynamic/deformable scenes need further research.
- Training supervision: Reported results use depth/camera priors during training for geometric supervision; fully self-supervised training would broaden applicability.
- Device and runtime constraints: While ZipSplat reduces Gaussian counts, real-time performance still depends on efficient rasterizers (e.g., gsplat) and GPU/NN acceleration on target devices.
- Domain generalization: Performance can degrade outside the training distribution (e.g., harsh lighting, outdoor extremes, medical imagery); fine-tuning or specialized backbones may be required.
- Privacy and ethics: Reconstructing real spaces/people raises privacy concerns; deployments should include consent, redaction, and secure storage policies.
Glossary
- 3D Gaussian Splatting (3DGS): An explicit scene representation that models scenes as sets of 3D Gaussian primitives rendered with a differentiable pipeline for fast, high-quality view synthesis. "3D Gaussian Splatting (3DGS)~\cite{kerbl20233d, huang20242d, Yu2023MipSplatting} represents scenes as sets of anisotropic 3D Gaussians rendered via differentiable rasterization"
- AdamW: An optimizer that decouples weight decay from gradient-based updates, often improving training stability. "AdamW~\cite{loshchilov2019adamw} (, weight decay $0.05$)"
- anisotropic 3D Gaussians: Gaussian primitives whose spatial extent varies with direction, enabling elongated or oriented splats. "anisotropic 3D Gaussians rendered via differentiable rasterization"
- camera frustum: The pyramidal volume defining what a camera can see; predictions outside it receive no rendering gradients. "predicted Gaussians fall within target camera frustums"
- Chamfer loss: A distance between point sets; here a one-directional version pulls predicted points to surfaces without enforcing coverage. "we apply a one-directional Chamfer loss~\cite{fan2017point} "
- cosine schedule: A parameter schedule that varies according to a cosine curve to gradually change training difficulty or capacity. "the compression ratio follows a cosine schedule"
- cost-volume matching: A multi-view stereo technique that aggregates matching costs across depth hypotheses to infer geometry. "dense cost-volume matching~\cite{chen2024mvsplat, xu2025depthsplat}"
- cross-attention: An attention mechanism where one set of tokens queries another set to retrieve relevant information. "Cross- and self-attention refine these tokens"
- DETR-style decoder: A transformer decoder with learned queries (as in DETR) used for set prediction without hand-crafted anchors. "with a DETR-style~\cite{carion2020end} decoder"
- differentiable rasterization: A rendering process with gradients that allows backpropagation through image synthesis. "rendered via differentiable rasterization"
- differentiable voxelization: Converting continuous geometry into voxels in a way that preserves gradients for learning. "merges predictions via differentiable voxelization"
- epipolar cross-view reasoning: Using epipolar geometry constraints across images to guide correspondence and depth estimation. "epipolar cross-view reasoning~\cite{charatan2024pixelsplat}"
- farthest point sampling: A selection strategy that iteratively picks the point farthest from existing samples to cover space well. "selected via farthest point sampling"
- feature space: The vector space of learned representations where similarity reflects visual/semantic properties. "clustering in feature space"
- feed-forward: Performing reconstruction in a single forward pass without per-scene iterative optimization. "Feed-forward methods sidestep this cost"
- graph network: A neural architecture operating on graphs to model relations (e.g., deduplication across views). "with a graph network"
- inverse-log activation: An activation that maps network outputs to unbounded values (e.g., 3D coordinates) via an exponential transform. "via an inverse-log activation~\cite{wang2025vggt}"
- k-means clustering: A clustering algorithm that partitions data into K groups by minimizing within-cluster variance. "k-means clustering compresses them"
- LPIPS: A learned perceptual similarity metric that correlates with human judgments of image quality. "an LPIPS perceptual loss ~\cite{zhang2018lpips}"
- MLP: A multi-layer perceptron; here a lightweight decoder that maps tokens to Gaussian parameters. "A lightweight MLP decodes each token into a group of Gaussians"
- multi-view backbone: A feature extractor that processes multiple images jointly to produce dense visual tokens. "A multi-view backbone extracts dense visual tokens"
- multi-view priors: Learned assumptions and cues from multiple views that guide geometry and appearance prediction. "leveraging powerful multi-view priors~\cite{wang2025vggt,lin2025depth,wang2024dust3r,leroy2024grounding,wang2025pi,keetha2025mapanything}"
- multi-view stereo: Classical methods for reconstructing 3D structure from multiple calibrated images. "classical multi-view stereo~\cite{schonberger2016structure, schonberger2016pixelwise, pan2024global}"
- Neural Radiance Fields: Neural representations that model volumetric color and density for photorealistic view synthesis. "Neural Radiance Fields~\cite{mildenhall2020nerf, barron2021mip, barron2022mipnerf360, muller2022instant}"
- novel view synthesis: Rendering images from viewpoints not present in the input set. "pose-free novel view synthesis"
- opacity loss: A regularizer that penalizes opacity to reduce redundant Gaussians and encourage sparsity. "fine-tunes with an opacity loss"
- patchified transformers: Transformer architectures that operate on image patches as tokens to scale to high resolution. "using patchified transformers~\cite{zhang2024gs, ziwen2025long}"
- per-scene optimization: Scene-specific training or refinement that runs for minutes to hours per scene. "the standard per-scene optimization~\cite{Yu2023MipSplatting,fan2024instantsplat,fu2024colmap} requires minutes to hours"
- photometric loss: A pixel-wise color difference loss supervising rendered images against ground truth. "an L photometric loss "
- pose-free: A setting where camera poses (and often intrinsics) are unknown and must be inferred or bypassed. "pose-free images"
- PSNR: Peak Signal-to-Noise Ratio; a metric for image reconstruction fidelity in decibels. "PSNR vs. number of Gaussians on DL3DV (24 input views)."
- ray-anchored methods: Approaches that constrain predicted geometry to lie along viewing rays from pixels. "ray-anchored methods"
- self-attention: An attention mechanism where tokens attend to each other within the same set for context aggregation. "Self-attention then gives every scene token global context"
- spherical-harmonic color coefficients: SH coefficients modeling view-dependent color of Gaussians. "spherical-harmonic color coefficients "
- SSIM: Structural Similarity Index; a perceptual metric for image quality. "SSIM"
- token compression: Reducing the number of tokens (e.g., via clustering) to control capacity and efficiency. "a token compression mechanism via feature-space clustering"
- viewing frustum: The visible volume of a camera in space; initialization biases Gaussians to lie within it. "inside the expected viewing frustum"
- viewing ray: The ray from a camera center through a pixel along which pixel-aligned methods place Gaussians. "placing its center on the viewing ray"
- volumetric functions: Continuous functions of 3D position (and view direction) representing density and color. "fit continuous volumetric functions to multi-view images"
- zero-shot: Evaluating a trained model on new datasets or scenes without additional training. "generalizes zero-shot to Mip-NeRF360 and ScanNet++"
Collections
Sign up for free to add this paper to one or more collections.
