單元 2 · 影像感測器基礎

Bayer、global shutter、OV9281

感測器把光變成 RAW

光子像素增益ADCRAW

Bayer CFA

OV9281 / OV5640 都是標準 Bayer 排列,由 ISP demosaic 重建全彩。

Global shutter(OV9281)

型態特性OV9281
Rolling逐列曝光
Global全像素同時曝光
為什麼機器人愛用 global shutter:移動中取像不扭曲,適合 SLAM、抓取等物理 AI 任務。

OV9281 完整規格(公開)

項目規格
解析度1 MP(1280×800)
像素3.0 µm
快門Global shutter
輸出MIPI CSI-2
I2C 位址0x36
ID register0x300A=0x92 / 0x300B=0x81

2.4 深入原理:光 → 電荷 → 數位的位元層級

感測器像素是一個光電二極體 + 浮動節點。光子擊中半導體產生電子(QE,量子效率),電子累積在電容(full well),再經 讀出放大(conversion gain)與 ADC 轉成數位碼。關鍵位元級概念:

光子電子(QE)電容飽和(full well)電壓(gain)ADC(bit depth)RAW code
名詞意義對影像的影響
QE光子 → 電子轉換率低光靈敏度
Full well像素能存的最大電子數飽和(過曝)門檻
Conversion gain電子 → 電壓放大讀出雜訊/位元深
Bit depthADC 解析度(如 10-bit)階調與條帶
調適語言:「過曝」在 register 層 = 像素電荷超過 full well,而「暗部斷階」= bit depth 不足或 gain 太小。說得出位元層原因,才能判斷是調 gain、調曝光還是換感測器。

2.5 Worked Example:一個像素從光子到 code

估算像素輸出 code(OV9281:10-bit ADC,full well ≈ 10000 e⁻)
假設該像素接收 4000 光子,QE=60%:
電子數   = 4000 × 0.6 = 2400 e⁻
飽和比例 = 2400 / 10000 = 24%
輸出 code = 24% × 1023(10-bit 上限)≈ 245

假設曝光時間加倍(光子→8000):
電子數   = 4800 e⁻ → code ≈ 491(線性)
若超過 10000 e⁻ → code 卡在 1023 = 過曝
工程意義:RAW code 與光子數是線性關係(未過曝時)。這代表 AE 演算法能直接用 RAW 統計回推「還差幾倍曝光」——也是 NVIDIA AE 能快速收斂的原因。

2.6 Bayer CFA 排列與 binning 陷阱

OV9281 是 1MP 感測器,最常以 2×2(RGGB)輸出。問題常出在裁切/讀出區域:若讀出視窗的起始像素錯位,Bayer order 就會變成 GRBG 等變體,顏色全錯。

判別 Bayer order(拍一張純白)
1. 拍白色卡片,取 RAW(unit-08)
2. 把 2×2 的四個位置各取平均
3. 兩個綠色通道平均應接近(Gr≈Gb)
4. 若 Gr≠Gb → 不是 RGGB 就是讀出視窗錯位
陷阱:Bayer order 跟「幾顆感測器共用同一條 CSI」無關,它只由感測器讀出順序 + 裁切位置決定。改 mode 後務必重驗。

2.7 Global shutter 位元層差異(與帶狀光源)

Global shutter 讓所有像素「同時開始、同時結束」曝光;相較 rolling 逐列曝光。這讓 global 天生對 LED 調光、閃光燈免疫——因為取樣窗是整幀同步。

現象RollingGlobal
LED 閃爍(banding)易產生水平亮暗帶整幀明暗、無帶狀
快速移動物果凍效應(傾斜)不扭曲
像素內存電荷不需需儲存節點(影響 QE/面積)
選型智慧:物理 AI 機器人(SLAM、抓取)要 global;一般影像監控、相機才考慮 rolling 的價格與感光面積優勢。

2.8 常見錯誤與陷阱

