DIBs et ses applications

Voici le texte de l'article « .dib et leurs utilise ». Cet article est disponible dans l'aide de Windows le format de fichier dans la bibliothèque logicielle Microsoft en plus sur le texte présenté ci-dessous.

Les fichiers suivants sont disponibles au téléchargement à partir du Centre de téléchargement Microsoft :


Dibs2.exe (http://download.microsoft.com/download/platformsdk/article/3.1/w31/en-us/dibs2.exe)
Pour plus d'informations sur la façon de télécharger des fichiers de support technique Microsoft, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft : Microsoft a analysé ce fichier de virus. Microsoft utilisé les logiciels de détection de virus plus récente ne sont associé à la date à laquelle le fichier a été validé. Le fichier est stocké sur des serveurs sécurisés, pour empêcher toute modification non autorisée dans le fichier. Cet article décrit le concept (bitmap indépendante du périphérique) DIB de définition et la structure à l'API qui l'utilise. Inclus est une application de petit exemple qui illustre certaines des méthodes courantes de l'utilisation de .dib pour afficher et manipuler des images numériques. Fonctions abordées sont GetDIBits() , SetDIBits() , CreateDIBitmap() , SetDIBitsToDevice() , StretchDIBits() et CreateDIBPatternBrush() . Cet article n'aborde pas avec des palettes .dib.

GÉNÉRALES

Une image indépendante du périphérique (DIB) est un format utilisé pour définir des images bitmap indépendante du périphérique dans diverses résolutions de couleur. Le principal .dib vise à permettre des bitmaps à déplacer d'un périphérique à un autre (par conséquent, la partie indépendante du périphérique du nom). Un DIB est un format externe, contrairement à une image dépend du périphérique, qui apparaît dans le système en tant qu'objet bitmap (créé par une application à l'aide CreateBitmap() CreateCompatibleBitmap() , CreateBitmapIndirect() ou CreateDIBitmap() ). Un DIB est généralement transporté dans métafichiers (généralement utilisant la fonction StretchDIBits() ), les fichiers BMP et le Presse-papiers (format de données CF_DIB).

Un DIB se compose de deux parties : les bits eux-mêmes et un en-tête qui décrit le format des bits. L'en-tête contient le format de couleur, une table des couleurs et la taille de l'image bitmap. Le format DIB actuel prend en charge quatre résolutions de couleurs: 1 bit 4 bits, 8 bits et 24 bits. Dans .dib 1 bit 4 bits et 8 bits, les pixels sont définis par l'index (de la résolution appropriée bits) dans la table de couleurs ; 24 bits pixels décrites comme des valeurs de 24 bits, 1 octet chaque pour rouge, vert et bleu. Les fonctions DIB sont :

' INDÉPENDANCE DU PÉRIPHÉRIQUE - QUI S IL CONVIENT AUX ?

Transfert des bitmaps couleur d'un périphérique à un autre est impossible dans les versions de l'environnement Microsoft Windows graphique précédemment que 3.0. Avec .dib, chaque périphérique affiche l'image dans la mesure de sa résolution couleur. Une application peut stocker une image dans le format DIB et ensuite afficher, de quel que soit le dispositif de sortie ; une application doivent créer n'est plus une version de chaque image pour chaque type de périphérique.

Cette capacité de transfert d'image peut servir à imprimer en demi-teintes images. Par exemple, la fonction StretchDIBits() peut transmettre un DIB directement à un pilote d'imprimante intelligent. Étant donné les informations de couleur complet de l'image au lieu de simplement une version monochrome (la méthode traditionnelle), le pilote pouvez utiliser les demi-teintes pour imprimer une image réaliste.

Car le format DIB publiquement est défini, une application peut le manipuler à la volée. En fait, une application peut générer une image sans aucune intervention de Windows. Si Windows n'a pas une primitive de dessin, l'application pouvez le simuler directement dans le DIB au lieu d'utiliser les primitives d'interface (GDI) périphérique graphique existant. Malheureusement, sous Windows versions 3.0 et 3.1, GDI ne peut pas effectuer des opérations sortie directement à un DIB.

FORMATS DE FICHIER BMP

L'extension de fichier d'un fichier Windows DIB est BMP. Le fichier se compose d'une structure BITMAPFILEHEADER suivie par le DIB lui-même. Malheureusement, car la structure BITMAPFILEHEADER jamais est passée à l'API, pas chaque application qui génère les fichiers BMP remplit la structure de données avec soin. Pour ajouter à cette confusion, la définition de « correcte de la structure est à odds avec la documentation. Correctement, la structure de données contient les champs suivants : DIB l'en-tête suit immédiatement la structure BITMAPFILEHEADER .

Pour un exemple de code qui lit un fichier BMP, voir l'exemple de programme.

L'en-tête DIB

L'en-tête se compose en réalité de deux parties adjacentes : l'en-tête approprié et la table des couleurs. Les deux sont combinés dans la structure BITMAPINFO , c'est-à-dire toutes les API DIB prévu.

Windows version 3.0 prend en charge existe deux types d'en-têtes : BITMAPINFOHEADER et BITMAPCOREHEADER. Si possible, les applications doivent utiliser BITMAPINFOHEADERs uniquement. La définition de BITMAPCOREHEADER est basée sur la définition bitmap de gestionnaire de présentation version 1.1 et est pris en charge à de compatibilité avec les.

Lors d'une opération de paramètre DIB, la plupart des champs sont déjà renseignés par les personnes généré le DIB. Effectuer un appel GetDIBits() , cependant, offre davantage de contrôle. La manière dont l'en-tête est renseigné pour que cette opération définit la DIB résultant, en particulier sa résolution couleur.

BITMAPINFOHEADER contient les champs suivants : la table des couleurs suit immédiatement les informations d'en-tête. Aucune table des couleurs n'est défini pour .DIB 24 bits. Le tableau se compose d'un tableau de structures de données RGBQUAD. (La table pour le format BITMAPCOREINFO est générée avec la structure de données RGBTRIPLE .) Octets de rouges, verts et bleus sont dans l'ordre inverse (position procède rouge avec bleu) de la convention de Windows. C'est une autre leftover de compatibilité du Gestionnaire de présentation.

La taille de la table des couleurs dépend de la valeur biBitCount (et peut être remplacée à l'aide du champ biClrUsed ; voir ci-dessus): .dib plus flottante autour actuellement ont biClrUsed définie à 0, mais si tout complète DIB bashing est prévu, un bon intérêt lui correctement. Si biClrUsed est différente de zéro, une table couleur 24 bits .dib est possible. GDI n'utilise pas cette table des couleurs, mais l'application pouvez l'utiliser pour déterminer les couleurs importantes utilisées dans le DIB.

Toutes les fonctions DIB inclut un paramètre wUsage, qui peut affecter la définition de la table des couleurs. Cet article permet d'éviter l'utilisation des palettes avec .dib et ce qui suppose que wUsage est toujours définie sur DIB_RGB_COLORS et que la table des couleurs est donc toujours composée de valeurs. Lorsque DIB_PAL_COLORS est utilisé, la table des couleurs se compose de valeurs WORD index dans la palette logique actuellement sélectionnée. (Cette rubrique est décrit en détail dans l'article « à l'aide de .dib avec palettes »).

Format binaire

L'en-tête définit le format des bits, mais tous les formats de partagent les règles suivantes :

• Chaque ligne de numérisation est DWORD-aligné. La ligne de numérisation est mises en mémoire tampon dans Alignement ; le tampon n'est pas nécessairement 0.
• Les lignes de numérisation sont stockés envers, avec l'analyse première (analyse 0) dans la mémoire en cours de l'analyse de l'image plus basse. (Voir figure 1). C'est une autre artefact de compatibilité du Gestionnaire de présentation. GDI inverse automatiquement l'image au cours des opérations Set et Get. La figure 1. (Image incorporée montrant les représentations de mémoire et l'écran.)
• Limites de segment de 64 Ko ne sont pas respectées, lignes de numérisation peut couper ces limites (contrairement au format d'image dépendant du périphérique mises en mémoire tampon aux limites de 64 Ko).

Chaque format présente les caractéristiques suivantes :

• 1 bit .dib est stockées en chaque bit d'index dans la table des couleurs. Le bit de poids fort est le pixel plus à gauche.

.dib 4 bits est stockées avec chaque 4 bits représentant un index dans la table des couleurs. Le quartet plus important est le pixel plus à gauche.

• .dib 8 bits est les plus faciles à stocker, car chaque octet est un index.
• .DIB 24 bits ont tous 3 octets représentant une couleur en utilisant le même ordering comme la table des couleurs. Ce format est particulièrement difficile au cours de traitement car une limite de 64 Ko peut exister au milieu d'un triple couleur-une condition difficile qui doit être gérée avec précaution.

UTILISATION DE L'API DIB

GetDIBits() et SetDIBits()

Ces deux fonctions sont utilisées pour convertir des images bitmap indépendante du périphérique en images bitmap dépend du périphérique et inversement. SetDIBits() convertit un DIB en une image dépend du périphérique et GetDIBits() génère un DIB à partir d'une image dépend du périphérique.

Le pilote de périphérique référencé par la hDC passé dans les deux appels effectue la conversion réelle. Certains pilotes de périphériques ne possèdent cette fonctionnalité (par exemple, un pilote de version 2.0 de Windows ou un pilote de version 3.0 Windows primitif). Dans ce cas, GDI simule la conversion, mais uniquement dans monochrome-informations de couleur sont converties en noir et blanc. Pour l'essentiel, toutefois, ce n'est pas un problème. Tous les pilotes d'affichage self-respecting prennent en charge cette fonctionnalité et seulement certains pilotes d'imprimante n'offrent pas la traduction, pilotes généralement monochromes pour laquelle les simulations GDI suffit.

GetDeviceCaps(hDC, RASTERCAPS) renvoie une valeur WORD avec des indicateurs définir indiquant le DIB fonctionne le prend en charge de pilote. RC_DI_BITMAP indique prise en charge de GetDIBits() et SetDIBits() , RC_DIBTODEV indique prise en charge de SetDIBitsToDevice() ; RC_STRETCHDIB indique prise en charge de StretchDIBits() . Toute fonction non prise en charge peut être simulée, bien que les simulations soient souvent pas aussi utile en tant que la chose réelle (principalement car les informations de couleur sont perdues). Un périphérique ne pourrez peut-être pas prendre en charge la fonctionnalité complète même si un peu est définie. Par exemple, un périphérique peut gérer StretchDIBits mais uniquement pour les intégrales stretches. Malheureusement, une application n'a aucun moyen pour déterminer l'achèvement de la mise en ?uvre. Dans ce cas, GDI simule la fonction.

Les paramètres sont les mêmes pour les GetDIBits() et SetDIBits() : Utilisation SetDIBits() est relativement simple. Un DIB provient de quelque part (par exemple, à partir du Presse-papiers ou d'un fichier disque) et est converti à un objet bitmap, qui peut ensuite être sélectionné dans un contrôleur de domaine et blted à l'écran pour l'affichage. C'est le moyen plus simple pour afficher un DIB.

note Pour de nombreuses imprimantes faire toutes les demi-teintes, cette méthode n'est pas par défaut ; StretchDIBits (décrit dans l'exemple suivant) est beaucoup plus utile.

Voici un affichage simple d'un DIB à un contrôleur de domaine (avec aucune gestion des erreurs): Utilisation GetDIBits() est plus complexe, car l'application peut choisir quel type de DIB pour générer. La taille de l'image source régule dimensions les DIB (un élément peut être extraites par blting dans une image plus petite), mais doivent pouvez dicter l'application la résolution couleur.

Pour GetDIBits() fonctionner correctement, l'application doit définir les champs suivants dans l'en-tête : aussi, l'espace alloué pour la table couleur doit être suffisant pour contenir une table en taille réelle : l'espace alloué pour lpBits doit également être assez grand pour contenir nNumScans de données. L'appel renseigne les champs suivants de la structure :

• biSizeImage = taille en octets de données DIB
• Table des couleurs (pour les cas non 24 bits) est rempli avec couleurs appropriées
• lpBits est rempli avec les données DIB

Si GetDIBits() est appelée avec lpBits définies avec la valeur NULL, aucun bits ne sont renvoyés, uniquement biSizeImage et la table des couleurs sont renseignés. Cette option est utile pour .dib avec RLE et n'est pas souhaitable pour .dib non codé.

Objectifs de l'application pour le DIB déterminent quel résolution couleur pour choisir. L'approche habituel est de générer un DIB conserve les informations de couleur de l'image dépendant du périphérique source. Choix une moindre aboutit résolution une perte des informations de couleur, qui est généralement indésirable. Toujours à l'aide de résolution 24 bits n'est inutile, toutefois, étant donné que cela ajoute aucune résolution couleur plus si la source a résolution 8 bits ou moins. calcul résolution l'image bitmap doit tenir compte que des bitmaps dépendant du périphérique sont planar (notamment EGA et VGA). DIBs, d'autre part, sont toujours « emballés pixels, « avec plan 1 seulement par pixel (biPlanes = 1).

Les paramètres nStartScan et nNumScans (residue de compatibilité du Gestionnaire de présentation) sont conçus pour être utilisés pour la tranche. Si suffisamment de mémoire est disponible pour charger le DIB entier en mémoire dans une pièce, la lpBits pouvant être apportées à pointer uniquement à une partie des bits. Prenons l'exemple suivant : définir le code prend la bande donnée, les convertit et place la bande traduite dans son emplacement correct, comptabilité à toutes les heures pour l'avantage nature de .dib déroulant. Notez comment biHeight ne pas modifier à tout moment parce que la bande est mises dans la bitmap en fonction de la hauteur de l'image complète. nStart est basé sur la hauteur de l'image complète (définie par biHeight).

CreateDIBitmap()

Le code suivant illustre l'appel CreateDIBitmap() avec le cas habituel : Ceci équivaut à: implémentation de GDI ignore la partie SetDIBits() si le troisième paramètre n'est pas défini avec l'indicateur CBM_INIT. Cette fonction rend pour raccourci intéressante de codage de la conversion de DIB à image dépendant du périphérique.

SetDIBitsToDevice()

SetDIBitsToDevice() permet à une application définir un DIB directement sur une surface du périphérique. Étant donné que cette fonction est un holdout du développement au plus tôt, son interface n'est pas élaborée qu'elle pourrait l'être. StretchDIBits() est une fonction beaucoup plus puissante que SetDIBitsToDevice() . StretchDIBits() ne tout que SetDIBitsToDevice() et possède une interface mieux. SetDIBitsToDevice() est limitée de la manière qu'il gère les métafichiers, car il ne pas redimensionner et bandes avec les paramètres nStartScan et nNumScans est importante au mieux. StretchDIBits() n'autorise pas la bande.

Le code suivant effectue la fonctionnalité SetDIBitsToDevice() sur l'image complète (pas de bandes) à l'aide de StretchDIBits : en supposant que nStartScan est définie sur 0 et que nNumScans est définie à lpInfo-> biHeight (c'est-à-dire qu'aucune tranche), la fonction est en fait un BitBlt avec SRCCOPY en tant que les opérations de TRAME et un DIB en tant que source. SrcX et SrcY compte espace les DIB et compte donc envers par rapport au contrôleur de domaine (Y = 0 est au bas de l'image).

Affaire à l'envers DIB est difficile lorsque vous effectuez un paramètre partiel. Par exemple, si une application veut obtenir la partie inférieure troisième d'un DIB est w en pixels h pour le périphérique au (x, y), l'appel ressemble à celui-ci : une image bitmap dépend du périphérique aura un SrcY de 2h/3 pour le bas Troisièmement, mais avec l'avantage déroulantes système de le DIB, un SrcY de points h/3 à l'endroit approprié par rapport à Windows de coordonnées.

StretchDIBits()

Cette fonction est le chouchou de faire à tout pour afficher un DIB sur la surface d'un périphérique. Il est particulièrement intéressante pour metafiling et pour l'impression, pour lequel la possibilité d'étendre est importante.

Un trou critique dans l'implémentation actuelle de StretchDIBits() est que StretchDIBits() est pris en charge par les pilotes d'imprimante et non par nombre affiche pilotes. Par conséquent, utiliser cette fonction à plusieurs reprises pour étirer un DIB à l'écran est sensiblement plus lent qu'à l'aide de SetDIBits (pour obtenir une image dépend du périphérique) suivi d'appels répétés StretchBlt() .

L'implémentation de cette fonction dans GDI est très simple. Si le pilote de périphérique peut traiter l'appel proprement dit, elle ne. Si ce n'est pas le cas et l'appel est 1-à-1 et le périphérique prend en charge SetDIBitsToDevice() , l'appel est converti à un appel SetDIBitsToDevice() au pilote. (Cela fonctionne uniquement avec SRCCOPY en tant que les opérations de TRAME.) Si aucun de ces méthodes n'est possible, CreateDIBitmap() est utilisé pour faire d'une version dépendant du périphérique de l'image bitmap, et StretchBlt est appelée pour effectuer le travail réel.

Les paramètres de StretchDIBits() sont pratiquement identiques à ceux des StretchBlt() (avec la source hDC remplacé par lpBits et lpInfo). Cette fonction n'a pas le nStartScan et les paramètres nNumScans des autres DIB fonctions, de sorte lpBits pointe toujours vers la première analyse de la DIB.

Lorsque vous utilisez cette fonction pour autre chose que stretches image complète, rappelez-vous que tous les coordonnées source (ceux concernant le DIB) sont dans un système envers. La fonction va retourner correctement l'image, mais le rectangle source est défini avec Y=0 au bas et étendues va haut. Heureusement, les coordonnées x utiliser les mêmes conventions que Windows.

Les pilotes d'imprimante qui prennent en charge cette fonctionnalité (par exemple, PSCRIPT et HPPCL) généralement permet un algorithme de demi-teintes de sortie des images en couleurs bon. Par conséquent, maintenance .dib à la résolution couleur significatifs le plus élevée possible (généralement 8 bits) est recommandée même si le périphérique de sortie est monochrome, car les les couleur informations sont toujours utiles pour les bons résultats. Malheureusement, la plupart des pilotes d'imprimante ne prennent en charge les opérations de TRAME autre que SRCCOPY.

CreateDIBPatternBrush()

Cette fonction permet à une application créer un pinceau de motif en spécifiant un DIB au lieu d'un bitmap dépend du périphérique, comme utilisé dans la fonction CreatePatternBrush() . Un pinceau créé à l'aide de cette fonction est utilisé similaire aux autres curseurs. Le DIB est converti en une image dépend du périphérique en temps SelectObject() pour utilisation par le périphérique. Ce pinceau ressemble à un pinceau modèle standard sur le périphérique.

DIBS DANS LE PRESSE-PAPIERS

Deux mécanismes de base de placement .dib dans le Presse-papiers utilisent le format de données CF_DIB ou placer le DIB dans un métafichier et à l'aide du format de données CF_METAFILEPICT.

Le format CF_DIB utilise un DIB compressée, dans lequel les bits suivre immédiatement après l'en-tête et de la table des couleurs. Lorsque lisez ou créer un DIB compressée, une application doit calculer correctement la taille de la table de couleurs pour vous assurer que les bits sont à l'emplacement adéquat. Étant donné que toutes les fonctions DIB prévu la DIB comme deux pointeurs, un à l'en-tête et un pour les bits, le pointeur de bits doit être calculé avant utilisation. (Pour les calculs de taille du tableau couleur, voir l'exemple de code dans la description table couleur ci-dessus.)

La plus simple pour placer un DIB dans un métafichier consiste à utiliser StretchDIBits() : cette méthode génère un métafichier que lorsque lu affiche le DIB vers la destination. Cette méthode également Redimensionne l'image pour ajuster le jeu de mappage actuel si nécessaire. Les métafichiers pour le transfert grâce même les applications qui ne sont pas DIB-connaissance pour coller le contenu du Presse-papiers sans perdre les informations DIB.

RLE FORMATS

Lorsque le champ biCompression dans en-tête un DIB est défini sur soit BI_RLE4 (pour biBitCount = 4) ou BI_RLE8 (pour biBitCount = 8), l'image a été codé run-length. Une description des schémas de codage pouvez trouver dans le « Microsoft Windows Software développement Kit référence volume 2 », dans la section « BITMAPINFOHEADER » de « types de données et structures » chapitre. Le schéma de base implique la compression multiples, horizontalement les pixels de l'adjacentes, mêmes dans un codage exécution. Par exemple, 10 pixels de couleur index 17 sont codés comme une exécution de longueur 10 et d'index 17. Codes pour fin de numérisation et passe delta sont également fournis, dans lequel un X et un décalage Y sont fournies pour le pixel suivant.

Ce type de codage généralement permet de compresser l'image et est également utile pour créer des animations sprite-type, dans lequel une petite partie d'une image change dans chaque cadre. Les fonctionnalités d'animation sont effectuer en utilisant les codes delta pour limiter le nombre de pixels en fait défini. Pixels ignorés par un déplacement delta sont reste inchangés.

Les limitations principales de RLE .dib qu'une application peut ne sont ni facilement déterminer la taille de l'image bitmap en octets ni pointez sur une ligne de numérisation certain sans décoder l'image bitmap de la première analyse. Le champ biSizeImage est utile pour résoudre le premier problème. Décodage, codage et généralement manipuler la RLE format est plus lente et plus compliqué que le format (BI_RGB) noncompressed. Certaines applications--par exemple, Paintbrush--refuse de lire .dib RLE. Bien que toutes les API acceptent les, RLE .dib seront probablement pas un format universellement pris en charge. En outre, en raison de rarity relative de ces formats, certains pilotes de périphérique ne peut-être pas entièrement testé prise en charge pour les processus de codage et de décodage.

Pour générer un DIB RLE, GetDIBits() est appelée avec biCompression type de codage souhaité. La quantité de mémoire nécessaires pour stocker les bits est calculée pas facilement. Si GetDIBits() est appelée avec lpBits définies avec la valeur NULL, la quantité de mémoire nécessaire pour les bits est renvoyée dans biSizeImage. Un appel suivant avec lpBits pointant vers un bloc de mémoire correctement taille renvoie une image codée.

Traduire un DIB RLE dans un formulaire dépendant du périphérique ne requiert aucun traitement spécial. Des fonctions de jeu peuvent servir normalement avec un en-tête contenant les biSizeImage approprié et les valeurs biCompression faire pour correspondre les bits.

DÉFAUTS DE DIBS

Probablement la limite plus importante de .dib est que qu'ils sont plus lentes que bitmaps dépendant du périphérique. Conversion .dib dans un formulaire dépendant du périphérique avant d'elles en fait être affichés nécessite supplémentaire traitement, entraînant la surcharge supplémentaire. Dans un monde idéal, un StretchDIBits() 1-à-1 est aussi rapide qu'une BitBlt() . Cette vitesse devez autoriser une application de fonctionner efficacement dans le domaine de l'image bitmap logique, avec couleur et un accès complet à chaque pixel, indépendamment des limitations du périphérique physique.

DIBs sont basées dans un système de coordonnées est envers relative à Windows, rendre le codage un peu frustrant et pas intuitive. Toujours mémoriser Cette quirkiness devrait permettre de limite le nombre d'itérations nécessaires pour obtenir des images alignées correctement.

Vous pouvez obtenir couleur utilisant .DIB 24 bits, mais ils sont très lent décoder, lire et écrire. Cela est particulièrement vrai sur 8 bits palette périphériques, dans lequel traduction littérale peut prendre minutes. La taille importante de 24 bits .dib rend les un peu encombrant pour une utilisation générale.

PROBLÈMES LIÉS À LA DIB DANS WINDOWS VERSION 3.0

Métafichier enregistrement des appels StretchDIBits() qui utilisent BITMAPCOREHEADER entraîne un eau. Convertir tous les en-têtes le style BITMAPINFO pour éviter ce problème. Cette solution de contournement est recommandée pour DIB générale du traitement.

Le code de simulation SetDIBits() pour supérieure à 64 Ko monochrome .dib provoque se bloque ou impression erronée lorsque vous utilisez un SetDIBits() , un SetDIBitsToDevice() ou un StretchDIBits() à un pilote qui ne prend pas en charge SetDIBits() .

Copyright 1992 par Microsoft Corporation. Tous droits réservés.