單元 7 · ISP 管線深入

Blackwell ISP

Thor 的 ISP

RAW黑位LSCdemosaicNRCCMgamma輸出

Thor 沿用 NVIDIA ISP 架構(與 Orin 的 libnvivp 同族),提供統計給 AE/AWB。

調適心態:與 Orin 相同——NVIDIA 平台強調自動調校。你的工作是「感測器 init 正確 + 場景合理」,讓 AE/AWB 自動收斂。

⚠️ Thor ISP 完整公開參數集以官方文件為準。

7.2 深入原理:每個 ISP 區塊做什麼

NVIDIA ISP(libnvivp 同族)的管線區塊各自對應一種「影像缺陷」。除錯時反過來用:看到什麼症狀 → 哪個區塊負責

區塊作用症狀若停用
黑位 OB扣除感測器暗電流偏移整體偏灰/偏綠
LSC補償鏡頭陰影四角偏暗偏色(unit-12)
DemosaicBayer → RGB 重建彩色假影/雜訊(aliasing)
NR空間/時間降噪低光雜訊明顯(unit-13)
CCM色彩矩陣校正色偏不自然(unit-11)
Gamma/TM亮度對數曲線/色調映射高光爆、暗部死黑
Statistics算 AE/AWB 需要的統計值AE/AWB 收斂不正常
調適心態:NVIDIA 的自動調校是「以統計回饋為閉迴路」。你的任務不是手動微調每一塊,而是確保:① 感測器 init 正確(前面單元)② 場景合理 → 讓 AE/AWB 自動收斂到統計目標。

7.3 Worked Example:一個像素通過管線

追蹤一個 RAW code(灰卡 500)
RAW code = 500(10-bit)
OB 扣除:500 − 黑位(64) = 436
LSC:中央增益 1.0 → 436
Demosaic:鄰近 R/G/B 內插 → R=430, G=436, B=432
NR:小幅平滑 → 不變(訊號不強)
CCM:3×3 矩陣轉換 → R'=0.9R−0.1G+... → 校正後色
Gamma:code 經過非線性 → 128(8-bit 輸出)
輸出:127~129 的灰
為什麼這樣追:當輸出「偏綠」,你就能沿管線往前猜:黑位沒設對?CCM 沒套?還是 AWB gains 錯?把「症狀」映射到「區塊」是 ISP 調校的核心技能。

7.4 疑難排解決策樹:輸出影像異常

「畫面怪怪的」決策樹
1. 整體偏色?
   ├─ AWB/CCM 關閉?→ 手動設灰卡白平衡
   └─ 仍偏 → 黑位 OB 檢查
2. 四角暗?
   └─ LSC(unit-12)
3. 低光雜訊多?
   └─ NR 與增益(unit-13)
4. 高光爆、暗部死黑?
   └─ Gamma/TM 與曝光(unit-10/14)
5. 動態畫面有假影?
   └─ 幀率/曝光(unit-11 幀率單元、unit-14)

7.5 常見錯誤與陷阱

陷阱 1:黑位沒設就調 AWB——OB 錯會讓所有統計值偏移,AE/AWB 跟著收斂到錯誤目標。校正順序:先黑位、再 LSC、才談色彩(unit-14 工作流)。
陷阱 2:把 ISP 當「全都自動」——自動化只在「感測器資料正確」的前提下成立。RAW 端就錯(黑位、Bayer、飽和),自動化只會放大錯誤。
陷阱 3:gamma 後再比較 RAW 亮度——gamma 是非線性,輸出亮度與 RAW code 不是線性對應。比較畫質要在同一階段(RAW vs RAW,或 sRGB vs sRGB)。

7.6 深入:統計回饋與 NVIDIA 自動調校閉迴路

NVIDIA ISP 的 AE/AWB 是「閉迴路」:ISP 計算每幀統計(亮度分布、色平衡),演算法依統計調整參數,下一幀再重算——如此反覆收斂。

ISP 算統計AE/AWB 演算法改參數下幀重算收斂
統計餵給誰異常時症狀
亮度直方圖AE過暗/過亮
色平衡統計AWB色偏
區域統計(格子)AE/AWB局部曝光錯
調校哲學:你「讓統計目標合理」,NVIDIA 幫你「追目標」。比如想要偏亮 → 提高 AE 目標亮度;想要暖色 → 設 AWB 目標色溫。不是手動逐幀調。

