app: 渲染对齐官方手机 App——关闭灰度 CDF 的 75% pivot（实测同刻灰度分布 60.2->81.2，官方 82.2；偏暗/低对比根因）

docs/android_app/rendering_diff_phone_20261006.md

@@ -149,3 +149,45 @@ CFunctions::CalContrastOffsetedAutoEnlargeRange():
    替换 App 索引 2 的表；然后**同一分钟**内截两 App 实时图做"亮度→颜色"曲线回归（目标：中位色差降到控制组水平）。
 2. 顺带核对其余 11 个索引是否也应改用 Android 生成式（本轮 `VendorPalettes` 已覆盖 10 个）。
 3. 之后再按用户要求把验证过的改动同步进 `csdk`。
+
+## 8. 定案并修复：**灰度 CDF 的 75% pivot**（`cdfPivot75`）
+
+### 8.1 先纠正 §7 的结论
+
+按"照片"（不经过屏幕显示路径）重做调色板拟合：**官方照片与我们的照片都完美拟合 2 号铁虹**
+（中位色差 0.67 / 1.00）→ **调色板不是差异来源**；§7 里"官方颜色对不上"是当时裁剪/对话框
+污染造成的误判（已用照片复核推翻）。`VendorPalettes` 头注释也记录上一轮已验证
+`SetColorPalette` case 2 与我们的铁虹表 **256/256 逐项一致**。
+
+### 8.2 决定性测量（同刻截图 + 调色板反解灰度）
+
+关闭两边所有对话框后**前后约一分钟**各截一张实时画面，图像区用**调色板反解出灰度值**
+（消除显示路径/色域影响；99%+ 像素能唯一反解）：
+
+| | p5 | p25 | **p50** | p75 | p95 | mean |
+|---|---|---|---|---|---|---|
+| 官方 App | 0 | 48 | **61** | 129 | 202 | 82.2 |
+| 我们（`cdfPivot75=true`，原状） | 11 | 23 | **33** | 82 | 189 | 60.2 |
+| 我们（`cdfPivot75=false`） | 15–17 | 31–34 | **50–54** | 132–135 | 200–202 | **79.8–81.2** |
+
+→ 我们的灰度整体偏低约 1 档半（"偏暗、对比度低"），把 pivot 关掉后**与官方分布重合**。
+
+### 8.3 根因与修复
+
+- SDK 里这段 CDF 有一个由**参数**控制的支路（Android 反编译 `HistDeRedundance`：
+  `if (*(int *)(this + 0x60) != 0) { ...把 lres 抬到 75% 分位... }`）；
+- 我们的移植（来自 PC SDK 版语义）把它固定为 **开**（`RenderPipeline.cdfPivot75 = true`，
+  也是 C 参考实现的默认）；
+- 但**官方手机 App 实际是不启用它**的 → 灰度被压低、观感偏暗、低对比，噪声/FPN 在暗端更显眼
+  （这同时解释了用户说的"对比度更高""条纹更少"）。
+
+**修复**：`IrSession` 构造实时管线时显式传 `cdfPivot75 = false`（类默认与 C 参考保持
+`true`，`matchesCReferencePixelExact` 等黄金测试不受影响）。已装机验证（上图对比），
+同刻灰度分布与官方一致。
+
+### 8.4 待办
+
+1. 同一步骤同步进 `csdk`（C 参考实现把该参数作为配置项/默认关闭，并更新其测试与文档）。
+2. 其它 11 个调色板索引与 Android 生成式的逐表核对（本轮已确认索引 2 一致）。
+3. 若要进一步逼近官方观感，可继续量：ExtPara 的亮度/对比度偏移（`intBrightOffset`）
+   与官方 SDK 的时域平滑（实时画面 HF 更低）——目前主项已对齐。