基于事件的视觉软件处理什么?
事件摄像机报告亮度变化,而不是在每个时间间隔提供传统的视频帧。解码事件通常标识像素、极性和时间戳。您的应用程序必须通过获取、过滤、记录和推理来保留这些字段的含义。的 基于事件与基于帧的比较 解释该数据模型何时有用。
区分设计中的三种格式:传感器或传输编码、软件使用的解码事件表示以及传递给算法的表示。包含原始传感器数据包、解码事件数组和累积图像的文件有不同的用途。它们之间的转换可以改变内存使用、处理成本和下游可用的计时信息。
| 代表 | 有用于 | 整合问题 |
|---|---|---|
| 原始数据包或供应商记录 | 再现采集和解码行为 | 部署的解码器可以读取这个确切的设备和格式修订吗? |
| 解码事件 | 过滤、时序分析和事件原生算法 | 时间戳单位、时钟域和坐标约定是什么? |
| 时间表面或类体素张量 | 需要结构化时间表示的算法 | 必须重现哪些历史记录、分箱和标准化设置? |
| 累积事件图像 | 可视化或兼容的基于图像的处理阶段 | 累积窗口会引入多少延迟和信息损失? |
如何评估事件相机 SDK
从精确的传感器、相机固件和主机平台开始。桌面演示不支持嵌入式 Linux 映像、ARM 处理器或您的生产许可证。向供应商询问支持的操作系统、CPU 架构、重新分配条件和相机接口要求。在提交 载板 之前验证预期平台上的应用程序。
- 收购: 设备发现、配置、解码和错误报告。
- 时间安排: 时间戳起源、翻转处理、外部触发器和多设备对齐。
- 重现性: 记录、配置导出和识别的软件版本。
- 部署: 无头操作、支持的二进制文件、重启行为和许可条款。
- 可观测性: 事件计数、队列深度、丢弃的数据和主机资源使用情况。
构建具有明确时序边界的管道
将采集与昂贵的可视化、磁盘写入和模型推理分开。否则,缓慢的消费者可能会在算法开始之前延迟新数据。定义有界队列和显式过载策略。删除最旧的窗口、减少感兴趣区域以及因错误而停止会产生不同的后果;选择适合应用程序的行为并在发生时进行记录。
使用传感器时间戳来描述观察发生的时间,并使用单调主机时钟来测量处理持续时间。从不相关的时钟中减去时间戳不会产生有效的端到端延迟。如果相机必须与 IMU 或传统相机结合使用,请建立我们的时钟关系和校准过程中描述的 传感器融合同步指南.
一个小的记录检查示例
以下 Python 示例对支持的记录中的解码事件进行计数并报告其时间戳的跨度。它使用已记录的 Metavision 流媒体 API,并需要兼容的 SDK 安装和录制。这是一个检查示例,而不是 ALVEXIS 相机基准或探测器。
import argparse
from metavision_sdk_stream import Camera, CameraStreamSlicer
parser = argparse.ArgumentParser()
parser.add_argument("recording")
args = parser.parse_args()
source = Camera.from_file(args.recording)
count, first_us, last_us = 0, None, None
for batch in CameraStreamSlicer(source.move()):
events = batch.events
if events.size:
start = int(events["t"][0])
end = int(events["t"][-1])
first_us = start if first_us is None else min(first_us, start)
last_us = end if last_us is None else max(last_us, end)
count += int(events.size)
span_s = 0.0 if first_us is None else (last_us - first_us) / 1_000_000
print({"events": count, "event_timestamp_span_s": span_s})
时间戳范围涵盖第一个到最后一个观察到的事件;它不测量文件持续时间、采集延迟或处理吞吐量。空期和时钟重置需要在生产中单独处理。将设备配置和记录元数据与文件一起保留,以便第二位工程师可以重现解释。
验证安静场景、繁忙场景和故障恢复
测试静止场景、代表性运动和故意要求较高的场景。闪烁、相机振动和纹理运动可能会产生截然不同的事件率。记录典型行为和您观察到的最坏情况。在存储和通信处于活动状态时重复此操作,因为这些工作负载会争夺内存和 CPU 时间。
| 测试 | 记录 | 支持的决定 |
|---|---|---|
| 重播相同的录音 | 配置、输出差异和处理持续时间 | 软件变更可以重复评估吗? |
| 增加场景活跃度 | 队列深度、事件丢失和输出年龄 | 系统在峰值负载下是否仍然可用? |
| 更改处理窗口 | 应用精度和传感器到输出延迟 | 哪种时间/细节权衡符合要求? |
| 断开并重新连接设备 | 恢复时间、时钟重置和记录连续性 | 已部署的服务能否按预期恢复? |
当算法使用神经网络时,在选择加速器之前检查生成的张量和支持的运算符。事件摄像机不会自动需要 NPU,并且 NPU 不会自动接受事件流。我们的 FPGA、NPU 和 MPU 架构指南 将采集、预处理、推理和应用服务分开。
选择软件堆栈之前的问题
我可以使用普通的计算机视觉模型吗?
仅在定义兼容的输入表示并验证其行为之后。将事件累积到图像中可以允许重用图像处理阶段,但会改变数据分布并添加定时窗口。根据代表性数据评估完整的应用程序。
可用的笔记本电脑演示是否证明了嵌入式兼容性?
否。确认实际目标平台的CPU架构、操作系统、传感器接口、驱动程序、SDK许可证和持续资源使用情况。
我应该发送什么内容来进行整合讨论?
发送相机或传感器参考、样本记录、预期输出、可接受的延迟、主机平台、接口和部署环境。这些投入使讨论足够具体,足以识别第一个集成风险。
计算机视觉管道中的神经形态视觉
事件相机经常在神经拟态视觉下讨论,因为它们的输出记录单个像素的变化,而不是完整图像的固定序列。该数据表示不会自动提供对象检测或神经网络结果。该软件仍然需要定义的任务、兼容的算法和可衡量的验收标准。
当与面向帧的计算机视觉工具集成时,事件流可以转换为时间窗口图像或其他表示。如果任务依赖于精细的时间信息,则保留原始时间戳。评估完整的转换和处理流程;仅凭有吸引力的重建图像并不能确定最终应用程序的准确性或延迟。
技术参考
供应商示例描述了他们自己支持的生态系统。确认所选设备和部署的兼容性和许可。
