ykcheungab a44eb2d65d 达不到帧率的判据改用实测速率（DSHOW 回读值会说谎），探针加帧率扫描 - What: short_capture_fallacy() 改为以**实测**速率为准（新增 measured_fps 关键字参数），消息改成"it delivers about 15 fps while the config asks for 30 (1920x1080 reported 30, MJPG/DSHOW)"——把驱动自报值降级为"矛盾的一部分"而不是判据；app_window 的 _check_capture_negotiation() 相应改为用 packet 的 capture_fps（实测）判据、实测为 0 时不下结论（等窗口填满）。tools/camera_probe.py 重写：probe() 返回结构体、format_row() 把 reported 与 measured 分列并在达不到 90% 时标 "<-- misses the request"；新增 --samples 与**帧率扫描**（同一格式依次申请 60/30/20/15/10 fps，逐行给实测值与"跟随申请 / 只有申请的 x 倍"的判断，最后给"本次看到的ceiling"）。tests/test_worker_frame_rate.py 的归因测试同步更新，并显式覆盖"驱动自报 30 而实测 15 必须判为不达标"与"没有实测值时不说话"。 - Why: 用户跑探针的结果推翻了我上一轮的判据：MJPG 1920x1080@30 -> MJPG 1920x1080 @ 30.0 measured 15.0。DSHOW 后端下 CAP_PROP_FPS 只是回读你设的值，所以 SDK 的 status.fps 同样不可信 —— 我原来比较"申请 vs 协商"等于拿申请跟自己比，那个提示永远不会出现（用户实际看到的只有轨道上的实测 16.7）。这也解释了为什么这件事必须靠实测：真实速率只能测出来。另外探针显示 1280x720 MJPG 实测也是 15、YUYV 只有 1 fps，说明换分辨率不解决问题，需要区分"摄像头本身的上限"与"我们申请多少就被砍半"。 - Verification: shared 全量 161 passed（含新增/更新的 3 项断言）；studio 91 passed；ui_check 554 项检查 0 失败；探针在本机（无摄像头）仍返回 1 并给出解释，format_row/_decode 单测通过（"reported 30.0 measured 15.0 ... <-- misses the request"）。 - Not in this change: 未改 SDK 采集申请顺序/后端；未做自动降级；frames.csv 仍未记录 process_ms/capture_fps。

2026-09-14 13:38:57 +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

达不到帧率的判据改用实测速率（DSHOW 回读值会说谎），探针加帧率扫描 - What: short_capture_fallacy() 改为以**实测**速率为准（新增 measured_fps 关键字参数），消息改成"it delivers about 15 fps while the config asks for 30 (1920x1080 reported 30, MJPG/DSHOW)"——把驱动自报值降级为"矛盾的一部分"而不是判据；app_window 的 _check_capture_negotiation() 相应改为用 packet 的 capture_fps（实测）判据、实测为 0 时不下结论（等窗口填满）。tools/camera_probe.py 重写：probe() 返回结构体、format_row() 把 reported 与 measured 分列并在达不到 90% 时标 "<-- misses the request"；新增 --samples 与**帧率扫描**（同一格式依次申请 60/30/20/15/10 fps，逐行给实测值与"跟随申请 / 只有申请的 x 倍"的判断，最后给"本次看到的ceiling"）。tests/test_worker_frame_rate.py 的归因测试同步更新，并显式覆盖"驱动自报 30 而实测 15 必须判为不达标"与"没有实测值时不说话"。 - Why: 用户跑探针的结果推翻了我上一轮的判据：MJPG 1920x1080@30 -> MJPG 1920x1080 @ 30.0 measured 15.0。DSHOW 后端下 CAP_PROP_FPS 只是回读你设的值，所以 SDK 的 status.fps 同样不可信 —— 我原来比较"申请 vs 协商"等于拿申请跟自己比，那个提示永远不会出现（用户实际看到的只有轨道上的实测 16.7）。这也解释了为什么这件事必须靠实测：真实速率只能测出来。另外探针显示 1280x720 MJPG 实测也是 15、YUYV 只有 1 fps，说明换分辨率不解决问题，需要区分"摄像头本身的上限"与"我们申请多少就被砍半"。 - Verification: shared 全量 161 passed（含新增/更新的 3 项断言）；studio 91 passed；ui_check 554 项检查 0 失败；探针在本机（无摄像头）仍返回 1 并给出解释，format_row/_decode 单测通过（"reported 30.0 measured 15.0 ... <-- misses the request"）。 - Not in this change: 未改 SDK 采集申请顺序/后端；未做自动降级；frames.csv 仍未记录 process_ms/capture_fps。

2026-09-14 13:38:57 +08:00