描述

本次提交修复了 BoundingBoxEncode kernel 在处理极端或失配坐标范围的边界框（例如 anchor 坐标接近 FP32 最大值 ~3.4e38、ground-truth 坐标 ~0.01）时的精度问题。该场景下 rw = gw / pw 会下溢趋近于零，触发 NPU 硬件 Ln 指令返回 -inf 而非有限负数值。

根因： NPU AscendC::Ln 硬件指令对极小正数输入（接近 FP32 下溢阈值 ~1e-38）返回 -inf，而 CPU numpy.log 与 GPU cuda::log 能正确返回有限值（如 log(1e-30) ≈ -69.07）。原始 kernel 在 FP16 和 FP32 两条计算路径中均直接消费 Ln 原始输出，当 rw/rh 下溢时，编码后的 dw/dh 变为 -inf，经 (dw - means) / stds 归一化后输出包含 -inf 或 NaN，导致与 CPU golden 的精度比对失败。

修复方法 — 在 BoxDeltaCalc 中新增 FixLnResult + SoftLnPositive 兜底逻辑：

1. FixLnResult(origInput, npuLnResult) —— 后处理守卫函数，同时检查原始输入和 NPU Ln 结果：

   • origInput 为 NaN → 返回 NaN（符合 IEEE 754）
   • origInput == 0.0 → 返回 -inf（符合 log(0)）
   • origInput < 0.0 → 返回 NaN（符合 log(负数)）
   • npuLnResult 为 NaN → 返回 NaN（传播硬件错误）
   • npuLnResult == -inf && origInput > 0.0 → 转入 SoftLnPositive 软件兜底（核心修复点）
   • 其余情况 → 原样返回 npuLnResult（正常路径，零开销）

2. SoftLnPositive(x) —— 针对 -inf 兜底场景的软件 ln 实现，采用 atanh 泰勒级数：

   • 将 x 归一化为尾数 m ∈ [1, 2) 和指数 e（通过反复乘/除 2 实现）
   • 计算 z = (m - 1) / (m + 1)，再算 atanh(z) ≈ z * (1 + z²/3 + z⁴/5 + z⁶/7 + z⁸/9 + z¹⁰/11)
   • 返回 2 * atanh(z) + e * ln(2)，其中 ln(2) = 0.69314718

3. ComputeFp16Path 和 ComputeFp32Path 同步更新：dw/dh 计算改为先从 buffer 读取原始 rw/rh，经 FixLnResult 处理后再做 (lnRw - means) / stds 归一化，替换原先直接消费 buf2.GetValue(base+2) 的方式。

影响范围： 正常值域（rw ∈ [0.5, 2.0]）不受影响 —— FixLnResult 原样透传硬件 Ln 结果，行为零变化。该修复仅在硬件会产出 -inf 的退化输入场景下激活，使 NPU 输出与 CPU/GPU 行为对齐。

关联的Issue

https://gitcode.com/cann/ops-cv/issues/734

测试

• GEIR 静态测试（test_geir_bounding_box_encode）：FP32 (2,4) 单节点图编译 + NPU 执行 —— PASS
• GEIR 动态 Shape 测试（test_geir_bounding_box_encode_dynamic）：[-1,-1] 5 种 shape + [-2]（unknown rank）5 种 shape —— 10/10 PASS
• GEIR 负向拦截测试（test_geir_intercept）：14 例矩阵（合法/非法 dtype、shape、rank、means/stds 长度、stds=0）—— 13/14 PASS（1 例结构性不可拦截：dtype 不一致被内置 proto V1 InferShape 屏蔽 + FE 自动插 Cast）
• NPU Ln 行为验证：确认 FixLnResult 正确将 rw=1e-30 路由至 SoftLnPositive，产出 ≈ -69.07 与 CPU numpy.log(1e-30) 一致；正常 rw=1.07 原样透传硬件 Ln，误差 ≤ 3.3e-7

类型标签

• Bug修复
• 新特性
• 性能优化
• 文档更新
• 其他，请描述：