BITMAPINFOHEADER-Struktur (wingdi.h)

Artikel
12/22/2023

[Das dieser Seite zugeordnete Feature DirectShow ist ein Legacyfeature. Es wurde von MediaPlayer, IMFMediaEngine und Audio/Video Capture in Media Foundation abgelöst. Diese Features wurden für Windows 10 und Windows 11 optimiert. Microsoft empfiehlt dringend, dass neuer Code mediaPlayer, IMFMediaEngine und Audio/Video Capture in Media Foundation anstelle von DirectShow verwendet, wenn möglich. Microsoft schlägt vor, dass vorhandener Code, der die Legacy-APIs verwendet, so umgeschrieben wird, dass nach Möglichkeit die neuen APIs verwendet werden.]

Die BITMAPINFOHEADER-Struktur enthält Informationen zu den Abmessungen und dem Farbformat einer geräteunabhängigen Bitmap (DEVICE-Independent Bitmap, DIB).

Hinweis Diese Struktur wird auch in der GDI-Dokumentation beschrieben. Die Semantik für Videodaten unterscheidet sich jedoch geringfügig von der Semantik, die für GDI verwendet wird. Wenn Sie diese Struktur verwenden, um Videodaten zu beschreiben, verwenden Sie die hier angegebenen Informationen.

Syntax

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;

Member

biSize

Gibt die Anzahl von Bytes an, die für die -Struktur erforderlich sind. Dieser Wert enthält nicht die Größe der Farbtabelle oder die Größe der Farbmasken, wenn sie am Ende der Struktur angefügt werden. Siehe Hinweise.

biWidth

Gibt die Breite der Bitmap in Pixel an. Informationen zum Berechnen des Schritts der Bitmap finden Sie unter Hinweise.

biHeight

Gibt die Höhe der Bitmap in Pixel an.

Wenn biHeight bei nicht komprimierten RGB-Bitmaps positiv ist, handelt es sich bei der Bitmap um einen Bottom-up-DIB mit dem Ursprung in der unteren linken Ecke. Wenn biHeight negativ ist, ist die Bitmap ein DIB von oben nach unten mit dem Ursprung in der oberen linken Ecke.
Bei YUV-Bitmaps ist die Bitmap immer von oben nach unten, unabhängig vom Vorzeichen von biHeight. Decoder sollten YUV-Formate mit positivem biHeight anbieten, aber zur Abwärtskompatibilität sollten sie YUV-Formate mit positivem oder negativem biHeight akzeptieren.
Bei komprimierten Formaten muss biHeight unabhängig von der Bildausrichtung positiv sein.

biPlanes

Gibt die Anzahl der Ebenen für das Zielgerät an. Dieser Wert muss auf 1 festgelegt werden.

biBitCount

Gibt die Anzahl der Bits pro Pixel (bpp) an. Bei nicht komprimierten Formaten ist dieser Wert die durchschnittliche Anzahl von Bits pro Pixel. Bei komprimierten Formaten ist dieser Wert die implizierte Bittiefe des unkomprimierten Bilds, nachdem das Bild decodiert wurde.

biCompression

Bei komprimierten Video- und YUV-Formaten ist dieser Member ein FOURCC-Code, der als DWORD in little-endianischer Reihenfolge angegeben wird. Beispielsweise enthält YUYV-Video den FOURCC "VYUY" oder 0x56595559. Weitere Informationen finden Sie unter FOURCC-Codes.

Für unkomprimierte RGB-Formate sind die folgenden Werte möglich:

Wert	Bedeutung
BI_RGB	Unkomprimiertes RGB.
BI_BITFIELDS	Unkomprimiertes RGB mit Farbmasken. Gültig für 16-bpp- und 32-bpp-Bitmaps.

Weitere Informationen finden Sie unter Hinweise. Beachten Sie, dass BI_JPG und BI_PNG keine gültigen Videoformate sind.

Wenn biCompression bei 16-bpp-Bitmaps gleich BI_RGB ist, ist das Format immer RGB 555. Wenn biCompressiongleich BI_BITFIELDS ist, ist das Format entweder RGB 555 oder RGB 565. Verwenden Sie die Untertyp-GUID in der AM_MEDIA_TYPE-Struktur , um den spezifischen RGB-Typ zu bestimmen.

biSizeImage

Gibt die Größe des Bilds in Bytes an. Dies kann für unkomprimierte RGB-Bitmaps auf 0 festgelegt werden.

biXPelsPerMeter

Gibt die horizontale Auflösung des Zielgeräts für die Bitmap in Pixel pro Meter an.

biYPelsPerMeter

Gibt die vertikale Auflösung des Zielgeräts für die Bitmap in Pixel pro Meter an.

biClrUsed

Gibt die Anzahl der Farbindizes in der Farbtabelle an, die tatsächlich von der Bitmap verwendet werden. Weitere Informationen finden Sie unter Hinweise.

biClrImportant

Gibt die Anzahl der Farbindizes an, die für die Anzeige der Bitmap als wichtig angesehen werden. Wenn dieser Wert null ist, sind alle Farben wichtig.

