From 07f1651040683e23dca267d6b3ca129a5c9f6453 Mon Sep 17 00:00:00 2001 From: crosstyan Date: Tue, 9 Dec 2025 16:46:57 +0800 Subject: [PATCH] Update README with additional notes on OpenCap and data flow considerations --- README.md | 29 ++++++++++++++++++++--------- 1 file changed, 20 insertions(+), 9 deletions(-) diff --git a/README.md b/README.md index 276a3e9..e412936 100644 --- a/README.md +++ b/README.md @@ -45,7 +45,12 @@ #### [OpenCap](https://www.opencap.ai) 和 [Pose2Sim](https://github.com/perfanalytics/pose2sim) 试图做的事情似乎类似, 但是给的管线是基于两台 -iPhone 便可实现的, 更加成熟 +iPhone 便可实现的, 更偏向 commercial + +> [!NOTE] +> 我估计 OpenCap 选择 iPhone 是因为其 ARKit 有 self-calibration 的能力 (只是猜测) + +论文: [OpenCap: Human movement dynamics from smartphone videos](https://doi.org/10.1371/journal.pcbi.1011462) #### [Sports2D](https://github.com/davidpagnon/Sports2D) @@ -64,24 +69,30 @@ iPhone 便可实现的, 更加成熟 ## 注意 -devil is in the details +Devil is in the details. 架构图画完并不算完成——真正的问题都藏在横线里。 -每一个数据流, 其 source 从哪里来, 以什么格式 (tensor? image? encoded video? byte stream?) 传输, -传输的协议 (socket? shared memory? file IO?) 是什么, 传输的频率是多少 (等间隔? 若等间隔, 采样频率是多少 Hz? 不等间隔时间戳哪里来的? 以什么为时基?) 预估的带宽是多少? (这又决定了传输协议的选择) +对系统里的每一条数据流，你都得说清楚： -必定有 source 与 sink, 还需要填充中间的部分 (能填充得越详细越好) +- 数据从哪来、要到哪去，中间经过哪些环节（别只写一个"大盒子"）。 +- 传的到底是什么：图像？压缩视频？张量？keypoints？字节流？字段怎么定义？ +- 怎么传：socket、共享内存、文件、消息队列？你选它的理由是什么？延迟/吞吐/背压怎么处理？ +- 多快传：固定 Hz 还是乱序/抖动？时间戳是谁给的，用的是什么时基？怎么对齐多相机？ +- 大概多大：带宽估算要写出来，因为这会反过来决定你能不能用某种协议。 -是单个进程还是多个进程? (答案应该是显然的) 能否分布式? (边缘计算的扩展可能) +另外别忘了：系统必然有 source 和 sink——你还得把中间每一段填满，填得越细越好； -表示层往往是 sink, 而渲染 3D 表示往往是 (游戏) 引擎等价的工作量 +再往上一步：你到底是单进程、单机多进程，还是天然就要分布式？（答案往往很显然）将来要做边缘计算时，哪些东西能下沉到边缘，哪些必须留在中心？ -可以用 LLM, 但是能否分辨祂是否在胡说八道? +最后提醒一句：表示层通常是终点，但 3D 渲染/交互的工作量经常等价于做半个 (游戏) 引擎——别指望 "顺手画一下" + +> [!NOTE] +> 注：允许使用 LLM 辅助调研与写作，但需要你能够指出其结论的依据、假设与不确定性；换言之，你必须证明自己能识别"看似合理但实际上不成立" 的回答。 ## 参考答案 AI 生成的架构图, 不代表我此刻的实际想法, which changes every moment. -能把每一个横线的细节都填上嘛? (确实有许多纰漏) +能把每一个横线的细节都填上嘛? (在本文行文时时回顾发现其中确实有许多纰漏, 而我暂且无意修正) ```mermaid flowchart TD