task: centralize frame-key serialization
还没有人认领这个 Issue。
评估
调研方向
首先定位 pickle 和 shelf 代码路径中现有的帧键宽度计算，然后比较每个路径如何读取和写入 frame0、frame09 和 frame00042 等键。在保留这些键的同时集中统一格式化器，并验证空帧处理不会复现 #3485 中描述的 log10(0) 失败。
由索引模型根据 Issue 内容生成。
描述
Summary
The PyTorch video-analysis pipeline currently hand-computes frame-key padding
widths in multiple places and stores per-frame outputs under string keys such as
frame0, frame09, or frame00042.
This works, but it is a low-level serialization detail that is easy to get
wrong, e.g. see #3485 where where log10(0) for empty frames raised an
OverflowError.
Motivation
- Frame-key formatting is an implementation detail, but callers currently need
to reason aboutkey_str_width. - Width calculations are subtle because they depend on the highest frame index,
not just the total number of frames in an intuitive way. - Read/write code should ideally share one canonical frame-key formatter.
Design Goals
- Centralize all frame-key logic in one place.
- Preserve the existing on-disk key format for backward compatibility.
- Reduce duplicate logic across pickle and shelf code paths.
- 主要语言
- Python
- 星标
- 5.8k
- 派生
- 1.8k
- 平均合并
- 3 天 18 小时
- 30 天内合并 PR
- 29
贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
DeepLabCut/DeepLabCut 的其他 Issue
-
napari-dlc
DeepLabCut/DeepLabCut#3524 · 1 条评论 · 已指派 1 人 ·
-
config enhancement metrics pytorch
DeepLabCut/DeepLabCut#3521 · 已指派 2 人 ·
-
bug metrics pytorch
DeepLabCut/DeepLabCut#3518 · 1 条评论 · 已指派 1 人 ·
-
CI enhancement
DeepLabCut/DeepLabCut#3517 · 1 条评论 · 已指派 2 人 ·
-
DeepLabCut/DeepLabCut#3493 · 已指派 1 人 ·
查看 DeepLabCut/DeepLabCut 的全部 Issue
相似的 Issue
-
enhancement
难度 2/5 1-3 小时 新手友好度 70/100
canonical/paas-charm#368 · 1 条评论 ·
-
难度 2/5 1-3 小时 新手友好度 75/100
-
tech debt
难度 2/5 1-3 小时 新手友好度 75/100
-
难度 1/5 1 小时以内 新手友好度 90/100
StevenBlack/hosts#3256 ·
-
难度 1/5 1 小时以内 新手友好度 90/100
qualcomm/qai-appbuilder#275 ·