陷阱 1:把 RAW code 當成亮度——code 是線性的電子計數,而「看起來亮」要經 gamma。直接在 RAW 上比明暗會誤判。
陷阱 2:忽略 full well 只調數位增益——數位增益放大飽和前的碼,但飽和邊界不變;曝光超過 full well 就 clip。
陷阱 3:Bayer 與「黑白感測器」混淆——OV9281 也有 monochrome 版本(無 CFA),RAW 每像素就是灰階,不需要 demosaic。確認你手上是 color 版。

2.9 練習

  1. 用 full well 與 QE 估算某像素 12-bit ADC 下的飽和 code。
  2. 解釋為何 global shutter 對帶狀光源免疫。
  3. 設計一個 3 分鐘實驗,驗證你感測器的 Bayer order。
看完這單元你應該能說出:
  • 感測器光→RAW 流程。
  • Bayer 排列。
  • Global shutter 對物理 AI 意義。
  • OV9281 規格與 ID register。

延伸閱讀

2.10 進階真實情境 Worked Example:高溫 industrial vision 的 full well 瓶頸

場景:Thor T5000 搭載在鋼鐵廠 24 小時連續運作的瑕疵偵測站。感測器為 OV9281 global shutter,環境溫度 55°C,感測器表面溫度可達 70°C。目標:穩定 SNR ≥ 30 dB。

高溫 full well 衰減分析
室溫(25°C)full well = 10000 e⁻,dark current = 10 e⁻/s
高溫(70°C)dark current 乘以 ~10 倍 → 100 e⁻/s
曝光 8.3 ms(120 fps)→ dark current 貢獻 = 0.8 e⁻(可忽略)
但 70°C 時 full well 衰減至 ~8500 e⁻(約 85%)

QE = 60%,平均像素接收 5000 光子:
  電子數 = 5000 × 0.6 = 3000 e⁻
  飽和比例 = 3000 / 8500 = 35.3%(比室溫 30% 稍高)
  SNR = 20·log10(3000 / √3000) ≈ 34.8 dB ✓

# 設計決策:
# 1. 高溫讓 full well 下降 → 飽和門檻提前 → 必須降低曝光避免 clip
# 2. dark current 增加但在短曝光下可忽略 → 主要瓶頸是 full well 不是 dark current
# 3. 加散熱片把感測器降回 55°C → full well 恢復至 ~9200 e⁻ → SNR 提升 1.5 dB
設計決策:高溫 industrial 環境的首要敵人不是 dark current 而是 full well 衰減。解決方案是散熱而非提高增益——增益只放大雜訊,散熱才增加真正的動態範圍。

2.11 深入原理擴充:OV9281 的 dual-gain 架構與 HDR 模式

OV9281 支援 dual-gain readout:同一幀中以兩種增益分別讀出,再由後端合成高動態範圍。低增益通道保留高光細節、高增益通道保留暗部。這在 global shutter 感測器中是珍貴的能力,因為 rolling shutter HDR 通常需要多次曝光(運動場景不適用)。

容易忽略的邊界案例:dual-gain HDR 模式下,每幀有效像素數減半(兩通道交錯排列)。若後端 ISP 不知道 sensor 處於 dual-gain 模式,demosaic 會把交錯排列當成正常 Bayer → 產生彩色摩爾紋。必須在 DTB 與 ISP 設定中同步標記 sensor mode 為 dual-gain。

2.12 診斷式疑難排解表

症狀可能原因解決方案
暗部有明顯紫色/綠色斑點bit depth 不足導致暗部量化斷階切換至更高 bit depth sensor mode(10-bit → 12-bit);或提高 analog gain 使暗部落入有效範圍
白卡 RAW 四通道比例正常但輸出偏色Bayer order 正確但 CCM 矩陣未套用確認 ISP 管線中 CCM 區塊是否啟用(unit-07);用手動 AWB + 灰卡驗證感測器本身色彩
高溫環境下偶發過曝full well 隨溫度下降,原本安全的曝光量變成飽和加入溫度感測回饋,在 AE 中設定溫度補償表;或限制最大曝光為 high-temp 值
Rolling shutter 感測器拍移動物體有果凍效應逐列曝光時間差造成幾何扭曲改用 global shutter 感測器(如 OV9281);或縮短曝光時間、提高補光
dual-gain HDR 輸出有規律彩紋ISP 未設定 dual-gain 模式,Bayer 解析錯位在 DTB 標記 sensor mode 為 dual-gain;確認 ISP demosaic 支援交錯 Bayer

2.13 進階挑戰題

  1. 設計一個實驗:在 25°C 和 65°C 兩個溫度下,量測 OV9281 的 full well、dark current 與 read noise。畫出三者隨溫度變化的曲線,並找出你的感測器「不可接受 SNR」的溫度門檻。
  2. 若你的專案需要在 30 fps 下同時使用 dual-gain HDR 與 global shutter,分析 ISP 管線中的 demosaic 區塊需要哪些特殊處理,並提出一個避免彩紋的 ISP 配置方案。
  3. 以 OV9281 為例,說明如何從 RAW 檔的 histogram 中區分「shot noise 主導」與「read noise 主導」的區域,並設計一個自動判定腳本。

2.14 專案級端到端 Worked Example:感測器規格驗證專案 — 從 datasheet 到實測

場景:你拿到一顆規格不明的感測器,要驗證 datasheet 聲稱的 full well、QE、global shutter 與 Bayer order。這個專案建立「感測器驗收」的可重複流程。

規格驗證里程碑
Phase 1  ID 與基礎(unit-03)
   ├─ 讀 ID register,確認型號
   └─ 通過:ID 符合 datasheet

Phase 2  Bayer order(unit-02/08)
   ├─ 拍純白卡,取 RAW
   ├─ 檢查 R/Gr/Gb/B 四通道平均
   └─ 通過:Gr≈Gb;輸出 RGGB 或記錄實際順序

Phase 3  黑位與 dark current(unit-13)
   ├─ 拍黑框(鏡頭蓋)取 RAW
   ├─ 量 mean(black level)與 std(read noise)
   └─ 通過:black level 固定、std 在感測器規格內

Phase 4  full well 實測(unit-02)
   ├─ 固定曝光,逐級增加光量(光源可調)
   ├─ 找「code 不再上升」的光量點
   └─ 通過:飽和 code ≈ 2^bitdepth − 1

Phase 5  global shutter 驗證
   ├─ 拍高速轉動物(扇葉)
   ├─ 逐列是否扭曲(rolling)or 整幀同步(global)
   └─ 通過:無果凍效應 → 確認 global

Phase 6  產出規格表 + 進 repo
   └─ 通過:文件含實測值 vs datasheet 對照
專案要點:感測器 datasheet 是「理想值」,實測才是「你的模組值」。每顆焊接的模組因製程與溫度略有差異——驗收專案的目的就是量化這些差異,供後續調校當基準。

2.15 量測 / 驗證 SOP:感測器關鍵參數量測

感測器參數 SOP(Step 1–6)
Step 1  準備
   黑框(鏡頭蓋)、白卡、灰卡、可調光源、三腳架
Step 2  黑位 / read noise
   固定曝光+gain,暗場取 20 張 RAW
   mean=black level,std=read noise(unit-13.14)
Step 3  Bayer order
   白卡 RAW 四通道平均,判別排列
Step 4  full well
   逐步加光,找飽和點(unit-02.5 的估算公式反向驗證)
Step 5  global shutter
   高速轉動物體測試,判斷果凍效應
Step 6  記錄
   每一項記錄:mode、曝光、gain、溫度、光量

判讀指標:
  黑位:應為固定常數(unit-08)
  read noise:隨 gain 線性放大 → 正常
  full well:飽和 code 對應回電子數 ≈ datasheet ±20%

2.16 平台間對照:感測器支援生態

面向Thor T5000RPi5Orange PiOrin Nano
感測器生態NVIDIA 官方 + 社群模組Raspberry Pi 相機(最多)Allwinner 相容模組NVIDIA 官方 + 工業模組
Global shutter 支援✅(OV9281 等)✅(IMX296 等)⚠️ 少✅(OV9281 等)
感測器內建 ISP❌(走 NVIDIA ISP)❌(走 libcamera ISP)✅(常啟用)❌(走 NVIDIA ISP)
多顆同型號✅ 6+✅ 2(需 HAT)⚠️ 1–2✅ 4–6
感測器 ID/register 工具i2c-toolsi2c-toolsi2c-toolsi2c-tools
選擇思考:感測器層「原理與 register 完全相同」,差異在「誰支援這顆感測器的驅動」。選平台前先查該感測器在平台上的 driver 與 DTB 支援度。

2.17 互動式檢核清單

2.18 Register 位元級完整工作流

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

Register位址功能Bit Field 說明
SENSOR_GAIN_REG0x0104 (OV9281)Analogue Gain 控制bit[7:0] = gain value, 寫入後需等待 1 frame 生效
讀→改→寫→驗證 完整序列(以 SENSOR_GAIN_REG 為例)
# Step 1: 讀取目前值
$ devmem2 0x0104 (OV9281) w
# 記錄 current_value

# Step 2: 計算新值
$ new_value=$(current_value | 0x0001)

# Step 3: 寫入
$ devmem2 0x0104 (OV9281) w $new_value

# Step 4: 驗證讀回值與預期一致
$ devmem2 0x0104 (OV9281) w
$ [ "$(devmem2 0x0104 (OV9281) w | grep Read)" = "expected" ] && echo "PASS" || echo "FAIL"

2.19 多層疑難排解決策樹

決策樹 1:影像偏暗或全黑
1. 感測器輸出全黑(code=0)?
   ├─ 暴露時間 = 0?→ 檢查 AE 設定或手動 exposure register
   ├─ Gain = 0 + 極暗環境?→ 調高 analog gain 0x0104
   └─ 輸出不是 0 但極低 → 檢查黑位 black level offset register
2. 影像偏暗但仍可見?
   ├─ AE convergence 正常?→ `v4l2-ctl --list-ctrls` 看 exposure/gain 值
   └─ AE 正常但偏暗 → ISP pipeline 的亮度目標值(bright_target)太低
決策樹 2:Bayer 顏色錯亂
1. 紅綠反覆、藍黃反覆?
   ├─ 是 → Bayer order 錯(RGGB vs BGGR)
   │  └─ 修改 device tree 的 `bayer-order` 或 ISP CCM matrix
   └─ 否 → 色彩偏移
      ├─ 單色偏 → CCM 校正不準,重跑白卡校正
      └─ 全面偏 → AWB 未收斂,檢查光源色溫

2.20 量測驗證完整 SOP

感測器基本參數量測 SOP:

步驟動作指令/方法預期輸出
Step 1設定已知光源6500K 日光燈或 D65 light box光源穩定無 flicker
Step 2拍攝白卡18% grey card, 全畫面覆蓋ISO 12233 或白卡中心 ROI
Step 3量測黑位蓋住鏡頭,取 10 幀平均code 應在 60–80 之間(10-bit)
Step 4量測 Read Noise暗場 100 幀,算 std dev期望 < 2 LSB RMS
Step 5量測 Full Well白卡逐級增加曝光,找 saturation 點期望 > 4000 DN(10-bit)
Step 6動態範圍計算DR = 20×log10(FW/RN)期望 > 60 dB

2.21 四平台終極對照

面向Thor T5000RPi5Orange PiOrin Nano
感測器格式支援RAW8–16, YUV, PDAFRAW10, YUVRAW10, YUVRAW10–14, HDR
Shutter 類型Global + RollingGlobal(OV5647 除外)Rolling onlyGlobal + Rolling
Analogue Gain 範圍1×–64×1×–16×(OV5647)1×–8×1×–32×
HDR 模式硬體 Stagger + LED HDR軟體 HDR(single-exposure)硬體 Stagger HDR
PDAF 支援
感測器 ID 讀取I2C: `i2cget -y 1 0x60 0x300A`同左同左同左
開箱即用相容數10+ (NVIDIA partner list)50+30+20+ (NVIDIA partner list)

2.22 完整 Bring-up 小 Checklist

針對「影像感測器基礎」主題的完整 bring-up 步驟清單: