在三维重建的采集页里，张数充足、视角完整，看上去就很接近“可以提交”了。但如果绕拍途中相机自动曝光突然拉高，后续又迅速压暗，同一个物体可能跨段呈现明显不同的亮度。问题不在于每一帧是不是足够亮，而在于相邻帧的外观是否突然改变。把所有照片的平均亮度算成一个数字，通常会掩盖这种局部变化。这轮做的是一个独立于重建 SDK 的小工具 LightContinuity：它接收应用已经得到的逐帧归一化亮度统计，按采集顺序找突变边界，再给出需要人工核对的片段。演示批次名 CAP-L52，包含 20 帧，业务阈值设为 0.28，被标记的转换点是 07→08 和 14→15。读者可以先把它当作一个采集后质检面板，而不是 3DGS 模型本身的质量评分。## 一、把“画面暗”与“亮度突然改变”分成两件事单张偏暗可能来自场景本身，曝光跳变却需要相邻照片对照。比如室内模型一侧有窗，另一侧有深色背景，镜头绕过去以后整体亮度变化并不一定是错误；反过来，如果镜头仍对准同一表面，却在一帧之内变得很亮，才值得考虑自动曝光或光源变化。只凭一个亮度值无法区分这两种情况，因此脚本的输出必须使用“待复核”而不能使用“无效帧”。官方对 Spatial Recon Kit 的描述是提供 3D 内容处理、三维建模与渲染相关能力。公开的 C/C++ 管线资料关注重建输入和处理流程；本文不把“亮度跃迁检测”冒充它内置的 API。示例采用的 luma 字段、LightJump 和 NEED_LIGHT_REVIEW 都由应用自行定义，也没有借用系统相机曝光补偿值去推断图像平均亮度。示例的 luma 是 0 到 1 的浮点量，可以来自项目已有的低分辨率抽样流程，但那属于额外实现工作。不同采集设备、色彩空间、曝光曲线和缩放算法会影响这个数字，不应该把它当作跨设备通用指标。本文为了便于复现判断，只提供一组人工构造的数据；真正采集时需要先锁定统计方法和有效像素区域。## 二、输入顺序不可信，差值再准确也没有用第一步把帧号、统计值和采集批次绑定，拒绝不在合法范围内的输入。不能靠数组碰巧已经有序，也不能把两个会话的同号照片放在一起比较。这里没有使用相机或重建 SDK 参数，仅定义一个可由 CSV、测试数据或上游图像分析模块喂入的 ArkTS 数据合同。arktsinterface FrameLuma { batchId: string; frame: number; luma: number;}function normalizeFrames(data: FrameLuma[], expectedBatch: string): FrameLuma[] { const result: FrameLuma[] = []; for (const item of data) { if (item.batchId !== expectedBatch || !Number.isFinite(item.luma) || item.luma < 0 || item.luma > 1 || item.frame <= 0 || !Number.isInteger(item.frame)) { continue; } result.push(item); } result.sort((a: FrameLuma, b: FrameLuma) => a.frame - b.frame); return result;}这个函数只完成初筛和排序，没有把重复帧号隐式覆盖。真实项目里应该把“同一帧号出现两条不同亮度”单独列成数据异常，因为悄悄取较新的一条，会让后续跳变看起来被修复了。上游也应保留源素材的稳定键，不以展示列表的位置充当帧号。Number.isFinite() 等基础数值判断来自 ArkTS 支持的 JavaScript 标准能力，不是 Spatial Recon Kit 特有接口。对于当前数据，先假定帧号 01 到 20 连续且无重复。若出现缺帧，则只能标记“中间隔了哪些帧”，不能把隔了十几张照片的两端叫作相邻帧。这个约束将直接影响下一段判断逻辑。## 三、检测阈值是业务参数，不是物理定律接下来比较相邻两帧的亮度差。为了避免一个常见误报，只有帧号确实连续，才允许进入跃迁规则；遇到帧号间隔时直接报告数据缺口，交给另一条诊断，不把它并入亮度检测。下面核心函数返回转换点和差值，阈值 0.28 仅用于这一组演示素材。arktsinterface LightJump { from: number; to: number; delta: number;}function findLightJumps(frames: FrameLuma[], threshold: number): LightJump[] { const result: LightJump[] = []; for (let i = 1; i < frames.length; i++) { const before = frames[i - 1]; const after = frames[i]; if (after.frame !== before.frame + 1) { continue; } const delta = Math.abs(after.luma - before.luma); if (delta > threshold) { result.push({ from: before.frame, to: after.frame, delta: delta }); } } return result;}人工数据的前七帧大致在 0.51～0.56 间，07 号是 0.54，08 号升至 0.85，差值 0.31；之后亮度稳定在 0.84～0.87 左右，到 14 号 0.85，15 号回落至 0.50，差值 0.35。因此按 > 而不是 >= 的规则，恰好产生两条提示。注意阈值等于 0.28 时不报警，这是函数定义的边界，应有独立测试样例。阈值调小会抓出更多自然场景变化，调大又可能漏掉明显的曝光跳变。选择稳定窗、中位数平滑或区域直方图可以在真实产品中进一步提高抗干扰能力，但它们属于后续扩展，不应把尚未实现的“稳健识别”写成当前演示结果。优先把可解释的差值清楚显示出来，再让采集者看到对应原帧。## 四、状态名称必须留下人工判断的空间LightContinuity 的页面用一张曲线图呈现 20 帧统计，橙色标记两个跃迁点。为了让开发者定位源素材，提示卡必须同时带上“从哪帧到哪帧”和两端亮度，而不只是一个醒目的风险百分比。底部模拟 HiLog 记录 CAP-L52、frames=20、threshold=0.28、两条边界和最终状态，这些都属于为了说明逻辑而准备的演示字符串。展示层只消费诊断结果，不改变源图片。下面这段 ArkUI 代码表达的是页面门禁：两个提示尚未被人工复核时，按钮写成“查看原帧”，而不将“可以进入重建”直接绑定到一次函数返回。arkts@Entry@Componentstruct CaptureLightPage { @State batchId: string = 'CAP-L52'; @State frameCount: number = 20; @State threshold: number = 0.28; @State warningCount: number = 2; @State phase: string = 'NEED_LIGHT_REVIEW'; build() { Column({ space: 14 }) { Text('LightContinuity').fontSize(24) Text('批次 ' + this.batchId) Text('帧数 ' + this.frameCount.toString()) Text('阈值 ' + this.threshold.toString()) Text('待复核跳变 ' + this.warningCount.toString() + ' 处') Text('当前状态 ' + this.phase).fontColor(Color.Orange) Button('查看原帧').onClick(() => { console.info('LightContinuity open frame comparison'); }) }.padding(20).width('100%') }}点击这里只记录了一个演示事件，没有创建官方图库跳转，也没有假装已经拉起重建。实际接入要由上层路由找到对应素材，交给用户核对画面内容。遇到强反光、明暗分界、进出阴影等情况，用户可能判断无需补拍；遇到自动曝光明显跳变，则可以建议降低移动速度、调整采集路线或检查相机控制策略。系统不会因为这两个橙色点自动判定模型失败。## 五、从演示统计走向真实采集，还差三组证据第一组是取样方法。同一张图取中心、取整幅或排除高光区域，统计结果可能不同；因此必须记录取样尺寸、采样区域、色彩转换方式和输出范围。第二组是时间及资产归属。当异步解码晚到时，检测器不能把上轮 CAP-L51 的亮度插入当前 CAP-L52；批次检查和帧号检查要同时生效。第三组是人工复核反馈。系统提示“亮度不连续”，产品才决定要不要重新拍摄，人工驳回的原因也应该留下。还有一个经常忽略的资源问题：如果上游为每帧解码高分辨率图像，质检本身可能增加峰值内存和采集卡顿。示例没有实现图片解码，也没有调用重建管线。实际产品应考虑缩略图采样、批次分段、统计完成后的缓存清理，以及在页面退出时终止不必要的显示更新。不可为了多一个质量分数，就让采集过程更不稳定。最终结果是一个纯业务诊断合同：CAP-L52、20 帧、阈值 0.28、两个相邻帧跃迁、NEED_LIGHT_REVIEW。它没有输出重建成功率，也不声称能判断照片的纹理可用性。后续如果要接入官方 3DGS 管线，应另外核对重建输入格式、设备能力、位姿信息和数据生命周期。只有把“输入素材值得复核”和“模型真实生成质量”分开，采集页的提示才不会越写越像未经验证的算法结论。还有一个值得提前留出的反例：两帧中间出现了明显的人员走动或镜头被手遮挡，即使整体亮度差达到了阈值，也不能自动断定是曝光控制出了问题。反过来，亮度数值几乎不变，也不代表对焦、运动模糊和位姿一定合格。当前规则专门处理一个可观察的数值现象，不应与清晰度、覆盖率或空间定位结果合并成一枚所谓“综合合格章”。如果打算把这段脚本放进真实采集链，建议先保存小规模的人工标注样本：每条提示都记录采集段、光照是否变化、人工是否接受补拍建议，以及最终是否真的重拍。随后再用这些反馈反推阈值，而不是直接把 0.28 写进所有机型的配置。参数可解释，比把演示值包装成标准答案更重要。### 参考资料与验证边界- 华为官方：空间计算与 3DGS 端侧重建能力：https://developer.huawei.com/consumer/cn/features/spatialization- 华为官方：Spatial Recon C/C++ Pipeline 用户指定资料入口：https://developer.huawei.com/consumer/cn/doc/harmonyos-guides/spatial-recon-c-spatial-recon-pipeline- 华为官方：ArkTS 运行时概述（2026-09-09）：https://developer.huawei.com/consumer/cn/doc/HarmonyOS-Guides/arkts-runtime-overview- 本文未调用设备采集、图像解码或 3DGS 重建 API；曲线、素材、日志与状态均为人工示例，不等于设备测试结果。