Fonctionnement du Composant Imagerie Windows
Découverte et arbitrage
Avant qu’une image puisse être décodée, vous devez trouver un codec approprié qui peut décoder ce format d’image. Dans la plupart des systèmes, étant donné que les formats d’image pris en charge sont codés en dur, aucun processus de découverte n’est nécessaire. Étant donné que la plateforme Windows Imaging Component (WIC) est extensible, il est nécessaire d’identifier le format d’une image et de le mettre en correspondance avec un codec approprié.
Pour prendre en charge la découverte au moment de l’exécution, chaque format d’image doit avoir un modèle d’identification qui peut être utilisé pour identifier le décodeur approprié pour ce format. (Il est vivement recommandé d’utiliser un GUID pour les nouveaux formats de fichier pour le modèle d’identification, car il est garanti qu’il soit unique.) Le modèle d’identification doit être incorporé dans chaque fichier image conforme à ce format d’image. Chaque décodeur a une entrée de Registre qui spécifie le ou les modèles d’identification des formats d’image qu’il peut décoder. Lorsqu’une application doit ouvrir une image, elle demande un décodeur à WIC. WIC recherche les décodeurs disponibles dans le registre et recherche dans chaque entrée de Registre un modèle d’identification qui correspond au modèle incorporé dans le fichier image. Pour plus d’informations sur les entrées de Registre du décodeur, consultez Entrées de Registre spécifiques à l’encodeur
Lorsque WIC trouve un décodeur unique qui correspond au modèle d’identification dans l’image, il crée une instance du décodeur et lui transmet le fichier image. Si WIC trouve plusieurs correspondances, il appelle une méthode appelée QueryCapability sur chaque décodeur correspondant pour arbitrer entre eux et trouver la meilleure correspondance. Pour plus d’informations, consultez la section QueryCapabilities dans Implémentation de IWICBitmapDecoder.
Décodage
Une fois le décodeur approprié sélectionné et instancié, l’application communique directement avec le décodeur. Le décodeur a plusieurs responsabilités, qu’il implémente via différentes interfaces. Ces services peuvent être classés comme suit :
- Services au niveau du conteneur
- Services au niveau de l’image
- Services d’énumération de métadonnées
- Transformations de décodeur natif
- Notifications de progression et prise en charge de l’annulation
- Services de traitement brut
Les services au niveau du conteneur incluent la récupération de la miniature de niveau supérieur (si prise en charge), l’aperçu, les contextes de couleur, la palette (le cas échéant) et le format conteneur, ainsi que l’accès aux cadres d’image individuels dans le conteneur. (Certains conteneurs ne contiennent qu’une seule trame, tandis que d’autres, comme TIFF (Tagged Image File Format), peuvent contenir plusieurs images.) Cet ensemble de services inclut également la fourniture d’informations sur le décodeur lui-même et ses fonctionnalités par rapport à un fichier image spécifique.
Les cadres individuels ont leurs propres miniatures et peuvent également avoir leurs propres contextes de couleurs, palettes et autres propriétés, qui sont exposés au niveau de l’image. L’opération la plus importante effectuée au niveau de l’image, cependant, est le décodage réel des bits d’image pour cette image.
WIC fournit des lecteurs de métadonnées pour les formats de métadonnées les plus courants (IFD, EXIF, IPTC, XMP, APP0, APP1 et autres formats), et prend également en charge l’extensibilité pour les formats de métadonnées tiers. Cela libère le codec de la responsabilité de l’analyse des métadonnées. Toutefois, le codec est responsable de l’énumération des blocs de métadonnées et de la demande d’un lecteur de métadonnées pour chaque bloc. WIC effectue la découverte pour les gestionnaires de métadonnées de la même façon que pour les codecs, en fonction d’un modèle dans l’en-tête de bloc correspondant à un modèle dans l’entrée de Registre du gestionnaire de métadonnées. Pour plus d’informations, consultez entrées de Registre spécifiques à l’encodeur
Les décodeurs ne sont pas nécessaires pour prendre en charge en mode natif les opérations de transformation, mais cela permet d’optimiser significativement les performances qui offrent une meilleure expérience utilisateur final. Par exemple, une application peut créer un pipeline de différentes transformations (mise à l’échelle, rognage, rotation et conversion au format de pixel) à effectuer sur une image avant que l’image ne soit rendue. Pour plus d’informations sur les pipelines de transformation, consultez IWICBitmapSource. Après avoir créé un pipeline de transformation, l’application demande la transformation finale dans le pipeline pour produire la bitmap qui résulte de l’application de toutes les transformations à la source d’image. À ce stade, si le décodeur lui-même est en mesure d’effectuer des opérations de transformation, WIC demande laquelle des transformations demandées peut effectuer. Toutes les transformations demandées que le décodeur ne peut pas effectuer seront effectuées par WIC sur l’image décodée avant de la renvoyer à l’appelant. Ce pipeline de transformation optimisé offre de meilleures performances que l’exécution séquentielle de chaque transformation en mémoire, en particulier lorsque certaines ou toutes les transformations peuvent être effectuées pendant le processus de décodage.
Les notifications de progression et la prise en charge de l’annulation permettent à une application de demander des notifications de progression pour les opérations longues, et permettent également à l’application de donner à l’utilisateur la possibilité d’annuler une opération qui prend trop de temps. Cela est important, car si un utilisateur ne peut pas annuler une opération, il peut sentir que le processus s’est bloqué et essayer de l’annuler en fermant l’application.
Ces interfaces sont décrites en détail dans la section implémentation d’un décodeur wic.
Les services de traitement brut incluent le réglage des paramètres de la caméra, tels que l’exposition, le contraste et le netteté, ou la modification de l’espace de couleur avant de traiter les bits bruts.
Encodage
Comme les décodeurs, les encodeurs ont des responsabilités qu’ils implémentent via des interfaces. Les services fournis par les encodeurs sont complémentaires aux services fournis par les décodeurs, sauf qu’ils écrivent des données d’image au lieu de les lire. Les encodeurs fournissent également des services dans les catégories suivantes :
- Services au niveau du conteneur
- Services au niveau de l’image
- Services d’énumération et de mise à jour des métadonnées
- Notification de progression et prise en charge de l’annulation
Les services au niveau du conteneur pour un encodeur incluent la définition de la miniature de niveau supérieur (si prise en charge), l’aperçu et la palette (le cas échéant), et l’itération dans les trames d’image individuelles afin qu’elles puissent être sérialisées dans le conteneur.
Les services au niveau de l’image pour un encodeur miroir ceux du décodeur, sauf qu’ils écrivent les données d’image, la miniature et toute palette ou tout autre composant associé, au lieu de les lire.
En outre, les services d’énumération de métadonnées pour un encodeur incluent l’itération au sein des blocs de métadonnées à écrire et l’appel des enregistreurs de métadonnées appropriés pour sérialiser les métadonnées sur le disque.
Ces interfaces sont décrites en détail dans la section Implémentation d’un encodeur compatible WIC.
Durée de vie d’un codec
Un codec WIC est instancié pour gérer une seule image et a généralement une courte durée de vie. Il est créé lors du chargement d’une image et libéré à la fermeture de l’image. Une application peut utiliser un grand nombre de codecs simultanément avec des durées de vie qui se chevauchent (pensez à faire défiler un répertoire contenant des centaines d’images), et plusieurs applications peuvent le faire en même temps.
Bien que certains codecs aient une durée de vie limitée à la durée de vie du processus dans lequel ils vivent, ce n’est pas le cas avec les codecs WIC. La galerie de photos Windows Vista, windows Explorer et la visionneuse de photos, ainsi que de nombreuses autres applications, reposent sur WIC et utilisent votre codec pour afficher des images et des miniatures. Si la durée de vie de votre codec était limitée à la durée de vie du processus, chaque fois qu’une image ou une miniature était affichée dans le Explorer Windows Vista, le codec instancié pour décoder cette image resterait en mémoire jusqu’à la prochaine fois que l’utilisateur redémarre son ordinateur. Si votre codec n’est jamais déchargé, ses ressources sont en fait « divulguées », car elles ne peuvent être utilisées par aucun autre composant du système.
Guide pratique pour activer un codec WIC
- Implémentez une classe de décodeur au niveau du conteneur et une classe de décodeur au niveau de l’image qui expose les interfaces WIC requises pour décoder des images et effectuer une itération au sein de blocs de métadonnées. Cela permet à toutes les applications WIC d’interagir avec votre codec de la même façon qu’elles interagissent avec les formats d’image standard.
- Implémentez une classe d’encodeur au niveau du conteneur et une classe d’encodeur au niveau de la trame qui expose les interfaces WIC requises pour l’encodage d’images et la sérialisation de blocs de métadonnées dans un fichier image.
- Si votre format de conteneur n’est pas basé sur un conteneur TIFF ou JPEG, vous devrez peut-être écrire des gestionnaires de métadonnées pour les formats de métadonnées courants (EXIF, XMP). Toutefois, si vous utilisez un format de conteneur basé sur TIFF ou JPEG, cela n’est pas nécessaire, car vous pouvez déléguer aux gestionnaires de métadonnées fournis par le système.
- Incorporez un modèle d’identification unique (nous vous recommandons un GUID) dans tous vos fichiers image. Cela permet à votre format d’image d’être mis en correspondance avec votre codec pendant la découverte. Si vous écrivez un wrapper WIC pour un format d’image existant, vous devez trouver un modèle de bits que l’encodeur écrit toujours dans ses fichiers image qui est propre à ce format d’image, et l’utiliser comme modèle d’identification.)
- Inscrivez votre codec au moment de l’installation. Cela permet de découvrir votre codec au moment de l’exécution en faisant correspondre le modèle d’identification dans le Registre avec le modèle incorporé dans le fichier image.
- À partir de Windows 7, WIC exige que les codecs soient de type COM « Both ». Cela signifie que vous devez effectuer le verrouillage approprié pour gérer les appelants et les appelants inter-appartements dans les scénarios multithread. Pour plus d’informations, consultez la section suivante sur la prise en charge des appartements multithreads.
- Prise en charge des plateformes 64 bits : pour Windows 7, WIC nécessite que les codecs WIC tiers soient fournis en tant que binaires natifs 32 bits et 64 bits. En outre, le formulaire 32 bits doit installer et s’exécuter sur des systèmes 64 bits, et le programme d’installation de codec Windows 7 tiers doit installer les fichiers binaires 32 bits et 64 bits sur les systèmes 64 bits.
Prise en charge de l’appartement multithread dans WIC
Les objets au sein d’un multithreaded Apartment (MTA) peuvent être appelés simultanément par n’importe quel nombre de threads au sein du MTA. Cela permet de meilleures performances sur les systèmes multicœurs et certains scénarios de serveur. En outre, les codecs WIC dans un MTA peuvent appeler d’autres objets dans l’assistant de gestion sans le coût de marshaling associé à l’appel entre des threads dans différents appartements STA. Dans Windows 7, tous les codecs WIC in-box ont été mis à jour pour prendre en charge les MTA, notamment JPEG, TIFF, PNG, GIF, ICO et BMP. Il est vivement recommandé d’écrire des codecs tiers pour prendre en charge les MTA. Les codecs tiers qui ne prennent pas en charge les MMA entraînent des coûts de performances importants dans les applications multithread en raison du marshaling. L’activation de la prise en charge de MTA nécessite l’implémentation d’une synchronisation appropriée dans le codec tiers. L’implémentation exacte de ces techniques de synchronisation dépasse le cadre de ce document. Pour plus d’informations sur la synchronisation des objets COM, consultez Understanding and Using COM Threading Models.
Rubriques connexes
Commentaires
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultez https://aka.ms/ContentUserFeedback.
Envoyer et afficher des commentaires pour