YCLABTECH / YUNG LO
CASE STUDY / COMPUTER VISION

沒有圖傳 API,如何串接目標偵測與告警?

多目標監視器警報系統

以既有監視器軟體的畫面為輸入,將螢幕擷取、目標檢測與管理員通知串成一個工作流程。

已有公開實作說明 · 交付與驗收狀態待確認

01 / 問題與現場限制

既有監視器播放程式不支援圖傳相關 API,無法直接從該程式取得影像供辨識流程使用。專案需要在這個限制下,處理多個監視畫面,並在出現目標時通知對應管理員。

這讓影像來源的取得方式成為整合設計的起點。

02 / 我的參與

這是我在 YCLabTech 既有作品頁中介紹的影像辨識專案。此篇整理的參與範圍是畫面擷取、目標檢測與告警流程的整合。

現有公開資料未細分團隊角色,因此不將模型訓練、全部程式開發或現場部署歸為我獨立完成。

03 / 解法

採用螢幕截圖取得既有軟體顯示的畫面,再進行目標檢測;當偵測到目標時,通知對應管理員。

INPUT

既有監視畫面 → 螢幕擷取

沿用原有軟體顯示的畫面,作為辨識流程的影像來源。

DETECTION

擷取畫面 → 目標檢測

對多個監視畫面進行目標檢測,判斷是否出現需通知的目標。

ACTION

偵測事件 → 管理員通知

將偵測結果接到對應管理員的通知流程。

04 / 關鍵取捨

從可取得的輸入開始。
螢幕擷取提供了無圖傳 API 條件下的整合途徑。這項選擇也讓系統依賴畫面是否正常顯示,以及畫質與版面是否適合辨識。

把辨識放回工作流程。
有偵測結果之後,仍須把事件送到對應人員。案例的工程重點因此包含輸入與通知兩端的串接。

以上限制分析是對此方案的工程整理;不代表已完成所有異常情境測試。

05 / 已有結果與證據邊界

既有公開作品頁記載,系統使用螢幕截圖處理同時 16 路目標檢測,並在目標出現時通知對應管理員。這支持本案例的功能描述。

目前未取得測試環境、幀率、準確率、誤報率、通知延遲或驗收紀錄。因此,16 路僅引用原作品說明,不代表本次重測或在所有環境下的效能保證;本案例也未標記為已交付或正式驗收。

依 YCLabTech 原作品介紹整理;未加入未確認的客戶資料或測試數據。

06 / 反思與後續驗證

這個案例呈現了模型之外的工程工作:先找出可取得的輸入,再將辨識結果接到使用者真正需要的通知流程。

若繼續完善此系統,我會優先驗證畫面移動或遮擋、來源中斷、誤報,以及通知失敗時的行為,並記錄端到端延遲。這些是後續驗證建議。

有類似的整合問題?

歡迎一起討論現有系統的限制與可行的接入方式。