ykcheungab a1314a02cb 界面显示每帧耗时与摄像头自身帧率，让低帧率可归因 - What: SdkPacket 新增 capture_fps（采集源自报的发布速率，与 fps 同一窗口）与 capture_dropped（SDK 后台读取线程累计的"发布了但没人取走"的帧数）；sdk_worker 的循环记录 (t0, 已发布序号) 并在每帧算出摄像头自身的发布速率，同时读 dropped_frames；新增 _capture_source()/_capture_dropped() 两个取值助手（原 _capture_sequence 里的取值逻辑抽出来复用）。app_window 在 视图▸显示帧率 打开时把这一段一起显示在轨道摘要上：16.7 FPS · 12 ms · 摄像头 30.0 (-13)——速率是我们消费的、耗时是每帧全部开销、摄像头速率是采集源自己发布的；两个速率不一致时后面的 (-N) 就是"摄像头有、我们没接住"的帧数。新增 locale 键 status.rail_camera_fps（中英）。tests/test_worker_frame_rate.py：假设备的采集源现在也像 orisys.capture.source 一样统计"发布时上一帧还没被取走"的丢帧，并支持给 get_img 加一个可配置的每帧耗时（PROCESS_COST_S）；新增 test_the_camera_s_own_rate_is_reported_next_to_ours：循环跟得上时摄像头速率≈30、丢帧 0；把流水线放到 60 ms/帧后我们的速率掉到 22 以下、**摄像头速率仍报 30**、丢帧 >5。 - Why: 用户报"上方显示 16.7 fps 而不是实际 30"，并且给出了关键数据：16.7 fps 但每帧只耗 12 ms。12 ms 的工作量塞进 60 ms 的周期里，说明循环大部分时间在等——而"等"有两种完全不同的原因：(a) 摄像头/驱动只发布 16.7（USB 带宽、MJPG/YUYV、格式协商），(b) 摄像头发布 30 而我们只取到一半（节拍与轮询问题）。原来的读数只有"我们消费了多少"，两种情形长得一模一样，无法判断，所以这不是显示 bug 而是**读数缺一半**。SDK 的 status.last_seq 与 dropped_frames 正好提供另一半（last_seq 每发布一帧就自增，与消费者无关；dropped_frames 在发布时若上一帧仍在缓存里就 +1，即消费者的亏欠），因此把它读出来即可判定。 - Verification: shared 全量 160 passed（新增 2 项，含上面的归因测试）；studio 90 passed；ui_check 554 项检查 0 失败；locale_check 287 字面键全部命中、中英键集一致。过程中自查出一个我自己引入的问题：最初把 (t0, 序号) 的记录与按时间裁剪放在**每次轮询**里，而等待期间该分支每秒会进几万次，列表推导把 GIL 抢光，假摄像头的发布速率从 30 掉到 8（test_the_same_frame_is_not_counted_twice 立刻变红）——改为"仅在该序号发生变化时记录"，即为每发布帧 O(1) 而非每轮询 O(n)。 - Not in this change: 未改节拍/等待逻辑（假设备上 30 fps 与 60 ms 慢流水线两种情形的消费速率都符合预期，未发现节拍 bug）；frames.csv 仍未记录 process_ms/capture_fps（下次改记录格式时一并加）。

2026-09-14 12:07:28 +08:00

..

test_calibration_identity.py

Browse a long recording from disk instead of loading it into memory

2026-09-13 16:54:26 +08:00

test_calibration_model.py

Browse a long recording from disk instead of loading it into memory

2026-09-13 16:54:26 +08:00

test_calibration_record.py

Browse a long recording from disk instead of loading it into memory

2026-09-13 16:54:26 +08:00

test_display_units.py

Browse a long recording from disk instead of loading it into memory

2026-09-13 16:54:26 +08:00

test_experiment_recorder.py

record the full experiment: video, CSV and metadata

2026-09-13 13:14:10 +08:00

test_force_filters.py

