一、引言：从静态照片到可交互的空间图片
iOS 26，苹果推出空间照片（Spatial Scene），轻轻转动手机，照片里的主体和背景随视角产生不同的位移，一张普通图片便有了可以探索的空间层次。
得物技术团队随即启动相关的技术预研并上线。在得物，用户发布图片时带上 #空间图片 话题，服务端异步生成三维场景模型，客户端根据手机姿态实时渲染。创作者仍然使用熟悉的图文发布方式。
发布活动页
视频交互示意
3D 空间图片功能的落地，涉及模型生成、内容分发、客户端渲染之间的一系列取舍。本文重点分享如何生产出高质量、小体积的模型，以及如何在手机上流畅运行。
二、方案概要：空间图片的端云协同链路
在落地过程中，模型质量、文件体积和端侧开销需要一起权衡。减少高斯点数，可以降低存储与绘制成本，也可能丢失新视角中的细节；压缩后的文件更小，解码时仍可能占用较多内存。
服务端完成模型生成、多视角渲染和质量评估，再将模型压缩后分发。客户端经过设备准入，完成下载、解码、GPU 上传和实时渲染。完整链路如下：
本文按模型生产、质量评价、模型体积压缩、移动端渲染四个环节，说明方案选择和工程实现。
三、模型生产：从单张照片到三维高斯场景
空间视差原理
普通图片记录了固定视角下的颜色信息。当观察位置移动时，不同距离的物体在画面中产生不同程度的位移，这种运动视差是空间感的重要来源。
相机横向移动时，近景在画面中的位移大于远景
要让图片随视角变化，需要先建立可渲染的三维表示。生产侧采用单图前馈生成路线：从输入图片提取几何与外观线索，预测三维高斯属性，输出场景模型。客户端加载模型后，通过改变虚拟相机的视角绘制画面，无需在每次手机转动时重新运行生成网络。
三维高斯表示
3D Gaussian Splatting（3DGS）用一组三维高斯基元表示场景。每个基元可以理解为一个带有颜色、不透明度和空间范围的柔和椭球。位置决定它在哪里，尺度与旋转决定形状和方向，颜色与不透明度决定它对画面的贡献。
渲染时，三维高斯被投影为屏幕上的二维椭圆，再按深度顺序进行透明度混合，形成最终画面。相机视角改变，投影与遮挡关系也随之改变，前景和背景因此产生不同的位移。高斯数量、屏幕覆盖范围和重叠程度都会影响绘制成本。
3DGS 渲染原理示意：三维高斯、投影、排序混合与二维画面
原始 3DGS 方法通过多视角照片优化一个场景的高斯参数；本方案从单张图片直接预测高斯属性，再交给渲染器展示附近视角。两者使用了相同类型的场景表示，生成高斯参数的方式不同。
单图生成的能力边界
单图生成降低了素材准备门槛，但照片没有记录被遮挡区域的真实信息。新视角中出现的内容包含模型推断，观察范围越大，越容易暴露空洞、拉伸或错误的遮挡关系。实际体验需要约束在原始视角附近。
生产规模也不能只由生成效果决定。在本项目中，内部处理分辨率会影响高斯数量，进而影响存储、排序和绘制开销。生成分辨率与客户端输出分辨率是两个变量，应分别控制。后文先说明评价方法，再用实验结果解释当前模型档位的选择。
四、质量评价：从像素误差到多视角观感
像素误差度量
空间图片不能只检查正面截图。一根鞋带可能在正面完整，转动后却出现断裂；人物轮廓可能露出空洞，远景纹理也可能在某些角度变得稀疏。评价需要覆盖视角变化后的画面。
PSNR 基于对应像素的均方误差，主要反映数值保真程度。SSIM 比较局部亮度、对比度和结构，能够描述部分结构变化，但仍依赖图像之间的空间对应关系。
视角合成中的微小几何偏差，会改变边缘在画面中的位置。即使纹理和整体观感接近，像素比较也可能受到明显影响；某些平滑结果则可能取得较小的像素误差，却损失细节。因此，本项目以 LPIPS、DISTS 等感知指标作为主要评价依据，PSNR、SSIM 可用于辅助诊断，不单独据此判断观看质量。
LPIPS 论文中的一组例子直观展示了这种差异。每组三张图以中间的 Reference 为参照，绿色对勾表示对应评价方式认为更接近参照的候选。左侧建筑案例中，人更倾向于保留细节但发生局部形变的右图，而图中列出的传统指标选择了模糊的左图。
传统指标与人眼判断可能给出不同的相似度排序
感知质量评价
LPIPS（Learned Perceptual Image Patch Similarity）利用神经网络提取图像特征，再比较特征空间中的差异，为纹理、轮廓等感知变化提供参照。
DISTS（Deep Image Structure and Texture Similarity）结合深层特征的结构与纹理统计，对一定程度的纹理重采样和轻微几何变化具有容忍性。将它与 LPIPS 联合观察，有助于定位轻量化后的细节退化。
两项指标都是数值越低，表示与参照图像的差异越小。前提是参照有意义：新视角渲染图不能直接与原始视角照片比较，否则正常视差也会被计入差异。
LPIPS 与 DISTS 的计算流程
多视角一致性评测
我们使用两类参照，分别检查生成过程和轻量化过程：
对比时需要统一图像尺寸、裁切范围等条件。轻量化评测的参照是基线模型的渲染结果，并非新视角的真实拍摄图像。如果基线模型本身存在生成错误，与它接近并不能说明新视角合理。
逐帧相似度也无法完整反映转动过程中的闪烁。指标之外，还需要连续观看，并回看遮挡边缘、文字和细结构等典型失败案例。下一章的帧级统计用于比较模型档位，不等同于模型整体合格率。
五、模型体积压缩：平衡画质、体积与渲染成本
高斯减点与画质取舍
模型轻量化包含两个环节：先减少需要表达和绘制的高斯基元，再压缩每个基元的存储开销。减点会改变场景表示，同时影响文件大小与端侧工作量；格式编码主要降低分发体积，运行时收益取决于解码方式和数据布局。
阶段实验比较了降低生成分辨率、均匀降采样和过滤部分基元等方式。均匀降采样能够直接减少点数，但测试中出现了放大后条纹感明显的案例。降低生成分辨率也有代价：继续压低点数时，毛发、人物边缘和大范围背景更容易缺失细节。
本轮比较使用统一的 5 秒渲染视频，每秒抽取一帧，对比相同序号的画面。每个轻量化档位累计得到 185 组对应帧，两项指标分别统计如下。
这些阈值用于本轮方案比较，不代表通用画质等级，两列比例也不能合并理解为联合通过率。高点数档位在两项指标下的帧级达标比例都更高。案例回看中，部分雪景和社区远景在低点数下出现的黑影、空洞或元素缺失，提高到该档位后有所改善。
低点数下的黑影空洞
结合多视角评测与端侧表现，当前采用较高的高斯点数，在保证效果的同时，能够大幅减少点数。
属性编码与格式压缩
确定模型规模后，还需要将原始的 PLY 模型压缩，以减小传输文件大小。我们通过属性量化和紧凑编码组织三维高斯数据，减少存储与网络传输体积。量化会引入数值误差，需要单独核验画质。
以本次测试使用的属性布局为例，位置、颜色、不透明度、尺度和旋转共包含 14 个 float32 数值，每个高斯的属性负载约为 56 字节。
减点与格式编码的作用区别
优化后，在保证渲染质量的前提下，文件大小相较于压缩前减少约81.5%。
六、移动端渲染：让空间图片流畅响应视角变化
大量的高斯点进入移动端后，开销分布在解码、数据搬运、排序和像素混合几个阶段。加载时并行还原属性，首帧建立深度索引，后续按需绘制并复用索引。
客户端展示与交互
空间坐标与视角交互
高斯点保存在世界坐标中，结合模型外参与观察目标建立初始相机，内参和画面比例决定投影。视图矩阵 V 将高斯变换到相机空间，投影矩阵 P 再将其映射到屏幕；相机空间以前方为 −Z，后续排序与投影都使用这套坐标。
陀螺仪将角速度积分为受限的横向、纵向相机位移，相机始终看向观察目标，形成小幅视差。手势可通过 Camera 的 orbit／pan／zoom 接口调整三维视角。
GPU 深度排序
高斯投影是半透明椭圆，同一像素可能被多个高斯覆盖。Alpha 混合与顺序有关：当前绘制路径需要先画远处，再叠加近处，否则前后颜色的贡献会颠倒。因此按高斯中心的相机空间深度建立绘制顺序；这种全局排序是近似，并非逐像素的精确遮挡求解。
采用 GPU 稳定 Radix Sort：生成 32 位深度键，每轮处理 8 位，经过 4 轮计数、前缀和、重排，输出排序索引。索引留在 GPU，后续绘制直接读取；Compute 与 Render 之间建立资源依赖。首帧排序后复用索引，适用于受限的小幅视差，大幅改变视角需重新评估排序。
经测试，采用 GPU 排序，排序耗时降低 60%–75%。
GPU 实例化绘制
每个高斯用一个四顶点四边形承载，片元着色器计算椭圆范围内的颜色与透明度。当前普通显示路径通过一次实例化 draw 绘制 N 个高斯：vertexCount = 4、instanceCount = N，减少逐高斯提交的 CPU 命令开销。
同一组高斯在两种提交方式下的绘制流程（N = 5 为示意）
GPU 用 instanceID 经排序索引找到高斯，用 vertexID 生成四个角。相比图中的逐个提交，实例化绘制省去了重复的 draw 调用和 CPU 顶点展开；高斯数量、约 4N 个顶点工作项及透明混合仍然存在。非实例化绘制也可合批，图中的 N 次调用仅指逐高斯提交。
// C++ 风格伪代码：普通显示路径的一次实例化绘制 bind(gaussianBuffer, sortedIndices, uniforms); drawInstanced(TriangleStrip, 4, pointCount); // 顶点阶段按 gaussians[sortedIndices[instanceID]] 读取属性。其他优化
端侧实测表现
iOS、Android 分别用高端机、中端机、低端机对不同高斯点数的模型进行效果测试、性能测试，性能测试指标包括帧率、内存占用、手机发热情况等，最终选择较高点数的模型。经真机测试，iOS 、Android 帧率稳定在 60FPS。
得物 APP 内渲染，稳定60FPS
七、总结
本次实践中，我们结合多视角质量与端侧表现确定模型档位，通过格式编码进一步压缩分发体积，并在客户端通过数据组织、排序与帧调度降低运行开销。最终，在保留模型细节与多视角观感的同时，降低了内容分发与端侧渲染的负担，让 3D 内容以更轻量、流畅的方式融入用户的浏览与交互体验。
八、写在最后：关于得物音视频团队
我们是得物音视频团队，专注于多媒体算法与工程，业务覆盖多媒体处理、播放器、AIGC、智能创作等方向，已上线 3D 球鞋展示、AR 试穿等创新玩法。围绕图片、视频、音频、Live Photo、3D 等内容，我们建设从智能生成、云端处理、内容分发到端侧播放与交互的完整技术链路，持续打磨画质、性能与使用体验。我们希望把技术探索融入日常创作与浏览，让创作者更轻松地表达想法，也让每一份分享以清晰、流畅、生动的方式抵达用户。欢迎加入得物音视频团队！
往期回顾
1.别再只卷向量检索了，得物交易搜索如何用“生成式”实现召回范式跃迁？
2.指标平台：从语义底座到智能消费的实践路径｜得物技术
3.企业级 MultiAgent 落地：Plan 模式与主子 Agent 协作｜得物技术
4.得物小摊 AI Native 演进实录：用 Harness 构建可控 AI 交付
5.企业级 MultiAgent 的记忆系统：短期上下文与四层记忆架构实现｜得物技术
文 / 南极熊、章北海
关注得物技术，每周四更新技术干货
要是觉得文章对你有帮助的话，欢迎评论转发点赞～
未经得物技术许可严禁转载，否则依法追究法律责任。
