Camera-Drop 项目总结

概述

经过周的开发，Camera-Drop 项目终于完成。项目的绝大部分工作由 xqy 佬完成，向他表示拜谢。

在项目过程中，我们遇到了不少问题，大部分问题我们都通过反复测试和修修补补解决，并在最终取得了相当不错的传输速率。不过，传输速率的数值是次要的，项目最大的成果在于 proof of concept：我们证明了 8x8 大小的、4 色 16 种图案的激进编码方案的可行性。我们有理由相信，若对这套方案再作深入研究与挖掘，能得到远比现阶段更高的传输速率。但我们应该没时间完成相应的验证与测试工作了，这些就留待后人探索吧。

注

我将传输速率定义为视频携带的有效信息量与视频时长之比，不考虑拍摄和编解码所用的时间。

过程

项目总体开发过程并不是一帆风顺的，中间经历了不少曲折。

• 第周：

  • 我确定了要做彩码，以及用大小的单元块作为图案编码单元的方案，并用朴素的方式对其能承载的颜色数和图案数做了验证与测试。
  • 完成了一些基础操作的封装；
  • 在图像定位方面，我经测试发现 OpenCV 的轮廓检测算法效果并不理想。

• 第周：

  • xqy 使用 yolo 来检测定位 Anchor，效果极其出色。
  • xqy 初步编写了 Web 端。
  • xqy 调整了图像样式标准。
  • 我封装了 Reed Solomon Code 和 Fountain Code 的编解码器，初步设计和测试冗余编码方案。

• 第周：

  • 我设计了一套严谨的冗余编解码参数方案。
  • xqy 不断优化 Web 性能，实现了完整文件传输功能。
  • xqy 为项目编写了 CI，实现了自动化构建和测试。

• 第周：因为太忙，项目停摆。

• 第周：接着摆。

• 第周：

  • xqy 实现了长条码（长宽比固定为），单帧理论容量得到了提高。
  • xqy 测试、调整了部分配置，并实现了不少工具辅助实拍解码测试。
  • xqy 经测试发现 4K 60FPS 的手机只能拍出的有效帧，导致传输速率只有可怜的~Mbps，和预期的Mbps 相去甚远。
  • xqy 实拍发现图案识别成功率太低，于是牺牲解码效率，把原来的 Hamming Distance 方案改成分类的 CNN。CNN 非常强大，模糊的图案也能识别出来，缺点就是解码器很吃 CPU 和 RAM，且解码时间很长。

• 第周：

  • 我找热心学妹借到了 iPhone 16 Pro，它能拍摄 4K 120FPS 的视频，使我们看到了曙光。
  • 花了一个晚上拍摄并测试解码，发现图案识别成功率正常，但颜色识别成功率极低，说明我们原来的颜色矫正、识别算法完全不可靠。
  • xqy 花了一天时间，优化了颜色识别算法。
  • 又花了一个晚上拍摄与测试，用一个稳健的配置跑出了我们的最终测试传输速率。

最终方案

• 冗余编解码方面，使用 Reed Solomon Code 和 Fountain Code。

• 图像编码方面：

  • 图案单元大小。
  • 颜色数。
  • 图案种类数。
  • 行单元数:列单元数 =。

• 图像解码方面：

  • 定位：使用 yolo 定位 Anchor。
  • 矫正：通过直接线性变换（DLT）求解单应矩阵实现透视变换，并采用逆向映射与最近邻插值将倾斜四边形矫正为矩形。其实就是手动实现了 cv::getPerspectiveTransform() 与 cv::warpPerspective()。
  • 图案识别：分类的迷你 CNN。
  • 颜色识别：分类的迷你 CNN。

测试结果

编码参数

---------------------------------------
Target Accuracy: 95.00%
RS Config: N = 223, K = 179, P = 44
Fountain:  M = 6 blocks/chunk, 12 chunks/frame
Redundancy factor: 1.056
Layout: aspect 16:9, image 1782x1008, grid 196x110, short-edge patterns 110
Frame Capacity: 16056 bytes
Effective Data: 12720 bytes/frame (79.22%)
---------------------------------------

拍摄情形

编码视频时长固定为秒。

• 对于一般的 4K 60FPS 的手机：

  • 短边图案单元数为。最好情况下，编码视频为FPS 时，有效帧能达到。
  • 短边图案单元数为。最好情况下，编码视频为FPS 时，有效帧能达到。
  • 最高传输速率不低于Mbps。

• 使用支持 4K 120FPS 的 iPhone 16 Pro 拍摄时：

  • 仅测试了短边图案单元数为的情况。
  • 编码视频为FPS 时，有效帧在左右。
  • 编码视频为FPS 时，有效帧最好情况下能达到。
  • 最高传输速率不低于Mbps。

课程项目的自测要求为：编码视频时长秒，测试次取平均。为追求稳定性，我们选择了非常保守的参数：短边图案单元数为，编码视频为FPS，有效帧固定为。测得传输速率为Mbps，作为我们的自测结果。

解码器性能：使用 i9-14900HX 处理器，线程用时分钟左右，RAM 占用近GB 左右；线程用时分钟左右，RAM 占用GB 左右。

提升空间

CNN 能够极大提升图案和颜色的识别准确率。我们对自测拍摄的个视频作了分析，发现每个有效帧图案和颜色的识别准确率基本保持在% 以上。我们推测，若将短边图案单元数提升为，有效帧提升为，编码参数的 acc 提升为%，仍具有较高的传输成功率，且传输速率能提升到Mbps（% 的提升）。

需要指出的是，我们是基于原来朴素的图案和颜色识别算法的测试结果，来决定编码单元的图案和颜色数的。后来我们换用了 CNN，但未对编码单元参数作调整和测试。基于目前极高的识别准确率，我们有理由猜测，若将图案数或颜色数翻倍，或减小图案单元大小，依旧能有相当可观的识别准确率。编码方案至少有% 的提升空间。

此外，课程项目并未要求做纠错，实际的评测指标是有效传输速率。这意味着，就课程项目而言，我们的冗余编码设计完全是多余的，只需要检错，不需要纠错。放弃纠错能够给我们的有效传输速率带来% 的提升。

若以上几点同时成立，则传输速率完全可以达到Mbps 以上。这些就留待后人探索了。