曲线图表头加齿轮，绘图设置对话框里可以直接调滤波 - What: ui/icons.py 新增 settings（齿轮）图标（八个齿 + 圆环，颜色取自主题 token，与另外三个图标同一套画法）；force_plots.py 表头新增 btn_settings 与 plot_settings_requested 信号（放在缩放按钮之后、单位芯片之前），换主题时一并重绘图标，retranslate 里补 tooltip/可访问名；plot_settings_dialog.py 增加"滤波"分区：预设下拉（off/low_latency/balanced/low_noise + 自定义，显示的就是写进 sensor.json 的那个名字）、光流 EMA α（0.05–1.00，1.00 = 关）、中值窗口（1–31，1 = 关）、低通截止（0–60 Hz，0 = 关）、低通阶数（1–6）、采样率（"自动跟随帧率"复选框 + 固定值）、"同时显示未滤波曲线"；选预设即写入该预设的数值，手改任一数值自动切到"自定义"，选中的预设名会随 filter_values() 一起带出（preset 字段），"_reset_defaults" 回到"什么都不滤"；对话框底部按当前数值给提示：光流 EMA 打开时提示"这是测量设置、两次录制不可比"、全关时提示"当前不滤波"、录制中显示"录制中不能更改滤波"并禁用整个分区；截止频率达到或超过奈奎斯特（帧率一半）时用 dialog.filter_nyquist 明确说出"设备不会滤"，其中 cutoff/nyquist/rate 三个数字由 FilterSettings.nyquist_issue() 提供（problems() 仍返回英文串供日志与测试用，判断条件只有一处）。filters.py 新增 FALLBACK_PRESETS 与 available_presets()（SDK 能导入就用 SDK 的 FILTER_PRESETS，导入不了才用这份文档副本，测试保证两者逐值一致）。app_window.py：把 plot_settings_requested 接到 _on_plot_settings，打开对话框时传入当前 _filter_settings()、filters_locked（正在跑或正在录）、以及 _device_sample_rate()（实测帧率优先，否则 30 fps，用于奈奎斯特检查）；接受后把 filter_values().as_dict() 逐键写成 plot_* 偏好（与 _filter_settings() 读回的是同一组键），未在采集时立刻 set_filter_settings() 交给两个 worker，并在状态栏回报"已保存：{describe}（下次采集生效）"。两个 locale 文件补齐 21+3 个新键，中英各 343 键一一对应。tests/test_ui_smoke.py 新增 4 项：齿轮确实触发设置信号、预设/自定义切换与数值一致、录制中分区被禁用且给出理由、对话框写的键与 _filter_settings 读回的键是同一组。 - Why: 用户要求"建议曲线图增加一个齿轮的配置按键，可以调节曲线图的上限和滤波等"。此前滤波只能靠手改 preferences.json 的 plot_* 键（上一轮留下的口子），而 app 默认已改成"什么都不滤"——没有这个入口，等于把默认变成了唯一选择。 - Verification: studio 全量 89 passed（原 85 + 新增 4）；shared 全量 158 passed；ui_check 554 项检查 0 失败；.repro/locale_check.py 扫描 64 个源文件里 287 个 t("…") 字面键，两个 locale 全部命中且键集合完全相同（343/343）；离屏实测对话框：预设 balanced→flowEMA(0.5)+median(3)、改中值→自定义、选 low_noise→带低通、30 Hz 采样率下填 30 Hz 截止→弹出奈奎斯特警告、恢复默认→off/不滤波。 - Not in this change: CSV 的 17 列与未滤波第二 buffer（SessionStore/记录格式版本）、回放界面显示滤波前曲线、标定面板显示 filters 块、发布说明里"默认不再滤波"的措辞。

2026-09-14 11:08:25 +08:00

test_force_history.py

update to match calibration data handling

2026-09-10 21:50:36 +08:00

test_history_source.py

Browse a long recording from disk instead of loading it into memory

2026-09-13 16:54:26 +08:00

test_module_boundaries.py

