采集素材交给三维重建之前，最容易产生误判的数字是“已经拍了多少张”。十几张照片看起来很充足，可能有好几张来自几乎相同的位置。另一方面，相似的两张照片也可能刚好保留了不同角度的细节，不能一句“重复”就删掉。本文设计一个可落地的应用侧预检：给每帧准备一份简化视觉指纹，对连续输入做候选标注，把最终是否保留交给采集人员确认。这里讨论的是素材整理，而不是声称调用了 3DGS 重建引擎。## 一、把“去重”改成“待复核候选”Demo 叫 FrameDiversity，页面 FrameAuditPage，规则放进 HashGate.ets。示例批次 FD-306 有 16 帧，示意输入在 21:18 进行一次检查：保留候选 11 帧，近重复提醒 5 帧，业务阈值设为汉明距离不超过 5 位。页面状态为 REVIEW_DUPLICATES。这组数字全部是构造的测试样本，不是来自真机相机或重建任务；五条提醒也不等于五张照片应该立刻被删除。为什么刻意用“提醒”？感知指纹和文件哈希不是一回事。文件哈希适合判断字节内容是否相同；一张照片缩放、重新压缩之后，文件哈希会变，但肉眼看到的画面可能还是一模一样。这里假设上游已将灰度缩略信息转换为定长二进制指纹，后续只处理这些字符串。缩略采样、曝光归一化和图像解码不在本文三段代码的覆盖范围内，更不能把它写成 HarmonyOS 已经提供了某个未验证的 getPerceptualHash() 系统方法。同样需要保留另一条边界：相似度不是三维几何信息。相邻两张图画面相近，但视差可能对建模有价值；夜景照明、反光和遮挡反过来会让同一机位的指纹变化很大。因此报告叫“近重复候选”，不叫“冗余帧判定”。它适合提醒拍摄人员检查，不适合成为自动清理原始素材的唯一依据。## 二、先确保指纹格式稳定最小的规则文件只接收 64 个字符、且字符只能是 0 或 1 的指纹。这样的约束看似繁琐，却能阻止空字符串、不同长度或者由另一种编码方案生成的指纹混进来。汉明距离是对应位置不相同的位数；它有清晰的可解释性，但并不是“两个画面有多少百分比相同”。第一段代码只做校验与距离统计，不碰文件和图片系统。ts// HashGate.ets：输入是业务侧生成的64位二进制文本指纹export function hamming64(a: string, b: string): number { const pattern: RegExp = /^[01]{64}$/; if (!pattern.test(a) || !pattern.test(b)) { throw new Error('FINGERPRINT_FORMAT_INVALID'); } let distance: number = 0; for (let i: number = 0; i < 64; i++) { if (a.charAt(i) !== b.charAt(i)) distance++; } return distance;}````pattern` 不是 SDK 的视觉能力，而是应用输入合同。明确校验长度后，距离的取值范围就是 0 到 64，便于日志与离线脚本交叉核对。若某个插件突然把文本改成十六进制，应该让检查直接失败，而不是将不兼容的编码悄悄当成“相似度很高”。实际项目还需要给指纹增加算法标识与版本号；不同算法产生的 64 位数字即使长度相同，也不能拿来互相比较。举一个能手工算清的例子：把 `F-007` 和 `F-008` 的示意指纹逐位对比，只有三位不同，得到 `distance=3`；`F-012` 与 `F-013` 的距离是 4。两组均小于或等于演示阈值 5，所以进入人工核对清单。这些距离来自构造数据，不能据此估计真实采集场景的误报率。## 三、顺序筛查不能随便跳过批次边界第二段代码把“最近一张已保留候选”作为比较参照。这里特意不用“上一张输入”，否则连续三张接近的照片中，第二张被标记之后，第三张可能与第二张接近、却与第一张不同；它会让参照关系难以向使用者解释。输出中同时保留 `referenceId`，在详情页面能看到当前提醒是与谁相似。tsexport interface FrameMark { id: string; sessionId: string; fingerprint: string;}export interface FrameDecision { id: string; referenceId: string; distance: number; decision: string;}export function classifyFrames(items: FrameMark[], threshold: number): FrameDecision[] { const rows: FrameDecision[] = []; let lastKept: FrameMark | undefined; for (const item of items) { if (!lastKept || lastKept.sessionId !== item.sessionId) { rows.push({ id: item.id, referenceId: ‘-’, distance: -1, decision: ‘KEEP’ }); lastKept = item; continue; } const distance: number = hamming64(item.fingerprint, lastKept.fingerprint); const near: boolean = distance <= threshold; rows.push({ id: item.id, referenceId: lastKept.id, distance, decision: near ? ‘REVIEW_DUPLICATE’ : ‘KEEP’ }); if (!near) lastKept = item; } return rows;}这段代码没有删除操作，输出只是诊断结论。新的 `sessionId` 会重置比较参照，防止两个不同拍摄会话碰巧出现相似图像时互相污染。阈值还应限制为合法整数并纳入配置版本，这里调用方固定传入 5；生产环境不能把从服务端随意读到的负数或者超大值直接塞进去。判断方法本身也有代价：只和最近一张保留帧比较，计算量小、结果可解释，却可能漏掉相隔很远的重复机位。如果需求变成“整个素材库检索相似照片”，就需要另做索引和分组算法，不能继续把这段顺序扫描包装成全局查重。本文选择的是一条适合拍摄现场的轻量提醒路线，而非覆盖所有近邻的检索服务。![](https://i-blog.csdnimg.cn/direct/f6ca33769d1b46f79886288b8fecfb5c.png)## 四、结果页要让人看清理由页面上把“输入 16”“保留候选 11”“待复核 5”和“阈值 ≤5 位”分开陈列，不用一个绿色的“筛查成功”遮住风险。具体条目至少带帧号、参照帧号和距离，例如 `F-008 ↔ F-007，3 bits`。即便人工最终决定保留 `F-008`，也不应改写系统曾经提示过它的历史；可以追加确认人、确认时间及理由，保留一次完整的处理链。第三段代码展示 ArkUI 怎样呈现诊断结果。示例的 `sampleFrames` 来自项目内静态构造数据 `Fixtures.ets`，不是系统相机返回值；文章省略了 16 份冗长二进制样本，避免让伪造字符串挤占正文。页面只维护当前报告，真正要持久化人工选择时，应另建一份用户决策记录，而不是直接修改 `FrameMark` 原始输入。tsimport { FrameMark, FrameDecision, classifyFrames } from ‘…/model/HashGate’;import { sampleFrames } from ‘…/model/Fixtures’;@Entry@Componentstruct FrameAuditPage { @State rows: FrameDecision[] = []; private frames: FrameMark[] = sampleFrames; build() { Column({ space: 12 }) { Text(‘FD-306 · 3DGS近重复帧筛查’) Button(‘生成复核清单’).onClick(() => { this.rows = classifyFrames(this.frames, 5); }) ForEach(this.rows, (row: FrameDecision) => { Text(${row.id} / ${row.referenceId} / ${row.decision}) .fontSize(14) }, (row: FrameDecision) => row.id) }.padding(18) }}````@State 负责让报告重算后刷新界面；ForEach使用帧 ID 作稳定键，防止列表顺序变化时把一项旧视图错误复用到别的帧。重要的是计算与展示分离：换成平板或折叠屏只是决定一行显示几个缩略图，不应改变classifyFrames 对同一批指纹的输出。若用户在检查期间删除了素材，应重新建立当前批次快照，而不是只在界面上减掉一个计数。![](https://i-blog.csdnimg.cn/direct/b47e0e6a80734337bfc920f797abf283.png)## 五、演示数字与真正验收之间隔着什么本次构造样例中，F-004、F-008、F-011、F-013、F-016被标记为待复核，另外 11 项进入保留候选。这是用来说明输出格式与交互方式的测试向量，没有经过真实相机图像解码，更没有进入 3DGS 训练、重建或渲染管线。尤其不能把“保留 11 帧”理解成“只需 11 帧就能得到好模型”。若接入现场工程，我会要求数据链条补齐三件事：第一，保存原始素材不可变标识和指纹算法版本，避免同名覆盖；第二，用不同光照、旋转、透视和重复机位组成一组标注样本，统计漏报和误报，再调整阈值；第三，保留人工恢复操作，任何自动建议都不能直接覆盖原件。日志优先只写帧 ID、距离、阈值和结果，不打印完整图片内容或可识别的外部路径。调试时还有一个容易遗漏的点：样本顺序必须稳定。相机回调到达顺序未必等同拍摄时间，如果先拿“接收顺序”比较，再拿“拍摄序号”展示，会让参照帧关系对不上。应在业务输入层完成排序、去除重复 ID 和批次隔离；没有可信顺序的帧先进入待整理队列，而不是让扫描器暗自猜测。这条预检链路最终只给出一句有节制的结论：当前采集批次出现五项值得人工回看的近重复提示。它没有判断深度、相机位姿、场景纹理是否足够，更没有替代华为 3DGS 端侧重建的正式输入与能力校验。技术能做的不是让每个步骤都显示通过，而是把它知道什么、不知道什么讲清楚。**官方资料与适用边界：** 华为 HarmonyOS 空间计算能力总览https://developer.huawei.com/consumer/cn/features/spatialization；3DGS 管线文档入口 https://developer.huawei.com/consumer/cn/doc/harmonyos-guides/spatial-recon-c-spatial-recon-pipeline`。本文使用的指纹生成假设、汉明距离、候选筛查和页面名称均为应用示例，并非官方重建 SDK 接口；示意图及日志不是实际设备测试结果。