Hinweise

Farbtabellen

Auf die BITMAPINFOHEADER-Struktur kann ein Array von Paletteneinträgen oder Farbmasken folgen. Die Regeln hängen vom Wert von biCompression ab.

Wenn biCompressiongleich BI_RGB ist und die Bitmap 8 bpp oder weniger verwendet, weist die Bitmap eine Farbtabelle auf, die unmittelbar auf die BITMAPINFOHEADER-Struktur folgt. Die Farbtabelle besteht aus einem Array von RGBQUAD-Werten . Die Größe des Arrays wird vom biClrUsed-Element angegeben. Wenn biClrUsed null ist, enthält das Array die maximale Anzahl von Farben für die angegebene Bitdepth. d. h. 2^biBitCount-Farben .
Wenn biCompressiongleich BI_BITFIELDS ist, verwendet die Bitmap drei DWORD-Farbmasken (rot, grün und blau), die das Bytelayout der Pixel angeben. Die 1 Bits in jeder Maske geben die Bits für diese Farbe innerhalb des Pixels an.
Wenn biCompression ein Video FOURCC ist, wird das Vorhandensein einer Farbtabelle durch das Videoformat impliziert. Sie sollten nicht davon ausgehen, dass eine Farbtabelle vorhanden ist, wenn die Bittiefe 8 bpp oder weniger beträgt. Einige Ältere Komponenten können jedoch davon ausgehen, dass eine Farbtabelle vorhanden ist. Wenn Sie eine BITMAPINFOHEADER-Struktur zuweisen, empfiehlt es sich daher, Platz für eine Farbtabelle zuzuweisen, wenn die Bittiefe 8 bpp oder weniger beträgt, auch wenn die Farbtabelle nicht verwendet wird.

Wenn auf BITMAPINFOHEADER eine Farbtabelle oder eine Reihe von Farbmasken folgt, können Sie die BITMAPINFO-Struktur verwenden, um auf die Farbtabelle der Farbmasken zu verweisen. Die BITMAPINFO-Struktur ist wie folgt definiert:

typedef struct tagBITMAPINFO {
    BITMAPINFOHEADER bmiHeader;
    RGBQUAD          bmiColors[1];
} BITMAPINFO;

Wenn Sie BITMAPINFOHEADER in bitmapinfo umwandeln, bezieht sich das bmiHeader-Element auf bitmapinfoheader und das bmiColors-Element auf den ersten Eintrag in der Farbtabelle oder die erste Farbmaske.

Beachten Sie, dass, wenn die Bitmap eine Farbtabelle oder Farbmasken verwendet, die Größe der gesamten Formatstruktur ( BITMAPINFOHEADER plus Farbinformationen) nicht gleich sizeof(BITMAPINFOHEADER) oder sizeof(BITMAPINFO)ist. Sie müssen die tatsächliche Größe für jede instance berechnen.

Berechnen von Surface Stride

In einer nicht komprimierten Bitmap ist der Schritt die Anzahl der Bytes, die benötigt werden, um vom Anfang einer Zeile mit Pixeln zum Anfang der nächsten Zeile zu wechseln. Das Bildformat definiert einen Mindestschritt für ein Bild. Darüber hinaus erfordert die Grafikhardware möglicherweise einen größeren Schritt für die Oberfläche, die das Bild enthält.

Bei nicht komprimierten RGB-Formaten ist der minimale Schritt immer die Bildbreite in Byte, aufgerundet auf das nächste DWORD. Um die Schritt- und Bildgröße zu berechnen, können Sie die makros GDI_DIBWIDTHBYTES und/oder GDI_DIBSIZE oder die folgende Formel verwenden:

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

Für YUV-Formate gibt es keine allgemeine Regel für die Berechnung des Mindestschritts. Sie müssen die Regeln für das jeweilige YUV-Format kennen. Eine Beschreibung der gängigsten YUV-Formate finden Sie unter Empfohlene 8-Bit-YUV-Formate für das Videorendering.

Decoder und Videoquellen sollten Formate vorschlagen, bei denen biWidth die Breite des Bilds in Pixel ist. Wenn der Videorenderer einen Oberflächenschritt erfordert, der größer als der Standardbildschritt ist, ändert er den vorgeschlagenen Medientyp, indem die folgenden Werte festgelegt werden:

Sie legt biWidth gleich dem Oberflächenschritt in Pixel fest.
Es legt den rcTarget-Member des VIDEOINFOHEADER oder VIDEOINFOHEADER2 Struktur gleich der Bildbreite in Pixel fest.

Anschließend schlägt der Videorenderer das geänderte Format vor, indem IPin::QueryAccept auf der Upstream Pin aufgerufen wird. Weitere Informationen zu diesem Mechanismus finden Sie unter Dynamische Formatänderungen.

Wenn der Bildpuffer aufgefüllt wird, dereferenzieren Sie niemals einen Zeiger in den Speicher, der für die Auffüllung reserviert wurde. Wenn der Bildpuffer im Videospeicher zugeordnet wurde, ist der Speicher möglicherweise nicht lesbar.