Skip to content
Projects
Groups
Snippets
Help
Loading...
Help
Submit feedback
Contribute to GitLab
Sign in / Register
Toggle navigation
L
libpdafdoc
Project
Project
Details
Activity
Releases
Cycle Analytics
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Charts
Issues
0
Issues
0
List
Board
Labels
Milestones
Merge Requests
0
Merge Requests
0
CI / CD
CI / CD
Pipelines
Jobs
Schedules
Charts
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Charts
Create a new issue
Jobs
Commits
Issue Boards
Open sidebar
尹洪福
libpdafdoc
Commits
58524948
Commit
58524948
authored
Mar 17, 2026
by
尹洪福
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
update
parent
49440e10
Changes
3
Hide whitespace changes
Inline
Side-by-side
Showing
3 changed files
with
55 additions
and
2 deletions
+55
-2
pd和fv出图方案选择.png
img/pd和fv出图方案选择.png
+0
-0
pd和fv出图流程.png
img/pd和fv出图流程.png
+0
-0
分工g.md
分工g.md
+55
-2
No files found.
img/pd和fv出图方案选择.png
0 → 100644
View file @
58524948
451 KB
img/pd和fv出图流程.png
0 → 100644
View file @
58524948
377 KB
分工g.md
View file @
58524948
...
...
@@ -12,11 +12,11 @@
1.
优化策略
重要:
-
FV unit
-
FV unit
1.
接口模块 / hisi /软实现?
-
SAD unit
1.
目标?场景检测
2.
hisi SAD 具体怎么算
2.
hisi SAD 具体怎么算
3.
时间延迟
-
TOF unit
1.
目标
...
...
@@ -27,6 +27,35 @@
-
各个unit分离
-
插拔式
> **FV unit — 用 HiSi ISP 硬件 AF stats,不要软实现**
> - Hi3519DV500 ISP 本身就出 AF 统计(H1/V1/H2/V2),硬件算的,零 CPU 开销,延迟最低
> - 软实现(自己算 Sobel/Laplacian)没有任何优势,反而吃 CPU 还慢
> - 唯一要做的是把 ISP AF stats 配置成 12×6 zone 对齐 PD,架构文档里已经写了
> - 所以 FV unit 的工作量其实很小:配置 ISP zone 参数 + 封装读取接口
>
> **SAD unit — 优先级低,先不做独立 unit**
> - SAD 在架构里定位是对焦抑制信号(画面剧烈运动时暂停触发),不是核心链路
> - HiSi ISP 应该有帧间 SAD 统计输出,如果有就直接读,不需要自己算
> - 建议先不做独立 unit,等触发模块(PolicyModule)写到抑制信号那一层时再接入,作为 PolicyModule 内部的一个判断条件就够了
> - "具体怎么算"和"时间延迟"等到真正用的时候再调研,现阶段不阻塞任何模块
>
> **TOF unit — 远期,现在不碰**
> - 架构文档里已标注 TofProcessor 是预留
> - 5×5 稀疏数据的融合、标定、RGB 映射,这些都是独立课题,复杂度不低
> - 当前 PD+FV 都还没搞定,TOF 的优先级排在最后
> - 等 PDAF 主链路跑通后再考虑
>
> **"插拔式 / unit 分离 / 帧对齐" — 方向对,但不要为此过度抽象**
> - 各 Processor 统一输出 ZoneMap 接口,这在架构里已经定义了,天然就是"插拔式"
> - 帧对齐:PD 和 FV 帧率不同(PD ~25fps, FV ~30/60fps),架构文档里已经用分离存储 + zone index 关联解决了,不需要强同步
> - 不要为了"插拔式"去搞 plugin 注册/工厂模式之类的框架,直接在 ProcessModule 里组合几个 Processor 就行
>
> **总结优先级:**
> 1. FV — 必须做,但工作量小(配 ISP + 封装接口)
> 2. SAD — 等 PolicyModule 需要时再接
> 3. TOF — 远期
> 4. 架构上保持简单组合,不搞过度抽象
# 窗口管理
-
具体几个模式
...
...
@@ -40,6 +69,30 @@
-
归一化问题 多尺度评分/占比?业界主流方案?
-
子代码模块架构实现
> 这个方向有过度设计的风险。
>
> "融合策略"和"归一化评分"听起来像是在做通用传感器融合框架,但 AF 触发决策不需要这个。
>
> 原因:
>
> 1. 各信号角色不同,不是同一维度的东西
> - PD → 方向 + 距离(核心决策依据)
> - FV → 合焦验证(门控信号)
> - SAD/AE/AWB → 抑制信号(暂停条件)
> - 这些不适合做加权评分,它们是逻辑关系(与/或/门控),不是数值融合
> 2. 架构文档里的四层门控已经是正确做法
> 场景变化检测 → 稳定性确认 → PD 分析 → 合焦门控
> 每层有明确的通过/不通过判定,层次清晰,易调试。如果改成"多信号加权打分 > 阈值就触发",反而黑箱化了,出问题很难定位是哪个信号导致的。
> 3. 业界也不这么做
> Sony、Canon、libcamera 都是分层判定,不是融合评分。手机 ISP(高通)的 AF 触发也是条件组合,不是归一化打分。
>
> 建议:
> - 坚持四层门控架构,不搞融合评分框架
> - 每个信号独立模块化(方便单独测试验证),但决策逻辑用清晰的 if-else 层级,不用权重系数
> - 如果团队里有人坚持要"融合",可以把它限定在 WindowManager 的 zone 选择上(多 zone 的 PD conf × 距离 × 中心权重加权选最优 zone),这个确实适合做加权融合,但这是"选哪个区域对焦",不是"要不要触发对焦"
>
> 简单说:zone 选择可以融合,触发决策不要融合。
# 执行 (待议)
...
...
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment