Framegrabber API#
| Library | 用途 |
|---|---|
| fglib5 |
|
| siso_genicam |
|
| clsersis |
|
| iolibrt |
|
| display_lib |
|
Framegrabber API 可用於開發應用程式，以從連接至 Basler 影像擷取卡的攝影機中擷取並處理影像。Basler 影像擷取卡及Framegrabber API 均支援採用Camera Link 及 CoaXPress 標準的攝影機。
資訊
自Framegrabber API 版本 5.9 起，API 進行了若干變更。在整個文件中，此類變更均已在相關章節中標示出來。所有變更均彙整於文件中的「變更歷史」部分。
Basler 影像擷取卡會利用直接記憶體存取（DMA）技術，將來自一台或多台攝影機的影像直接傳輸至應用程式所分配的記憶體中。在「Framegrabber API 」的脈絡下，影像資料從攝影機經由影像擷取卡傳入應用程式記憶體的傳輸路徑被稱為DMA 通道（從Framegrabber API 的觀點來看，影像資料是透過 DMA 傳輸至應用程式記憶體，從而進入應用程式的執行環境）。
應用程式可設計為在擷取迴圈中等待新影像，或者可註冊一個函式，當有新影像可用時，由Framegrabber API 呼叫該函式。無論採用哪種方式，應用程式都必須等到新影像已完全傳輸至電腦記憶體，且影像資料可由應用程式安全處理之後，才會得知有新影像。
應用程式必須指定一個等待新影像的時間（通常以秒為單位）。用於等待新影像的函式會呼叫隨Framegrabber SDK 安裝所提供的作業系統驅動程式，並可能使呼叫該函式的執行緒進入休眠狀態，直到有新影像傳入或指定時間屆滿為止（以較早發生者為準）。若在指定的等待時間內未收到任何影像，系統將產生超時錯誤並回報給應用程式。
Framegrabber API 的運作方式可確保在等待新影像時，處理器使用率保持在低水平，並能以低延遲將影像資料從相機傳輸至應用程式。然而，這也意味著大多數應用程式將採用在獨立執行緒中執行影像擷取的方式，或使用回呼機制——該機制同樣會在由Framegrabber API 管理的獨立執行緒中執行擷取迴圈。否則，當應用程式等待新影像時，其主執行緒可能會被阻塞。
等待新影像的時間，也可能意味著應用程式必須先等待執行緒從對作業系統驅動程式的呼叫中返回，才能退出。雖然對於例如在機器上作為唯一使用者介面運行的應用程式而言，這並非太大問題；但對於在多用途電腦上運行、且在退出應用程式時需要提供即時回應使用者體驗的應用程式來說，則應採用較短的等待時間，並據此處理超時錯誤。
Framegrabber API 中的函式可在不同執行緒間安全地使用，但不同執行緒不應同時控制相同的功能或 DMA 通道。
Basler 的幀擷取卡可在將影像資料傳輸至應用程式記憶體之前，對其進行預處理。雖然大多數幀擷取卡都支援一套標準的常用預處理功能，但透過使用 Basler 的VisualApplets 以及 Basler 的可程式化幀擷取卡，應用程式開發人員可以實現更複雜的預處理，將影像處理任務從 CPU 卸載至幀擷取卡的 FPGA 上。