Partager via


Structure BITMAPINFOHEADER (wingdi.h)

[La fonctionnalité associée à cette page, DirectShow, est une fonctionnalité héritée. Il a été remplacé par MediaPlayer, IMFMediaEngine et Audio/Video Capture dans Media Foundation. Ces fonctionnalités ont été optimisées pour Windows 10 et Windows 11. Microsoft recommande vivement au nouveau code d’utiliser MediaPlayer, IMFMediaEngine et La capture audio/vidéo dans Media Foundation au lieu de DirectShow, lorsque cela est possible. Microsoft suggère que le code existant qui utilise les API héritées soit réécrit pour utiliser les nouvelles API si possible.]

La structure BITMAPINFOHEADER contient des informations sur les dimensions et le format de couleur d’une image bitmap indépendante de l’appareil (DIB).

Note Cette structure est également décrite dans la documentation GDI. Toutefois, la sémantique des données vidéo est légèrement différente de la sémantique utilisée pour GDI. Si vous utilisez cette structure pour décrire des données vidéo, utilisez les informations fournies ici.
 

Syntaxe

typedef struct tagBITMAPINFOHEADER {
  DWORD biSize;
  LONG  biWidth;
  LONG  biHeight;
  WORD  biPlanes;
  WORD  biBitCount;
  DWORD biCompression;
  DWORD biSizeImage;
  LONG  biXPelsPerMeter;
  LONG  biYPelsPerMeter;
  DWORD biClrUsed;
  DWORD biClrImportant;
} BITMAPINFOHEADER, *LPBITMAPINFOHEADER, *PBITMAPINFOHEADER;

Membres

biSize

Spécifie le nombre d’octets requis par la structure. Cette valeur n’inclut pas la taille de la table de couleurs ou la taille des masques de couleur, s’ils sont ajoutés à la fin de la structure. Consultez la section Notes.

biWidth

Spécifie la largeur de l’image bitmap, en pixels. Pour plus d’informations sur le calcul de la foulée de la bitmap, consultez Remarques.

biHeight

Spécifie la hauteur de l’image bitmap, en pixels.

  • Pour les bitmaps RVB non compressées, si biHeight est positif, la bitmap est une DIB de bas en haut avec l’origine dans le coin inférieur gauche. Si biHeight est négatif, la bitmap est une DIB supérieure vers le bas avec l’origine dans le coin supérieur gauche.
  • Pour les bitmaps YUV, la bitmap est toujours top-down, quel que soit le signe de biHeight. Les décodeurs doivent proposer des formats YUV avec biHeight positif, mais pour une compatibilité descendante, ils doivent accepter les formats YUV avec biHeight positif ou négatif.
  • Pour les formats compressés, biHeight doit être positif, quelle que soit l’orientation de l’image.

biPlanes

Spécifie le nombre de plans pour l’appareil cible. Cette valeur doit être définie sur 1.

biBitCount

Spécifie le nombre de bits par pixel (bpp). Pour les formats non compressés, cette valeur correspond au nombre moyen de bits par pixel. Pour les formats compressés, cette valeur correspond à la profondeur de bits implicite de l’image non compressée, une fois l’image décodée.

biCompression

Pour les formats vidéo et YUV compressés, ce membre est un code FOURCC, spécifié en tant que DWORD dans un ordre peu endian. Par exemple, la vidéo YUYV a le FOURCC « VYUY » ou 0x56595559. Pour plus d’informations, consultez Codes FOURCC.

Pour les formats RVB non compressés, les valeurs suivantes sont possibles :

Valeur Signification
BI_RGB
RVB non compressé.
BI_BITFIELDS
RVB non compressé avec des masques de couleur. Valide pour les bitmaps 16-bpp et 32-bpp.
 

Pour plus d'informations, consultez la section Notes. Notez que BI_JPG et BI_PNG ne sont pas des formats vidéo valides.

Pour les bitmaps 16 bpp, si la biCompression est égale à BI_RGB, le format est toujours RVB 555. Si la biCompression est égale à BI_BITFIELDS, le format est RVB 555 ou RVB 565. Utilisez le GUID de sous-type dans la structure AM_MEDIA_TYPE pour déterminer le type RVB spécifique.

biSizeImage

Spécifie la taille, en octets, de l’image. Cette valeur peut être définie sur 0 pour les bitmaps RVB non compressées.

biXPelsPerMeter

Spécifie la résolution horizontale, en pixels par mètre, de l’appareil cible pour l’image bitmap.

biYPelsPerMeter

Spécifie la résolution verticale, en pixels par mètre, de l’appareil cible pour l’image bitmap.

biClrUsed

Spécifie le nombre d’index de couleur dans la table de couleurs qui sont réellement utilisés par l’image bitmap. Pour plus d'informations, consultez la section Notes.

