How 3D Gaussian Splatting scenes get compressed

What a splat scene is made of

3D Gaussian Splatting represents a captured scene as a cloud of small, soft, coloured blobs called 3D Gaussians. The reference implementation starts from the sparse points produced during camera calibration, typically a COLMAP reconstruction of a set of photos, and then optimises each Gaussian's position, shape, opacity and colour while a density-control step adds and removes Gaussians as training proceeds. Its authors describe the result as high-quality real-time novel-view synthesis at 1080p, at 30 frames per second or more.

Every Gaussian carries its own parameters. A recent survey lists them: a 3-value position, a 3-value scale, a 4-value rotation quaternion, a single opacity, and colour stored as spherical harmonics, which lets colour change with viewing direction. At degree 3 that colour alone needs 48 coefficients per Gaussian, 16 for each of red, green and blue, and every parameter is a 32-bit float. Multiply by the millions of Gaussians in a typical scene and the files get large: the survey's baseline figures are 734 MB for the Mip-NeRF360 scenes, 411 MB for Tanks and Temples and 676 MB for Deep Blending.

The usual ways to shrink one

The survey sorts compression methods into two families. Unstructured methods treat each Gaussian's numbers on their own: pruning removes Gaussians that contribute little, quantization stores values with fewer bits or replaces them with entries from a shared codebook, and entropy coding packs whatever remains as tightly as its statistics allow. Structured methods exploit relationships between Gaussians, for example by attaching them to anchors, building graphs, or predicting one Gaussian's attributes from its neighbours.

Another survey, 3DGS.zip, collects concrete examples. LightGaussian prunes with a recovery step and distils the spherical harmonics down to a lower degree. Several methods store attributes as half-precision floats or cluster them with K-means codebooks. HAC, an anchor-based method, uses a hash grid queried by anchor location to predict attribute distributions for entropy coding; its low-rate setting is reported at 8.1 MB on Tanks and Temples.

Why it is harder than it looks

Every saving costs something. In the 3DGS.zip tables, HAC's low-rate version reaches 24.04 dB PSNR at 8.1 MB on Tanks and Temples while its high-rate version reaches 24.40 dB at 11.2 MB. Pruning can quietly erase detail, which is why methods add recovery steps or learned masks. Structured methods add computation, so their storage gains do not automatically turn into faster rendering, and they cannot simply be plugged into a standard 3DGS pipeline. Some approaches also need the scene to be trained with compression in mind, for instance by enforcing smoothness during training.

There is also a measurement problem. Most codecs report an average image-quality score over a set of test views after compression. That says little about how far any single Gaussian has moved, or how the scene will look from a viewpoint that was never tested.

Guaranteeing the error instead of averaging it

A new preprint, PLEDGE: Progressive Lossy Error-Bounded Compression of 3D Gaussian Splatting, targets that gap. It is a training-free codec: it works on an already trained scene. The user declares four tolerances, for screen-space position, for footprint deformation caused by changes in rotation and scale, for view-dependent colour, and for opacity, and the codec turns them into per-Gaussian quantization bounds.

Position and opacity are bounded directly. Footprint deformation is bounded under the affine projection model the rasterizer itself uses, and colour is bounded over all viewing directions, so the guarantees hold across a declared range of cameras, including viewpoints never rendered during encoding. The quantized residuals are laid out as a progressive bitstream in which every valid prefix comes with its own explicit error bound, so a reader can stop early and still know its worst case.

The authors report that experiments on thirteen scenes satisfied every declared bound, with rate-distortion performance they describe as competitive. They also found that the four tolerances have very different costs in bits, which lets users spend their budget on whichever property their application cares about most.