SKU 顏色分選：通道與漂移診斷

目的與適用邊界

在改動閾值、硬湊出預期的 SKU 之前，先在取像、通道轉換、遮罩或類別規則中，找出最早出現的顏色不一致。

本教學給出的是一套工程評估方法，而不是可直接執行的產品認證。Deyi Vision 目前公開的 PC 範例，涵蓋的是在已確認的樣品影像上執行 EAN-13 的工作流程。工程程式碼中的原生 OCR 和檢測部分，使用前必須對照已安裝的執行環境、已繫結的模型和任務逐一核實。瀏覽器範本並不能證明可以在瀏覽器中執行：規劃中的 OpenCV.js 後端需要單獨驗證。雲端辨識須明確核准影像範圍、服務供應商、模型和費用。評審封存檔不是可執行的發行套件。相機、韌體和驅動程式的相容性需另行核查。下文所有紀錄表中的數值均為假設值，不是 Deyi Vision 的量測結果，也不是客戶的結果。

準備佐證

保留一份彩色原始影像、中性參考和一件此前未知的物品。把預期類別單獨凍結，不放進處理輸入中，並記錄目前的轉換版本。寫出另一位工程師無需猜測用的是哪張影像、哪個版本就能重播的失敗紀錄。紀錄中包括原始來源、受影響的區域、實際輸出、預期處置，以及第一個出現偏差的中間結果。記錄該現象出現在重播中、即時取像中，還是兩者都有。修正之後，重新執行原先的失敗案例，以及此前已成功的相鄰條件。靠排除某個區域或接受缺失的結果來消除一次警報，這樣的修正改變的是需求，並沒有解決原因。如果失敗尚未解決，應讓受影響的操作保持在 Review 或禁止狀態，並寫明原因；不要把未經測試的變通辦法標成已驗證的解決方案。顏色分選與 SKU 辨識回答的是不同的問題。某個顏色區域可能與紅色參考相符，而該物品的尺寸、標籤或包裝規格卻是錯的。要先明確該任務是依實物顏色分選、核對預期的 SKU，還是兩項獨立的檢查都要做。使用通道順序已知的彩色影像，並把曝光、白平衡和光源光譜寫入配方。要測試可接受的各批材料、光澤表面、陰影和外來產品，而不是只測一張乾淨的參考色卡。飽和度低時色相不可靠，而被截斷的高光會丟掉演算法無法還原的資訊。未知、無法觀察和混色的物品需要有明確的分流去向。若語意 SKU 辨識使用了模型，要把該模型與顏色閾值分開驗證，並且在向雲端傳輸任何資料之前先取得核准。從最早可觀察到的偏差著手排除問題。把同一份已儲存的來源影像，分別送入未改動的基線和候選方案重播，比較中間影像、區域、數值和結果狀態。如果來源影像本身就不同，這種比較就無法再把問題隔離到演算法上。一次只改動一個懷疑的原因，執行之前先寫下預期效果，假設不成立時要保留這個否定的結果。要把佐證無法判讀、規則不相符、相依項目缺失和執行故障區分開，它們需要不同的補救辦法。重播可以重現軟體故障，但無法驗證即時觸發、照明時序或實際的剔除路徑。這些取像和產線方面的檢查，要作為單獨的後續實驗另行進行。

操作步驟

1. 轉換色彩空間之前，先檢查原始通道順序和一個已知的來源像素。
2. 用聲明的轉換重播同一張原始影像，再比較已儲存的物體遮罩和有效像素分母。
3. 分別檢查白平衡漂移、截斷和低飽和度；無法觀察的顏色必須保持為未知或 Review。
4. 在新取得的影像和相鄰的顏色類別上驗證修正，並保留原來的錯誤結果，不要覆蓋。

解讀試驗結果

假設同一個來源顏色，既可以寫作 RGB [200,40,30]，也可以寫作 BGR [30,40,200]。只調換陣列標籤而不與實際輸入順序對應，其意義就變了。這個像素也好，修正後的預覽也好，都不能證明 SKU 身分。只有灰階的來源影像，無法靠改轉換代碼恢復成原來的顏色。

紀錄表

兩個工程視角

故障診斷

• 紅色物體轉換後變成藍色，提示可能是通道順序問題；先比對原始像素。
• 僅僅換了背景類別就變了，提示遮罩或分母有誤，不一定是出現了新的產品顏色。

驗收與交接

只有當第一個出現偏差的環節已被重現、已被修正，並且用獨立的已知樣品和未知樣品核對過，才可結束診斷。剩餘的不確定之處要保持可見，並記錄取像、幾何或判定邏輯是否發生了變化。

將來源影像、預期判定、確切的版本和完整的結果紀錄放在一起儲存。在選定最終參數之前，先凍結評估集。如果這些答案後來被用於調整工作流程，就把該集合標記為開發資料，並另取一組新的獨立驗收集。要讓 Review、NoResult、執行錯誤和取像缺漏一直計入分母；不要透過篩掉資料列把它們變成合格。把可重現的失敗案例與成功樣例一併儲存。交接資料應寫明：誰有權更改配方，如何恢復先前已核准的版本，以及在驗收之前哪些設備輸出仍保持禁止。僅憑軟體結果，不能證明移動中的實物零件到達了正確的目的地。