Framegrabber API

，可以在命令列中輸入以下內容：

Library	目的
fglib5	透過載入 Applet 來初始化擷取卡 存取 Applet 參數 Memory 管理 影像擷取
siso_genicam	尋找符合 GenICam 標準的相機 存取相機參數 執行相機命令
clsersis	根據 Camera Link 標準與相機通訊
iolibrt	讀取與寫入標準影像檔案格式
display_lib	在視窗中呈現影像資料

Framegrabber API 可用於編寫應用程式，以擷取和處理來自連接至 Basler 擷取卡的相機之影像。Basler 擷取卡和 Framegrabber API 支援使用 Camera Link 和 CoaXPress 標準的相機。

資訊

從 Framegrabber API 5.9 版本開始，API 進行了一些變更。在整個說明文件中，此類變更都會在相應章節中突顯顯示。所有變更均總結在說明文件的 變更歷史記錄 部分中。

Basler 擷取卡透過直接記憶體存取 (DMA)，將來自一台或多台相機的影像直接傳輸到應用程式所配置的 Memory 中。在 Framegrabber API 的語境中，影像資料從相機經由擷取卡進入應用程式 Memory 的路徑被稱為 DMA 通道（從 Framegrabber API 的角度來看，影像資料是透過 DMA 傳輸進入應用程式 Memory 的應用程式語境中）。

應用程式可以設計為在擷取迴圈中等待新影像，或者也可以註冊一個函數，以便在有新影像可用時由 Framegrabber API 呼叫。在這兩種情況下，應用程式只有在影像資料完全傳輸到電腦記憶體且應用程式可以安全處理之後，才會收到新影像的通知。

應用程式必須始終指定一個等待新影像的時間（通常為若干秒）。為等待新影像而呼叫的函數將呼叫隨 Framegrabber SDK 安裝一同提供的作業系統驅動程式，並可使呼叫執行緒進入休眠狀態，直到新影像到達或指定時間過期（以先發生者為準）。如果在指定的等待時間內沒有影像到達，將會產生逾時錯誤並回報給應用程式。

Framegrabber API 的運作方式確保了在等待新影像時具有較低的處理器使用率，並能實現從相機到應用程式的低延遲影像資料傳輸。然而，這意味著大多數應用程式都會實作為在獨立執行緒中執行影像擷取，或者使用回呼機制，而該機制同樣會在由 Framegrabber API 管理的獨立執行緒中執行擷取迴圈。否則，當應用程式等待新影像時，應用程式的主執行緒可能會遭到封鎖。

等待新影像的時間也意味著，應用程式在等待執行緒從作業系統驅動程式呼叫返回之前將無法結束。雖然這對於作為機器上單一使用者介面執行的應用程式來說影響不大，但在多用途電腦上執行且要求在結束應用程式時具備良好回應速度的應用程式，則應當使用較短的等待時間並相應地處理逾時錯誤。

Framegrabber API 中的函數可在不同的執行緒中安全使用，但不同的執行緒不應同時控制相同的 Property 或 DMA 通道。

Basler 擷取卡可以在將影像資料傳輸至應用程式記憶體之前對其進行預先處理。雖然大多數擷取卡支援一組常用標準預先處理功能，但使用 Basler VisualApplets 和 Basler 的可程式化擷取卡時，應用程式開發人員能夠實作更複雜的預先處理，將影像處理工作從 CPU 卸載到擷取卡的 FPGA 上。