Thor vs 其他
| 平台 | ISP | 特性 |
|---|---|---|
| RPi5 | 開源 libcamera | 看得見、手動 |
| Orange Pi | 感測器內建 | 陽春 |
| Orin Nano | NVIDIA ISP | 自動化、封閉 |
| Thor T5000 | Blackwell + Holoscan | 次世代、高階自動化 |
「ISP 架構差異」其實是「調校邏輯住在哪一層」的差異。這決定你能動什麼、誰在管。
| 平台 | 調校邏輯位置 | 你能控制的 | 誰決定自動化 |
|---|---|---|---|
| RPi5 | libcamera(user space) | 所有參數(開源) | libcamera IPA |
| Orange Pi | 感測器內建 ISP | 感測器 register | 感測器韌體 |
| Orin Nano | NVIDIA ISP(libnvivp) | Argus 層 | NVIDIA 自動化 |
| Thor T5000 | Blackwell ISP + Holoscan | Argus / Holoscan 層 | NVIDIA 自動化 |
RPi5 (libcamera): libcamera-still --shutter 20000 --gain 2 Orange Pi: v4l2-ctl -d /dev/v4l-subdev0 -c exposure=20000 Orin: argus_camera ... SensorMode exp_time=20000 Thor (HSB): argus_camera / Holoscan SensorMode 同上
0x3500–0x3502。只要理解感測器 register(unit-03),換平台只換語法——這是整套課程的設計主軸。1. 參數真的有套上嗎?(回讀驗證) ├─ 否 → 找對平台的控制語法 └─ 是 ─┐ 2. ISP 順序/強度相同? ├─ 否 → 各平台 ISP 區塊順序不同(如 NR 在 CCM 前/後) └─ 是 ─┐ 3. 同一顆感測器 + 同一模式? └─ 否 → 鎖定 sensor mode(unit-08)
跨平台比較不能只看 API 名稱。把相機系統拆成控制面(I2C、曝光、模式、電源)與資料面(CSI/HSB、buffer、ISP、輸出),再標出調校檔實際生效的位置。相同的 exposure 名稱,可能只改 sensor register,也可能由平台 AE 在下一幀覆寫。
| 問題 | 先看哪一層 | 跨平台差異 |
|---|---|---|
| 讀不到 ID | 控制面/I2C | bus、bridge、reset 不同 |
| 有 RAW 無好色彩 | 資料面/ISP | 可見 tuning 參數不同 |
| 延遲或掉幀 | buffer/排程 | 零拷貝與 queue 深度不同 |
RPi5:取 RAW → 關 IPA/AWB → 看 Bayer 與黑位 → 再查 libcamera tuning Orange Pi:確認 sensor 內建 ISP 是否已開 → 讀出未處理格式 Orin:用 Argus 固定 AWB → 檢查 NVIDIA ISP 統計與 CCM Thor:分開驗證 CSI/HSB source → 固定 Holoscan source format → 查 ISP 共同判斷: 1. RAW 也偏綠?→ Bayer、黑位、sensor gains 2. RAW 正常、YUV 偏綠?→ AWB/CCM/色彩矩陣 3. 只有動態時偏綠?→ AE/AWB 收斂與 buffer 對應
同一個症狀的根因不一定相同。可攜移的是量測順序與判斷邏輯,不是 tuning 檔或命令列參數本身。
1. 感測器 ID、鏡頭、mode、fps 都相同? ├─ 否 → 先建立同條件測試 └─ 是 ─┐ 2. RAW histogram / Bayer / 黑位相同? ├─ 否 → 修 driver、格式或 sensor init └─ 是 ─┐ 3. 同一曝光與 AWB 狀態下仍不同? ├─ 是 → 比對 ISP block、tuning、gamma └─ 否 → 可能是 AE/AWB closed-loop 收斂差異 4. 效能不同?→ 分開量 capture、ISP、GPU、輸出 queue 延遲
場景:團隊在 RPi5 上已建立完整的 OV9281 調校參數(AWB gains 表、LSC 網格、NR 強度),要移植到 Thor T5000。RPi5 用 libcamera(開源 ISP),Thor 用 NVIDIA ISP。
# Phase 1:感測器層(可移植) # OV9281 的 register 設定(曝光、增益、init table)→ 直接搬 # 驗證:讀回 register 確認值一致 # Phase 2:ISP 層(不可直接搬,需重校) # RPi5 的 libcamera tuning JSON → 語義不同 → 不能直接套 # 重校順序:黑位 → LSC → AWB/CCM → NR → Sharpen # Phase 3:驗證對照 # 同一灰卡、同一光源、同一 sensor mode # 比較 RPi5 與 Thor 的 RAW histogram、YUV histogram、SNR # 差異量 > 10% → 重校;< 10% → 可接受 # 設計決策: # 1. 感測器 register 100% 可移植(OV 感測器不因平台而異) # 2. ISP 參數 0% 可移植(不同 ISP 引擎語義不同) # 3. 可攜的是「校正流程與量測指標」,不是具體參數值
除了調校能力,四平台的 ISP latency(從感測器輸出到 ISP 輸出的延遲)也不同。RPi5 的 libcamera ISP 在 CPU 上運行,latency ~15 ms;Orin/Thor 的 NVIDIA ISP 在硬體引擎上運行,latency ~2–4 ms。但這只是 ISP 本身的延遲——完整管線還包括 DMA、buffer queue 與後處理。
| 平台 | ISP latency(估算) | 完整管線 latency | 瓶頸 |
|---|---|---|---|
| RPi5 | ~15 ms | ~25–35 ms | CPU + ISP 共用運算資源 |
| Orange Pi | ~5 ms(內建 ISP) | ~15–20 ms | ISP 功能受限 |
| Orin Nano | ~2–3 ms | ~8–12 ms | DMA + buffer queue |
| Thor T5000 | ~2–4 ms | ~5–8 ms | HSB 網路延遲(若有) |
| 症狀 | 可能原因 | 解決方案 |
|---|---|---|
| RPi5 調校搬到 Thor 後整體偏暗 | AE 目標亮度語義不同(RPi5 用 histogram percentile,Thor 用平均值) | 重新設定 Thor 的 AE target brightness;用灰卡量測對照 |
| RPi5 的 LSC 網格搬到 Thor 後暗角未改善 | LSC 網格格式與 ISP 插值方式不同 | 用 Thor 專用工具重新拍灰卡校正 LSC |
| 同感測器在 Orin 與 Thor 上 FPS 不同 | sensor mode 的 frame length 設定差異 | 確認兩平台的 DTB 中 frame length 與 line length 一致 |
| RPi5 的 tuning JSON 直接套入 Thor 無效 | libcamera JSON 與 NVIDIA tuning 格式語義不同 | 不套用 JSON;用 Thor 專用工具重新建立 tuning 資料 |
| Orange Pi 的感測器內建 ISP 已做 NR,Thor 再做一次 NR 導致過度模糊 | 雙重 NR 處理 | 確認感測器 ISP 狀態(開/關);若已開 NR,Thor 端 NR 強度降低 |
場景:一顆感測器在 RPi5 已調校完成,現在要遷移到 Thor 量產。專案目標:在不重建演算法的前提下,用相同 SOP 重產 Thor 專用參數,並量化兩平台的差距。
M1 可移植盤點 ├─ 感測器 init 表(可搬) ├─ 曝光/AWB 換算表(可搬) ├─ libcamera JSON tuning(不可搬,需重校) └─ 通過:列出「可搬/重校/不可對映」三類清單 M2 同條件基準 ├─ 同感測器、同鏡頭、同光源箱、同 sensor mode ├─ 各平台取 RAW + YUV └─ 通過:RAW histogram 接近(輸入相同) M3 Thor 重校 ├─ 黑位 → LSC → AWB/CCM → NR/Sharpen(unit-14 SOP) └─ 通過:各階段門檻(ΔE、四角亮度差、SNR) M4 量化對照 ├─ 比較兩平台:SNR、ΔE、latency、掉幀 └─ 通過:產出對照表 + 差距原因分析 M5 回歸 └─ 通過:室內/日光/混合光源回歸全過 M6 交付 └─ 通過:Thor 調校包 + 移植 SOP 進 repo
Step 1 定義條件 同感測器/鏡頭/光源/模式/曝光/輸出格式 Step 2 各平台取樣 RAW、YUV、fps、延遲、CPU/GPU 使用率 Step 3 比對輸入 RAW histogram、Bayer、黑位是否一致 # 不一致 → 先修輸入,別比 ISP Step 4 比對輸出 SNR、ΔE、MTF、latency Step 5 歸因 差異分類:sensor / ISP / 輸出 Step 6 記錄 條件表 + 資料 + 結論進 repo 判讀指標: 輸入一致 + 輸出不同 → 平台 ISP 差異 輸入就不一致 → 無效比較
| 面向 | Thor T5000 | RPi5 | Orange Pi | Orin Nano |
|---|---|---|---|---|
| 調校邏輯位置 | Blackwell ISP + Holoscan | libcamera IPA(user space) | 感測器韌體 | NVIDIA ISP(libnvivp) |
| 可視參數 | ~50 + 自動化 | ~200(開源) | ~30(sensor only) | ~50 + 自動化 |
| ISP latency | ~2–4 ms | ~15 ms | ~5 ms | ~2–3 ms |
| 調校交付格式 | NVIDIA 工具 + Holoscan 設定 | JSON tuning 檔 | register init 表 | NVIDIA 工具 |
| 自動化程度 | 很高 | 中 | 低 | 高 |
本單元涉及的關鍵 register,以及「讀→改→寫→驗證」的完整位元級操作序列:
| Register | 位址 | 功能 | Bit Field 說明 |
|---|---|---|---|
ISP_POWER_CTRL | 0x00140004 | ISP 電源控制 | bit[0]=ISP_en, bit[1]=clock gating, bit[4]=power domain switch |
TEGRA_VIDEO_CTRL | 0x0c800000 | Video Engine 控制 | bit[0]=enable, bit[3:2]=input source |
# Step 1: 讀取目前值 $ devmem2 0x00140004 w # 記錄 current_value # Step 2: 計算新值(設定 bit[0]=1) $ new_value=$((current_value | 0x0001)) # Step 3: 寫入 $ devmem2 0x00140004 w $new_value # Step 4: 驗證 $ devmem2 0x00140004 w # 確認 bit[0] = 1,其餘 bit 不變 # Step 5: 進階 — bitmask 操作 $ read_val=$(devmem2 0x00140004 w | grep "Read" | awk '{print $NF}') $ mask=0x0001 $ expected=0x0001 $ [ $(($read_val & $mask)) -eq $expected ] && echo "PASS" || echo "FAIL: bit[0] not set"
1. 輸出 frame rate 低於預期? ├─ ISP clock 太低 → 調升 ISP clock rate └─ ISP pipeline 太長 → 關閉不需要的 block 2. GPU 顯示卡頓但 ISP 處理正常? ├─ GPU pipeline 問題 → 檢查 CUDA stream 同步 └─ Display queue 滿 → 增加 display buffer
1. 第二顆相機無法啟用? ├─ ISP 硬體通道已滿 → 確認 ISP 有幾個 VPP(Thor: 4, Orin: 2) └─ DDR 帶寬不足 → 降低兩顆相機的 resolution
跨平台 ISP 架構對比驗證 SOP:
| 步驟 | 動作 | 指令/方法 | 預期輸出 |
|---|---|---|---|
| Step 1 | 確認 ISP 有無 | `lspci | grep -i isp` 或 `/proc/device-tree/` | Thor/Orin: 有, RPi/OPi: 無獨立 ISP |
| Step 2 | ISP clock 測量 | `cat /sys/kernel/debug/bpmp/debug/clk/isp/rate` | Thor: 600MHz, Orin: 408MHz |
| Step 3 | 同時跑 2 路 camera | 各平台接 2 顆 camera 並同時 stream | Thor: OK, Orin: OK, RPi: 有限 |
| Step 4 | ISP tuning 能力 | 比較各平台 tuning 工具與參數數量 | Thor > Orin > RPi > OPi |
| Step 5 | 輸出品質比較 | 用同一感測器在各平台拍同一場景 | 色彩/動態範圍對比 |
| 面向 | Thor T5000 | RPi5 | Orange Pi | Orin Nano |
|---|---|---|---|---|
| ISP 硬體 | Blackwell ISP(2 GOPS) | 博通 ISP(有限) | 無獨立 ISP | NVIDIA ISP(1.5 GOPS) |
| ISP pipeline 深度 | BLC→BPC→LSC→LDC→Demosaic→CCM→Gamma→NR→Sharpen | BLC→Demosaic→CCM→Gamma | 軟體 only | BLC→BPC→LSC→Demosaic→CCM→Gamma→NR→Sharpen |
| VPP 通道數 | 4 | 2(共享) | 0 | 2 |
| ISP clock 範圍 | 400–800 MHz | 200–400 MHz | N/A | 200–600 MHz |
| 硬體 LDC | ✅ | ❌ | ❌ | ✅ |
| ISP 功耗 | ~1.5W | ~0.5W | N/A | ~1W |
針對「各平台 ISP 架構差異」主題的完整 bring-up 步驟清單: