Windows 映像處理元件的運作方式
探索和仲裁
在影像譯碼之前，必須先找到可譯碼該影像格式的適當編解碼器。 在大部分系統中，由於支援的影像格式是硬式編碼，因此不需要探索程式。 由於 Windows 映射元件 （WIC） 平臺是可延伸的，因此必須能夠識別影像的格式，並將它與適當的編解碼器相符。
若要支援運行時間探索，每個影像格式都必須有識別模式，可用來識別該格式的適當譯碼器。 （強烈建議您針對新的檔格式使用 GUID 進行識別模式，因為它保證是唯一的。識別模式必須內嵌在符合該影像格式的每個圖像檔案中。 每個解碼器都有一個註冊表項目，指定它可以解析的影像格式的識別模式。 當應用程式需要開啟映像時，它會向 WIC 要求譯碼器。 WIC 會查閱登錄中可用的譯碼器，並檢查每個登錄專案是否有符合映像檔內嵌模式的識別模式。 如需譯碼器登錄專案的詳細資訊，請參閱 Encoder-Specific 登錄專案
當 WIC 找到符合影像中識別模式的單一譯碼器時，它會建立譯碼器的實例，並將圖像文件傳遞給它。 如果 WIC 找到多個匹配項，它會在每個相符解碼器上叫用名為 QueryCapability 的方法，以在它們之間進行仲裁，並尋找最佳匹配。 如需詳細資訊，請參閱 實作 IWICBitmapDecoder中的 QueryCapabilities 一節。
解碼
選取並具現化適當的譯碼器之後，應用程式會直接與譯碼器交談。 譯碼器有數個責任，它會透過各種介面實作。 這些服務可以分類為：
- 容器層級服務
- 框架層級服務
- 元數據列舉服務
- 原生解碼器轉換
- 進度通知和取消支援
- 原始處理服務
容器層級服務包括擷取最上層縮圖（如果支援）、預覽、色彩內容、調色盤（如果適用），以及容器格式，以及提供容器內個別影像框架的存取權。 （某些容器只包含單一框架，而其他容器，例如標記圖像檔格式（TIFF），可以包含多個框架。 這組服務也包含提供譯碼器本身的相關信息，以及其與特定圖像文件相關的功能。
個別框架有自己的縮圖，也可能有自己的色彩內容、調色盤和其他屬性，這些屬性會在框架層級公開。 不過，在每個畫面層級執行的最重要操作是對該畫面的影像位元進行實際解碼。
WIC 提供最常見元數據格式的元數據讀取器（IFD、EXIF、IPTC、XMP、APP0、APP1 和其他格式），也支援第三方元數據格式的擴充性。 這使編解碼器不再需要負責剖析元數據。 不過，編解碼器負責列舉元數據區塊，並要求每個區塊的元數據讀取器。 WIC 探索元數據處理程式的方式與編解碼器相同，都是經由比對區塊標頭中的模式與元數據處理程式登錄專案中的模式來進行。 如需詳細資訊，請參閱 Encoder-Specific 登錄專案
譯碼器不需要原生支援轉換作業，但這樣做可大幅優化效能，以提供更佳的用戶體驗。 例如，應用程式可以建立各種轉換的管線（縮放、裁剪、旋轉和像素格式轉換），以在轉譯影像之前對影像執行。 如需轉換管線的詳細資訊，請參閱 IWICBitmapSource。 建立轉換管線之後，應用程式會要求管線中的最終轉換，以產生將所有轉換套用至影像來源所產生的點陣圖。 此時，如果譯碼器本身能夠執行轉換作業，WIC 會詢問譯碼器它可以執行哪些所要求的轉換。 譯碼器無法執行的任何要求轉換，都會在譯碼的影像上由WIC執行，然後再將它傳回給呼叫端。 此優化轉換管線可提供比在記憶體中循序執行每個轉換更好的效能，尤其是在譯碼程序期間完成部分或所有轉換時。
進度通知和取消支援可讓應用程式要求長時間作業的進度通知，並讓用戶有機會取消花費太久的作業。 這很重要，因為如果使用者無法取消作業，他或她可能會覺得程式已停止回應，並嘗試關閉應用程式來取消它。
在 啟用 WIC 的譯碼器實作一節中，詳細說明了這些介面。
原始處理服務包括調整相機設定，例如曝光、對比和銳化，或在處理原始位之前變更色彩空間。
編碼
就像譯碼器一樣，編碼器有責任透過介面實作。 編碼器所提供的服務與譯碼器所提供的服務互補，不同之處在於它們會寫出影像數據，而不是讀取它。 編碼器也提供下列類別的服務：
- 容器層級服務
- 框架層級服務
- 元數據列舉和更新服務
- 進度通知和取消支援
編碼器的容器層級服務包括設定最上層縮圖（如果支援）、預覽和調色盤（如果適用），以及逐一查看個別影像框架，以便將其串行化至容器。
編碼器的畫面層級服務會鏡像譯碼器的畫面層級服務，不同之處在於它們會寫出影像數據、縮圖，以及任何相關聯的調色盤或其他元件，而不是讀取它們。
此外，編碼器的元數據列舉服務包括逐一查看要寫入的元數據區塊，以及叫用適當的元數據寫入器，將元數據串行化至磁碟。
編解碼器的存留期
WIC 編解碼器會具現化來處理單一映像，且通常存留期很短。 它會在載入映射時建立，並在關閉映像時釋放。 應用程式可能會同時使用大量具有重疊的生命週期的編解碼器（想像一下瀏覽包含數百個圖像的目錄），而且多個應用程式可能同時進行這項操作。
雖然有些編解碼器的存留期限定於其生存程式的存留期，但 WIC 編解碼器的情況並非如此。 Windows Vista 相片庫、Windows 檔案總管和相片查看器以及其他許多應用程式都是建置在 WIC 上，而且會使用編解碼器來顯示影像和縮圖。 如果編解碼器的存留期限定於程式的存留期，則每次在 Windows Vista 檔案總管中顯示影像或縮圖時，將影像具現化為譯碼的編解碼器會保留在記憶體中，直到下次使用者重新啟動其電腦為止。 如果您的編解碼器從未卸除，其資源實際上會「外泄」，因為它們無法供系統中的任何其他元件使用。
如何啟用具有 WIC 支援的編解碼器
- 實作容器層級譯碼器類別和框架層級譯碼器類別，其會公開譯碼影像所需的 WIC 介面，並逐一查看元數據區塊。 這可讓所有以 WIC 為基礎的應用程式與您的編解碼器進行互動的方式，就像與標準影像格式互動一樣。
- 實作容器層級編碼器類別和框架層級編碼器類別，該類別會公開編碼影像所需的 WIC 介面，並將元數據區塊串行化為圖像檔。
- 如果您的容器格式不是以 TIFF 或 JPEG 容器為基礎，您可能需要撰寫通用元數據格式的元數據處理程式（EXIF、XMP）。 不過，如果您使用 TIFF 型或 JPEG 型容器格式，則不需要這樣做，因為您可以委派給系統提供的元數據處理程式。
- 在所有映像檔中內嵌唯一的識別模式（我們建議 GUID）。 這可讓您的影像格式在探索期間與您的編解碼器進行比對。 如果您要為現有的影像格式撰寫 WIC 包裝器，您必須找到一種位元模式，這是編碼器始終寫入其影像檔案的特徵，並使用此模式作為識別依據。
- 在安裝時間註冊編解碼器。 這可以讓您的編解碼器在執行期間被檢測到，方法是比對登錄中的識別模式與映像檔中內嵌的模式。
- 從 Windows 7 開始，WIC 要求編解碼器必須是 COM Apartment 類型「Both」。 這表示您必須執行適當的鎖定，以處理跨公寓呼叫者和多執行緒環境中的來電者。 如需詳細資訊，請參閱多線程 Apartment 支援的下一節。
- 支援 64 位平臺：針對 Windows 7，WIC 會要求以 32 位和 64 位原生二進位檔的形式提供第三方 WIC 編解碼器。 此外，32 位窗體必須在64位系統上安裝並執行，而第三方 Windows 7 編解碼器安裝程式必須在64位系統上安裝32位和64位二進位檔。
WIC 中的多線程 Apartment 支援
多執行緒公寓（MTA）內的物件可由 MTA 內任意數量的執行緒同時調用。 這可在多核心系統和特定伺服器案例上提供更好的效能。 此外，MTA 中的 WIC 編解碼器可以呼叫 MTA 中的其他物件，而無需承擔在不同 STA 公寓中的線程間呼叫所產生的封送成本。 在 Windows 7 中，所有內建 WIC 編解碼器都已更新為支援 MTA，包括 JPEG、TIFF、PNG、GIF、ICO 和 BMP。 強烈建議撰寫第三方編解碼器以支援 MTA。 不支援 MTA 的第三方編解碼器在多線程應用程式中因為封送處理而造成顯著的效能成本。 啟用 MTA 支援需要在第三方編解碼器中實作適當的同步處理。 這些同步處理技術的確切實作已超出本文的範圍。 如需同步處理 COM 物件的詳細資訊，請參閱 瞭解和使用 COM 線程模型。