Update README with additional notes on OpenCap and data flow considerations

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