2026 年 10 月 21 日至 24 日，世界超高清视频产业联盟（UWA 联盟）在深圳举办 2026 UWA SUMMIT。主论坛上宣布的事，到 11 月 2 日才由 IT之家 的报道扩散开来：Spatial Vivid 1.0（空间菁彩影像）标准的参考工具开源，包括 EGSC 编解码工具、Web 渲染器工具、封装解封装工具在内的全链路参考实现，以 MIT 协议面向全球开发者开放。报道里给了两个关键定语，这是业界首个六自由度三维空间影像格式标准的配套实现，面向 3DGS 场景实现平均 20 倍压缩比和多终端快速渲染。
这条消息落在三段技术栈上。上游是 3DGS 重建管线，训练完把几十万个高斯点导出成 PLY 的那一端；中游是资产分发，文件要从 CDN 拖下来；下游是浏览器，Web 渲染器意味着解码和绘制全在用户设备上完成。三段里任何一段不通，这个格式就只能停在展台和论文里。
二十倍是平均值，不是常数
先把 3DGS 的体积来源算清楚。一个高斯点携带的属性是固定的：位置 3 个 float，不透明度 1 个，三个轴的尺度 3 个，旋转四元数 4 个，剩下全是球谐系数。三阶球谐每个通道 16 个系数，三个颜色通道就是 48 个。加起来 59 个 float，约 236 字节，还不算原始实现里预留的法线占位。一个百万点的场景，文件直接落在两百多 MB 这个量级，放进网页里下载和显存都吃不消。
压缩能动手的地方也就那么几处。量化，把 float32 砍成 float16 甚至 8 bit 定点；剪枝，扔掉不透明度低到看不见的点、尺度大到已经糊成背景的点；球谐降阶，三阶降到一阶甚至只留直流分量，代价是视角相关的高光会丢；最后才是熵编码，把前面几步留下的统计冗余压掉。EGSC 属于哪个组合、各占多少贡献，报道里没说，公开信息只说面向 3DGS 场景的平均压缩比是 20 倍。
平均值这三个字要盯住。测试集是什么、点云密度分布如何、压缩后 PSNR 掉多少，这些信息决定了 20 倍能不能搬到你的场景。一个室内小物件扫描和一个室外街区重建，同样的量化步长，前者可能几乎无损，后者会在远景上糊成一片。所以拿到参考实现的第一件事不该是直接压自己的资产，而是先量清楚自己的资产长什么样。
六自由度这个定语也值得展开一句。3DoF 的全景视频只存朝向，观看者脑袋转动时画面跟着转，但人不能往前走。6DoF 允许在场景内平移，这就必须保留一套可以重投影的几何表示，不能只存一组图。3DGS 被选成载体，原因在这。压缩必须发生在高斯属性这一层，也是同一个原因。
先量一遍自己的场景
下面这段代码不依赖那套参考工具，用的是 3DGS 原始实现导出的 PLY 文件。目的很简单，在压缩之前先看清楚点云的点数、不透明度分布和尺度分布，判断剪枝能砍掉多少。演示用法，字段名对应上游导出的通用约定。
python
import numpy as np
from plyfile import PlyData
def load_splat(path):
v = PlyData.read(path)["vertex"]
xyz = np.stack([v["x"], v["y"], v["z"]], axis=1).astype(np.float32)
# scale 存的是对数值，取 exp 才是三个轴的真实尺度
scale = np.exp(np.stack([v[f"scale_{i}"] for i in range(3)], axis=1))
# opacity 存的是 logit，过一遍 sigmoid
opacity = 1.0 / (1.0 + np.exp(-v["opacity"].astype(np.float32)))
return xyz, scale, opacity
xyz, scale, opacity = load_splat("point_cloud.ply")
print("点数", len(xyz))
print("不透明度中位数", float(np.median(opacity)))
print("各轴尺度中位数", np.median(scale, axis=0))
## 一个很粗的剪枝口径：太透明的、大到不像细节的
keep = (opacity > 0.05) & (scale.max(axis=1) < 0.5)
print("保留比例", round(float(keep.mean()), 3))两千行 Python 跑完，你大概就知道自己的场景里有多少点是不透明度低于 0.01 的、有多少点的尺度超过半米。这两个比例直接决定剪枝这一刀能切多深。如果保留比例本身就在 0.9 以上，说明场景里几乎全是有效细节，20 倍压缩基本只能从量化里挤，那就得提前接受画质损失。
拿到参考工具之后，本地跑 Web 渲染器不需要起服务框架，一个静态目录就够：
bash
python -m http.server 8080 --directory <渲染器目录>把压缩前后的资产分别指到这个页面里看一遍，比读十页标准文本更直观。
三处容易踩空的地方
第一处是数值空间。scale 和 opacity 在文件里都不是原值，前者是 log，后者是 logit。直接读出来做阈值判断，会得到完全错误的剪枝结果。这个坑在 3DGS 生态里被踩过太多次，凡是自己写 PLY 解析的代码，第一行注释就该写清楚。
第二处是球谐系数的排布。f_dc_0 到 f_dc_2 是直流分量，f_rest_* 是剩余系数，且按点数分块排列而不是按点交错。做量化时如果把 f_rest 当成一个扁平的数组统一处理，单点的系数会被打散到别的点上，画面会出现整片的颜色跳变。解析前先确认形状，是 N×45 还是 45×N，不同导出工具不一样。
第三处是协议边界。MIT 覆盖的是这次公布的参考工具，标准文本本身和可能存在的必要专利，授权条件不在这次公告的范围内。商用之前把这两件事分开看，工具能白用，不代表格式能白实现。
判断落在哪
这套东西真正值得上的场景，是资产必须下发到浏览器、且用户要在场景里走动的那一类：文旅景区的线上预览、商品的三维展示、跨端的内容分发。这些场景里，文件体积直接决定首屏时间和跳出率，压缩比是硬指标。
不值得上的场景也很清楚。离线渲染、影视级后期、单机演示，本来就没有带宽约束，直接用原始 PLY 配桌面查看器更省事，多一层编解码反而多一处画质损失。点云规模在十万级以下的场景也要谨慎，解码本身的开销会把压缩省下的时间吃掉大半。
真正决定这套标准能铺多开的，不是 20 倍这个数字，而是浏览器里解一帧要多少毫秒、在什么档位的手机上能跑满 30 帧。参考实现开源之后，这两个数字任何人都能自己测出来。谁的场景先测出可用的结果，谁才有资格谈这个格式的生产可用性。