# 影像處理與轉換模組 (Image Processor) 深度分析

在 `CB_IMGPSScanImp.pas.bk` 中，「影像處理與轉換模組」負責在硬體掃描取得原始影像後，以及上傳/顯示之前，對影像進行一系列的強化、分析與格式轉換。這個模組是決定影像品質、檔案大小與後續 OMR 辨識準確率的關鍵。

若要將此模組進一步細拆，其內部組成可分為以下四大子分類：

---

## 1. 影像幾何與物理變換引擎 (Image Geometric Transformation Engine)

**職責**：專責處理影像的空間座標轉換、旋轉、去斜以及裁切，確保最終儲存的影像端正且符合業務規定的尺寸。
**核心實作特性**：
*   **影像去斜與轉正**：
    *   `DeskewImg`：透過演算法自動偵測影像傾斜角度並將其校正。
    *   `Rotate`：依據條碼辨識出的角度 (`MpsBarcodeinf.r180`) 或使用者手動點擊按鈕 (`SpeedButton14Click` 等)，進行 90、180、270 度的旋轉。
*   **影像裁切與分割**：
    *   `CheckNeedCrop`：根據影像寬高比與偵測到的條碼數量，判斷是否為需要分割的 A3 雙頁合併影像。
    *   `CropImg`：給定 `TRect` 座標，將 A3 影像精準裁切為兩張 A4 (`iGraphic_First`, `iGraphic_sec`)。
*   **影像縮放 (Resize)**：
    *   `ImageReSize_FormID` / `ImageReSize_tmp`：依據表單定義檔 (`FORM_INF`) 中的長寬設定與尋找到的十字定位點，強制將影像縮放變形至標準尺寸，以利後續的 OMR 座標對位。
    *   `DpiResize`：調整影像的 DPI 解析度參數。

## 2. 色彩處理與編碼轉換器 (Color & Format Converter)

**職責**：處理影像的色彩深度 (位元深度) 轉換，以及針對不同色彩模式套用最適合的檔案壓縮演算法，以達到最佳的畫質與檔案大小平衡。
**核心實作特性**：
*   **色彩空間轉換**：
    *   `ConvertToBW`：將彩色或灰階影像強制二值化 (Binarization) 轉為黑白影像，這不僅能大幅縮小檔案，也是條碼與 OMR 辨識的必要前置步驟 (系統通常會保留一個隱藏的 `ISB_BW` 物件專做辨識用)。
    *   `ConvertToGray`：將彩色轉換為灰階 (`ifGray256`)。
    *   `Image_Smooth` / `NegativeImg` / `CleanupBorder`：影像平滑化、反相處理與清除黑邊。
*   **格式與壓縮決策**：
    *   針對黑白影像 (`ifBlackWhite`)：使用 `tcGroup4` (CCITT Group 4 Fax Compression) 或 `tcPackBits` 壓縮，並儲存為 `.tif`。
    *   針對彩色/灰階影像 (`ifTrueColor`, `ifGray256`, `ifColor256`)：轉換為 `TJpegGraphic`，套用 `tcJpeg` 壓縮與指定的壓縮率 (`FJpgCompression` / `SaveQuality`)，並儲存為 `.jpg`。

## 3. 條碼識別與解析器 (Barcode Recognizer)

**職責**：獨立負責掃描與解析影像上的一維或二維條碼，這是系統實現「文件自動歸類」的核心依賴。
**核心實作特性**：
*   **條碼引擎呼叫**：
    *   `MpsGetBarcode`：呼叫底層的 MPS Barcode 引擎，傳入二值化的影像 (`ISB_BW.Graphic`)。
    *   回傳 `TMpsBarcodeinf` 結構，包含條碼內容字串陣列 (`Text`) 與每個條碼的方向資訊 (`r180`)。
*   **應用與邏輯綁定**：
    *   透過條碼字串找出對應的 `FormID` 與 `DocNo`。
    *   檢查條碼長度是否符合規範 (`FormIDLength`)，過濾雜訊或誤判的條碼。

## 4. OMR 與十字定位點分析器 (OMR & Anchor Analyzer)

**職責**：專門為「光學標記辨識 (OMR)」服務，負責找出影像上的基準定位點，並計算特定區域內的黑白像素分佈。
**核心實作特性**：
*   **基準點尋找 (Anchor Finding)**：
    *   `FindPoint`：根據 XML 定義的模式 (`ANCHOR` 或 `FRAME`)，在影像四個角落尋找定位基準點 (`UpLPoint`, `UpRPoint`, `DownLPoint`, `DownRPoint`)。
    *   `CheckSize`：比對找到的定位點距離與標準長寬是否有巨大落差，若找不到則記錄至 `AnchorError.dat`。
*   **像素計算與標記判定 (Pixel Calculation)**：
    *   `GetSiteOMR`：根據 XML 傳入的相對座標字串 (`Site`)，將其換算為實際的 `TRect`。
    *   `Get_OMR`：計算該區域內黑色像素的數量。
    *   結合雜訊過濾 (`ClearLine`) 與容差值 (`SafePixel`, `bt`)，最終判定該 OMR 欄位是否「有畫記」。

---


## 影像相關關鍵字:
```js
[
'TTiffGraphic',
'TDibGraphic',
'DeskewImg',
'Rotate',
'CropImg',
'ImageReSize_FormID',
'ImageReSize_tmp',
'CheckNeedCrop',
'ImageProcessor.transformer',
'ConvertToBW',
'ConvertToGray',
'Image_Smooth',
'NegativeImg',
'CleanupBorder',
'ImageProcessor.converter',
'MpsGetBarcode',
'Get_OMR',
'ImageProcessor.barcodeRecognizer',
'FindPoint',
'CheckSize',
'GetSiteOMR',
'ImageProcessor.anchorAnalyzer',
'TJpegGraphic',
'DpiResize',
// 以下可省
'SaveQuality',
'FJpgCompression',
'ifTrueColor',
'ifGray256',
'ConvertToBW',
'ConvertToGray',
'Image_Smooth',
'NegativeImg',
'CleanupBorder',
'ifBlackWhite',
'tcGroup4',
'tcPackBits',
'tcJpeg',
'ifColor25'
]
```


## 💡 未來重構與微服務化建議

若要對此影像處理模組進行重構，建議方向如下：

1.  **抽離為獨立的 Pipeline 模式 (管線模式)**：
    目前這些功能散落在 `OnAcquire` 與各個事件中。應將其重構為一條清晰的影像處理管線：`Image -> Deskew -> Crop -> ConvertBW -> BarcodeRead -> Resize -> Compress -> Save`。每個步驟 (Step) 應該是獨立的類別，方便抽換或開關。
2.  **解耦 UI 與影像處理**：
    目前大量依賴畫面上隱藏的 `ISB_BW` (TImageScrollBox) 來進行二值化和條碼辨識。這違反了 MVC 原則且耗費額外的 GDI 資源。應改用純記憶體物件 (如獨立的 `TDibGraphic` 或 `TBitmap`) 在背景執行緒中進行這些運算，不要綁定可見的 UI 元件。
3.  **引入更現代的影像引擎 (如 OpenCV)**：
    早期依賴的 Envision SDK 在尋找十字定位點 (FindPoint) 和去斜 (DeskewImg) 的演算法可能較為老舊。若未來轉型為微服務架構，可將這部分邏輯移植為 Python/C++ 並使用 OpenCV 來達成更精準的高速運算。