biClrImportant

Spécifie le nombre d’index de couleur considérés comme importants pour l’affichage de l’image bitmap. Si cette valeur est égale à zéro, toutes les couleurs sont importantes.

Remarques

Tables de couleurs

La structure BITMAPINFOHEADER peut être suivie d’un tableau d’entrées de palette ou de masques de couleur. Les règles dépendent de la valeur de la biCompression.
  • Si la biCompression est égale à BI_RGB et que l’image bitmap utilise 8 bpp ou moins, la bitmap a une table de couleurs immédiatement après la structure BITMAPINFOHEADER . La table de couleurs se compose d’un tableau de valeurs RGBQUAD . La taille du tableau est donnée par le membre biClrUsed . Si biClrUsed est égal à zéro, le tableau contient le nombre maximal de couleurs pour le bitdepth donné ; autrement dit, 2^biBitCount couleurs.
  • Si la biCompression est égale à BI_BITFIELDS, la bitmap utilise trois masques de couleur DWORD (respectivement rouge, vert et bleu), qui spécifient la disposition d’octets des pixels. Les 1 bits de chaque masque indiquent les bits de cette couleur dans le pixel.
  • Si biCompression est une vidéo FOURCC, la présence d’une table de couleurs est implicite par le format vidéo. Vous ne devez pas supposer qu’il existe une table de couleurs lorsque la profondeur de bits est de 8 bpp ou moins. Toutefois, certains composants hérités peuvent supposer qu’une table de couleurs est présente. Par conséquent, si vous allouez une structure BITMAPINFOHEADER , il est recommandé d’allouer de l’espace pour une table de couleurs lorsque la profondeur de bits est inférieure ou égale à 8 bpp, même si la table de couleurs n’est pas utilisée.
Lorsque BITMAPINFOHEADER est suivi d’une table de couleurs ou d’un ensemble de masques de couleur, vous pouvez utiliser la structure BITMAPINFO pour référencer la table de couleurs des masques de couleur. La structure BITMAPINFO est définie comme suit :
typedef struct tagBITMAPINFO {
    BITMAPINFOHEADER bmiHeader;
    RGBQUAD          bmiColors[1];
} BITMAPINFO;

Si vous castez BITMAPINFOHEADER en BITMAPINFO, le membre bmiHeader fait référence au BITMAPINFOHEADER et le membre bmiColors fait référence à la première entrée de la table de couleurs ou au premier masque de couleur.

N’oubliez pas que si l’image bitmap utilise une table de couleurs ou des masques de couleur, la taille de la structure de format entière ( bitmapINFOHEADER plus les informations de couleur) n’est pas égale à sizeof(BITMAPINFOHEADER) ou sizeof(BITMAPINFO). Vous devez calculer la taille réelle pour chaque instance.

Calcul de la foulée surface

Dans une bitmap non compressée, la foulée correspond au nombre d’octets nécessaires pour passer du début d’une ligne de pixels au début de la ligne suivante. Le format d’image définit une foulée minimale pour une image. En outre, le matériel graphique peut nécessiter une plus grande foulée pour la surface qui contient l’image.

Pour les formats RVB non compressés, la foulée minimale est toujours la largeur de l’image en octets, arrondie au DWORD le plus proche. Pour calculer la foulée et la taille de l’image, vous pouvez utiliser les macros GDI_DIBWIDTHBYTES et/ou GDI_DIBSIZE , ou la formule suivante :

stride = ((((biWidth * biBitCount) + 31) & ~31) >> 3);
biSizeImage = abs(biHeight) * stride;

Pour les formats YUV, il n’existe aucune règle générale pour calculer la foulée minimale. Vous devez comprendre les règles pour le format YUV particulier. Pour obtenir une description des formats YUV les plus courants, consultez Formats YUV 8 bits recommandés pour le rendu vidéo.

Les décodeurs et les sources vidéo doivent proposer des formats où biWidth est la largeur de l’image en pixels. Si le convertisseur vidéo nécessite une foulée de surface supérieure à la foulée d’image par défaut, il modifie le type de média proposé en définissant les valeurs suivantes :

Ensuite, le convertisseur vidéo propose le format modifié en appelant IPin ::QueryAccept sur le amont broche. Pour plus d’informations sur ce mécanisme, consultez Modifications de format dynamique.

S’il existe un remplissage dans la mémoire tampon d’image, ne déréférencez jamais un pointeur dans la mémoire réservée pour le remplissage. Si la mémoire tampon d’image a été allouée dans la mémoire vidéo, le remplissage peut ne pas être de la mémoire lisible.

Configuration requise

   
En-tête wingdi.h

Voir aussi

DirectShow Structures

VIDEOINFOHEADER Structure

VIDEOINFOHEADER2 Structure

Utilisation des images vidéo