7.7 Worked Example:AE 收斂觀察

從過暗場景看到收斂
1. 開機拍暗場景:畫面很暗
2. 幾幀後 AE 逐步調高曝光/增益 → 畫面變亮
3. 檢查收斂:亮度不再大幅跳動 = 已收斂
4. 若一直跳動或過暗:
   → 統計目標錯 / 上限卡住 / 感測器 RAW 有問題
   (回到 unit-10 的「上限卡住」診斷)

7.8 練習

  1. 把 7.3 的像素追蹤在自己的 RAW 上跑一遍(取灰卡 RAW)。
  2. 列出你的平台 ISP 的區塊順序,標出每塊的輸入/輸出。
  3. 設計一個「關掉某一區塊」的實驗,驗證你對管線的理解。
看完這單元你應該能說出:
  • Thor ISP 沿 NVIDIA 架構。
  • ISP 區塊與統計回饋。
  • 「自動調校」心態。
  • 與 Orin 調校共通性。

延伸閱讀

7.9 進階真實情境 Worked Example:多感測器 ISP 管線的統計衝突

場景:Thor T5000 同時處理 3 顆感測器(前視 8MP + 左右側視 2MP),每顆的 ISP 統計獨立計算 AE/AWB。左側視感測器朝向逆光窗戶,AE 統計被強光主導,導致整體曝光策略錯誤。

多感測器 AE 統計隔離
# 問題:3 顆感測器共享同一 ISP 統計引擎
# 左側視逆光 → AE 計算出「場景很亮」→ 降低曝光
# → 前視感測器跟著變暗 → 前方物件欠曝

# 解決方案:per-sensor AE ROI 設定
# 1. 每顆感測器的 AE 統計範圍獨立設定(不跨 sensor)
# 2. 前視感測器的 AE 目標獨立於側視
# 3. 或使用 Holoscan 的統計隔離 operator,每路 ISP 管線各自有獨立 AE 閉迴路

# 驗證:
# 固定前視曝光為手動,觀察側視曝光自動調整是否影響前視
# 若不受影響 → 統計隔離成功
設計決策:多感測器系統的 ISP 統計必須隔離。NVIDIA ISP 的預設行為是「每顆感測器獨立 AE/AWB」,但若共享同一 ISP 硬體 instance,統計可能互相干擾。解法是確認每路 ISP pipeline 有獨立的統計引擎,或在 Holoscan 層做統計隔離。

7.10 深入原理擴充:NVIDIA ISP 的 multi-pass pipeline 與 Blackwell 架構

Thor 的 Blackwell ISP 支援 multi-pass processing:同一幀資料可以通過 ISP 管線多次,每次套用不同的參數集。例如第一 pass 做基礎色彩校正(CCM + AWB),第二 pass 做局部 tone mapping。這在 HDR 場景中特別有用——第一 pass 計算動態範圍,第二 pass 針對高光/暗部分別映射。

RAWPass 1:OB + LSC + Demosaic + CCMPass 2:Local TM + NR + Sharpen輸出
容易忽略的邊界案例:multi-pass 模式下,第一 pass 輸出的統計值可能與單 pass 不同(因為某些 block 被延到第二 pass)。若 AE/AWB 演算法以第一 pass 的統計為準但實際色彩在第二 pass 才校正,收斂可能偏移。必須在 tuning 時確認 AE/AWB 的統計取樣點位於管線的哪一個 pass。

7.11 診斷式疑難排解表

症狀可能原因解決方案
輸出影像整體偏綠但 RAW 四通道正常CCM 矩陣未套用或 CCM 色溫分段切換錯誤確認 CCM 輸入色溫是否與實際光源匹配;用手動 AWB 固定色溫後重試
AE 收斂後畫面仍過暗AE 目標亮度設定過低 / 統計 ROI 遮蔽主體調整 AE target brightness;確認統計 ROI 覆蓋主要場景區域
低光場景中 NR 開啟後畫面模糊空間 NR 強度過高,把細節當雜訊抹除降低 spatial NR strength;確認 sharpen 在 NR 之後才啟用
multi-pass ISP 的第二 pass 產生殘影時間性 NR 在 multi-pass 間的幀緩衝未清除確認 temporal NR 的幀緩衝在 multi-pass 切換時正確重置
ISP 輸出的 histogram 與 RAW histogram 不一致gamma/tone mapping 在兩者之間改變了亮度分布比較時必須在同一階段(RAW vs RAW,或 sRGB vs sRGB)