删除深度重算引擎；修好回放视频每帧重开文件导致的无法播放，运输控制改到状态轨主按钮 - What: 1) 彻底删除深度重算引擎：shared/.../record/depth.py（DepthRecomputer/DepthResult）与 depth_backends.py（BoxReplay/FingerReplay）、其专属测试 test_depth_replay.py，record/__init__ 不再导出，playback.py::replay_warnings 不再报 depth_recomputed；apps/studio/replay.py 由 515 行瘦身为只做读盘+游标+视频帧+提示，回放视图的 2D 面板只提供「原始图像」；session.json 的 depth.replay 由 recompute 改为 none；删除 31 个只剩深度使用的文案键（depth_*/warn_state_*/warn_reset_*），warn_config_changed 与 warn_sdk_changed 改为描述"由视频重算"；ui_check 深度段、studio 两个深度用例、test_playback 三例、drive_shared 的 test_depth_replay 与 reproduce.py 的深度段一并清理（shared 套件 150→134 项）。2) 无法播放的根因是 RecordingReader.video_frame_at 每帧都 cv2.VideoCapture 重开并 seek：小片段已 ~10 ms/帧，1080p H.264 每次 seek 需从关键帧解码（上百 ms），而播放每 33 ms 要一帧且全在 UI 线程上，视频因此看着不动；改为按分段缓存解码器、顺序帧用 read() 步进（实测 10 ms → 0.5 ms/帧）、跳转才 seek，新增 RecordingReader.close() 释放。运输控制按用户建议上移到状态轨主按钮：toolbar.set_run_role("playback") 使回放视图的主按钮变成「▶ 回放」/「⏸ 暂停」（实时视图仍是「▶ 运行」），点按以 1× 推进游标（墙钟计时，漏拍不变慢）、到末尾自动停，拖动游标/框选/滚轮/拖总览条经 ForcePlotsPanel.timeline_taken_over 自动暂停，空格键同效；曲线表头不再放第二个播放按钮；按钮样式在回放角色下不再套用"停止"的红色语义。 - Why: 用户要求先清掉深度重算引擎、并反馈"现在无法播放视频"，建议把上方播放按钮在历史回放形式下改为回放。 - Verification: ui_check.py 554 项 0 失败（新增 seek<250ms/步进<60ms 的解码预算、回放按钮文字随播放/暂停切换、手动拖游标即暂停、切回实时视图按钮恢复运行、按深度视图已移除）；test_ui_smoke.py 71 项 0 失败；drive_shared.py 134 项 0 失败（深度引擎用例随代码删除）；locale_studio.py 262 键齐全、zh==en；reproduce.py 退出 0；.repro/probe_play.py 实测按「回放」后 0.75 s 内游标推进 0.689 s、面板 12/12 帧都在更新；两张复核图（回放视图的「▶ 回放」、实时视图的「▶ 运行」）。 - Not in this change: 录制文件格式与 CSV 列序不变（raw_*.mp4 与 forces.csv 继续一起写）；「由视频重算」复核模式保留（它复用实时管线，是有状态、只能顺序前进的一遍）。

2026-09-14 09:31:21 +08:00

test_playback.py

删除深度重算引擎；修好回放视频每帧重开文件导致的无法播放，运输控制改到状态轨主按钮 - What: 1) 彻底删除深度重算引擎：shared/.../record/depth.py（DepthRecomputer/DepthResult）与 depth_backends.py（BoxReplay/FingerReplay）、其专属测试 test_depth_replay.py，record/__init__ 不再导出，playback.py::replay_warnings 不再报 depth_recomputed；apps/studio/replay.py 由 515 行瘦身为只做读盘+游标+视频帧+提示，回放视图的 2D 面板只提供「原始图像」；session.json 的 depth.replay 由 recompute 改为 none；删除 31 个只剩深度使用的文案键（depth_*/warn_state_*/warn_reset_*），warn_config_changed 与 warn_sdk_changed 改为描述"由视频重算"；ui_check 深度段、studio 两个深度用例、test_playback 三例、drive_shared 的 test_depth_replay 与 reproduce.py 的深度段一并清理（shared 套件 150→134 项）。2) 无法播放的根因是 RecordingReader.video_frame_at 每帧都 cv2.VideoCapture 重开并 seek：小片段已 ~10 ms/帧，1080p H.264 每次 seek 需从关键帧解码（上百 ms），而播放每 33 ms 要一帧且全在 UI 线程上，视频因此看着不动；改为按分段缓存解码器、顺序帧用 read() 步进（实测 10 ms → 0.5 ms/帧）、跳转才 seek，新增 RecordingReader.close() 释放。运输控制按用户建议上移到状态轨主按钮：toolbar.set_run_role("playback") 使回放视图的主按钮变成「▶ 回放」/「⏸ 暂停」（实时视图仍是「▶ 运行」），点按以 1× 推进游标（墙钟计时，漏拍不变慢）、到末尾自动停，拖动游标/框选/滚轮/拖总览条经 ForcePlotsPanel.timeline_taken_over 自动暂停，空格键同效；曲线表头不再放第二个播放按钮；按钮样式在回放角色下不再套用"停止"的红色语义。 - Why: 用户要求先清掉深度重算引擎、并反馈"现在无法播放视频"，建议把上方播放按钮在历史回放形式下改为回放。 - Verification: ui_check.py 554 项 0 失败（新增 seek<250ms/步进<60ms 的解码预算、回放按钮文字随播放/暂停切换、手动拖游标即暂停、切回实时视图按钮恢复运行、按深度视图已移除）；test_ui_smoke.py 71 项 0 失败；drive_shared.py 134 项 0 失败（深度引擎用例随代码删除）；locale_studio.py 262 键齐全、zh==en；reproduce.py 退出 0；.repro/probe_play.py 实测按「回放」后 0.75 s 内游标推进 0.689 s、面板 12/12 帧都在更新；两张复核图（回放视图的「▶ 回放」、实时视图的「▶ 运行」）。 - Not in this change: 录制文件格式与 CSV 列序不变（raw_*.mp4 与 forces.csv 继续一起写）；「由视频重算」复核模式保留（它复用实时管线，是有状态、只能顺序前进的一遍）。

