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