7.12 進階挑戰題

  1. 設計一個 multi-pass ISP 的調校策略:如何在 Pass 1(基礎色彩)與 Pass 2(tone mapping + NR)之間分配調校參數?若 Pass 1 的 CCM 錯誤,Pass 2 的 NR 強度是否需要跟著調整?
  2. 在多感測器(3 顆)系統中,畫出每路 ISP 管線的統計流向圖。標出哪些統計值共享、哪些獨立。分析「左側逆光」如何影響前視 AE,並提出一個 Holoscan 層的統計隔離方案。
  3. 分析 NVIDIA ISP 的 OB(Optical Black)扣除在不同溫度下的穩定性。設計一個實驗:在 25°C 與 65°C 下量測 OB 飄移量,並說明它對後續 LSC/AWB 校正的連鎖影響。

7.13 專案級端到端 Worked Example:ISP 管線驗證專案 — 逐區塊停用與啟用

場景:你接手一個 Thor 專案,畫面「怪怪的」。專案目標:用「逐區塊停用實驗」建立對 ISP 管線的實證理解,並定位畫面異常來自哪個區塊。

里程碑規劃
M1 建立基準
   ├─ 固定場景(灰卡 + 光源箱)
   ├─ 固定曝光、關 AWB
   └─ 通過:取得 RAW 與 YUV 基準檔

M2 逐區塊停用
   ├─ 依序停用:OB / LSC / Demosaic / NR / CCM / Gamma
   ├─ 每停一個存一張 YUV
   └─ 通過:每張對應「症狀 vs 區塊」觀察記錄

M3 症狀→區塊對照
   ├─ 整理「停用某區塊 → 出現什麼症狀」
   └─ 通過:產出自己平台的區塊-症狀表

M4 統計回饋檢查
   ├─ 檢查 AE/AWB 統計是否隨區塊停用變化
   └─ 通過:理解統計取樣點在哪個區塊之後

M5 異常定位
   ├─ 套回原參數,重新診斷初始「怪畫面」
   └─ 通過:定位到具體區塊並提出修正

M6 產出調校地圖
   └─ 通過:repo 內有「區塊-症狀-調校參數」對照文件
專案要點:ISP 調校最怕「瞎試」。逐區塊停用實驗把「症狀」綁定到「區塊」,之後任何畫面問題都能沿著對照表快速定位。

7.14 量測 / 驗證 SOP:ISP 管線健康檢查

ISP SOP(Step 1–6)
Step 1 固定條件
   固定曝光、固定 AWB、固定光源、灰卡/色卡
Step 2 取基準
   RAW + YUV 各一組
Step 3 統計檢查
   看亮度直方圖、色平衡統計是否落在合理範圍
Step 4 區塊停用掃描
   依序停用區塊,各取一幀,記錄視覺變化
Step 5 量化
   比較每幀的 histogram(均亮、峰位、通道比例)
Step 6 記錄
   區塊-症狀-量化表 進 repo

判讀指標:
  停 OB    → 偏灰/偏綠     = OB 正常運作
  停 LSC   → 角落變暗     = LSC 正常運作
  停 CCM   → 色彩偏感測器原生 = CCM 正常運作
  停 Gamma → 暗部變灰     = Gamma 正常運作

7.15 平台間對照:ISP 管線與統計

面向Thor T5000RPi5Orange PiOrin Nano
ISP 位置Blackwell 硬體引擎libcamera(CPU)感測器內建NVIDIA 硬體引擎
管線順序OB→LSC→Demosaic→NR→CCM→Gammalibcamera(可看原始碼)感測器固定同 NVIDIA 族
統計回饋✅ AE/AWB 統計閉迴路✅ IPA⚠️ 感測器韌體✅ 同 Thor
區塊可調性受限(自動化為主)全可調(開源)幾乎不可調受限
Multi-pass✅ 支援⚠️ 部分
選擇思考:「區塊-症狀」對照邏輯四平台通用,但「你能改哪個區塊」差異巨大——RPi5 全可調、Thor 靠自動化。先理解管線,再決定平台。