2026-09-14 09:31:21 +08:00

test_record_channel.py

cd D:\orisys_ws\orisys-app

2026-09-13 14:01:24 +08:00

test_record_lifecycle.py

Browse a long recording from disk instead of loading it into memory

2026-09-13 16:54:26 +08:00

test_record_semantics.py

Fix the phase-1/2 review findings in recording, calibration and depth replay

2026-09-13 14:55:53 +08:00

test_worker_cancellation.py

fix stop button disabled during connection

2026-09-12 20:27:34 +08:00

test_worker_frame_rate.py

界面显示每帧耗时与摄像头自身帧率，让低帧率可归因 - What: SdkPacket 新增 capture_fps（采集源自报的发布速率，与 fps 同一窗口）与 capture_dropped（SDK 后台读取线程累计的"发布了但没人取走"的帧数）；sdk_worker 的循环记录 (t0, 已发布序号) 并在每帧算出摄像头自身的发布速率，同时读 dropped_frames；新增 _capture_source()/_capture_dropped() 两个取值助手（原 _capture_sequence 里的取值逻辑抽出来复用）。app_window 在 视图▸显示帧率 打开时把这一段一起显示在轨道摘要上：16.7 FPS · 12 ms · 摄像头 30.0 (-13)——速率是我们消费的、耗时是每帧全部开销、摄像头速率是采集源自己发布的；两个速率不一致时后面的 (-N) 就是"摄像头有、我们没接住"的帧数。新增 locale 键 status.rail_camera_fps（中英）。tests/test_worker_frame_rate.py：假设备的采集源现在也像 orisys.capture.source 一样统计"发布时上一帧还没被取走"的丢帧，并支持给 get_img 加一个可配置的每帧耗时（PROCESS_COST_S）；新增 test_the_camera_s_own_rate_is_reported_next_to_ours：循环跟得上时摄像头速率≈30、丢帧 0；把流水线放到 60 ms/帧后我们的速率掉到 22 以下、**摄像头速率仍报 30**、丢帧 >5。 - Why: 用户报"上方显示 16.7 fps 而不是实际 30"，并且给出了关键数据：16.7 fps 但每帧只耗 12 ms。12 ms 的工作量塞进 60 ms 的周期里，说明循环大部分时间在等——而"等"有两种完全不同的原因：(a) 摄像头/驱动只发布 16.7（USB 带宽、MJPG/YUYV、格式协商），(b) 摄像头发布 30 而我们只取到一半（节拍与轮询问题）。原来的读数只有"我们消费了多少"，两种情形长得一模一样，无法判断，所以这不是显示 bug 而是**读数缺一半**。SDK 的 status.last_seq 与 dropped_frames 正好提供另一半（last_seq 每发布一帧就自增，与消费者无关；dropped_frames 在发布时若上一帧仍在缓存里就 +1，即消费者的亏欠），因此把它读出来即可判定。 - Verification: shared 全量 160 passed（新增 2 项，含上面的归因测试）；studio 90 passed；ui_check 554 项检查 0 失败；locale_check 287 字面键全部命中、中英键集一致。过程中自查出一个我自己引入的问题：最初把 (t0, 序号) 的记录与按时间裁剪放在**每次轮询**里，而等待期间该分支每秒会进几万次，列表推导把 GIL 抢光，假摄像头的发布速率从 30 掉到 8（test_the_same_frame_is_not_counted_twice 立刻变红）——改为"仅在该序号发生变化时记录"，即为每发布帧 O(1) 而非每轮询 O(n)。 - Not in this change: 未改节拍/等待逻辑（假设备上 30 fps 与 60 ms 慢流水线两种情形的消费速率都符合预期，未发现节拍 bug）；frames.csv 仍未记录 process_ms/capture_fps（下次改记录格式时一并加）。

2026-09-14 12:07:28 +08:00