7.16 互動式檢核清單

7.18 Register 位元級完整工作流

本單元涉及的關鍵 register,以及「讀→改→寫→驗證」的完整位元級操作序列:

Register位址功能Bit Field 說明
ISP_BLC_OFFSET0x00140000Black Level Correction 偏移bit[15:0] = BLC offset per channel (R/Gr/Gb/B)
ISP_BPC_CTRL0x00140040Bad Pixel Correction 控制bit[0]=enable, bit[1]=method (median/interpolation)
讀→改→寫→驗證 完整序列(以 ISP_BLC_OFFSET 為例)
# Step 1: 讀取目前值
$ devmem2 0x00140000 w
# 記錄 current_value

# Step 2: 計算新值(設定 bit[0]=1)
$ new_value=$((current_value | 0x0001))

# Step 3: 寫入
$ devmem2 0x00140000 w $new_value

# Step 4: 驗證
$ devmem2 0x00140000 w
# 確認 bit[0] = 1,其餘 bit 不變

# Step 5: 進階 — bitmask 操作
$ read_val=$(devmem2 0x00140000 w | grep "Read" | awk '{print $NF}')
$ mask=0x0001
$ expected=0x0001
$ [ $(($read_val & $mask)) -eq $expected ] && echo "PASS" || echo "FAIL: bit[0] not set"

7.19 多層疑難排解決策樹

決策樹 1:ISP 輸出異常色彩
1. 色彩偏移或反色?
   ├─ CCM matrix 未載入 → 確認 ISP tuning 文件路徑
   └─ Gamma curve 設定錯 → 進 visualizer 調 LUT
2. 暗角或亮角?
   ├─ LSC table 不對 → 重拍白卡生成新 table
   └─ 鏡頭與 LSC table 不匹配 → 確認 lens 型號
決策樹 2:ISP 處理延遲過高
1. pipeline latency > 20ms?
   ├─ ISP clock 頻率太低 → 檢查 `cat /sys/kernel/debug/bpmp/debug/clk/isp/rate`
   └─ ISP block 過多 → 關閉不需要的功能(HDR、Nr、LSC 可暫關測試)

7.20 量測驗證完整 SOP

ISP 管線完整驗證 SOP:

步驟動作指令/方法預期輸出
Step 1raw 輸入確認先確保 sensor raw streaming 正常raw 檔非零
Step 2BLC 驗證拍暗場,量測四通道 black levelR/Gr/Gb/B 接近(±2 DN)
Step 3BPC 驗證拍白卡,放大檢視 dead pixel無明顯亮/暗點
Step 4LSC 驗證拍白板四角,量測亮度均勻度四角差 < 10%
Step 5Demosaic 驗證拍 ISO 12233 chart無 moiré / false color
Step 6CCM + AWB 驗證拍白卡 + X-Rite ColorCheckerΔE < 3
Step 7Gamma 驗證拍 21 級灰階 charttone curve 符合預期
Step 8NR + 銳化暗場 + 細節 chart雜訊抑制但不糊

7.21 四平台終極對照

面向Thor T5000RPi5Orange PiOrin Nano
ISP 處理能力Blackwell ISP: 2 GOPS博通 BCM2835 ISP無獨立 ISP(CPU soft)NVIDIA ISP: 1.5 GOPS
BLC 精度12-bit per channel10-bitN/A(raw only)12-bit
BPC 方法Median + ML inferenceFixed patternN/AMedian + Interpolation
LSC table 格式5×5 grid × 4 channels17×13 gridN/A16×12 grid
CCM 矩陣大小3×3 + offset3×3N/A3×3 + offset
ISP tuning 工具NVIDIA ISP Visualizerraspistill --settingsN/ANVIDIA ISP Visualizer

7.22 完整 Bring-up 小 Checklist

針對「ISP 管線深入」主題的完整 bring-up 步驟清單: