Estrutura BITMAPINFOHEADER (wingdi.h)

Artigo
12/22/2023

[O recurso associado a esta página, DirectShow, é um recurso herdado. Foi substituído por MediaPlayer, IMFMediaEngine e Audio/Video Capture in Media Foundation. Esses recursos foram otimizados para Windows 10 e Windows 11. A Microsoft recomenda fortemente que o novo código use MediaPlayer, IMFMediaEngine e Audio/Video Capture in Media Foundation em vez de DirectShow, quando possível. A Microsoft sugere que o código existente que usa as APIs herdadas seja reescrito para usar as novas APIs, se possível.]

A estrutura BITMAPINFOHEADER contém informações sobre as dimensões e o formato de cor de um DIB (bitmap independente do dispositivo).

Nota Essa estrutura também é descrita na documentação do GDI. No entanto, a semântica dos dados de vídeo é ligeiramente diferente da semântica usada para GDI. Se você estiver usando essa estrutura para descrever dados de vídeo, use as informações fornecidas aqui.

Sintaxe

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;

Membros

biSize

Especifica o número de bytes exigidos pela estrutura . Esse valor não inclui o tamanho da tabela de cores ou o tamanho das máscaras de cores, se elas forem acrescentadas ao final da estrutura. Consulte Observações.

biWidth

Especifica a largura do bitmap, em pixels. Para obter informações sobre como calcular o passo do bitmap, consulte Comentários.

biHeight

Especifica a altura do bitmap, em pixels.

Para bitmaps RGB descompactados, se biHeight for positivo, o bitmap será um DIB de baixo para cima com a origem no canto inferior esquerdo. Se biHeight for negativo, o bitmap será um DIB de cima para baixo com a origem no canto superior esquerdo.
Para bitmaps YUV, o bitmap é sempre de cima para baixo, independentemente do sinal de biHeight. Os decodificadores devem oferecer formatos YUV com biHeight positivo, mas para compatibilidade com versões anteriores, eles devem aceitar formatos YUV com biHeight positivo ou negativo.
Para formatos compactados, biHeight deve ser positivo, independentemente da orientação da imagem.

biPlanes

Especifica o número de planos para o dispositivo de destino. Esse valor deve ser definido como 1.

biBitCount

Especifica o número de bits por pixel (bpp). Para formatos descompactados, esse valor é o número médio de bits por pixel. Para formatos compactados, esse valor é a profundidade de bit implícita da imagem descompactada, depois que a imagem é decodificada.

biCompression

Para formatos de vídeo compactado e YUV, esse membro é um código FOURCC, especificado como um DWORD em ordem little-endian. Por exemplo, o vídeo YUYV tem o FOURCC 'VYUY' ou 0x56595559. Para obter mais informações, consulte Códigos FOURCC.

Para formatos RGB descompactados, os seguintes valores são possíveis:

Valor	Significado
BI_RGB	RGB descompactado.
BI_BITFIELDS	RGB descompactado com máscaras de cores. Válido para bitmaps 16-bpp e 32-bpp.

Confira Comentários para obter mais informações. Observe que BI_JPG e BI_PNG não são formatos de vídeo válidos.

Para bitmaps de 16 bpp, se biCompression for igual a BI_RGB, o formato será sempre RGB 555. Se biCompression for igual a BI_BITFIELDS, o formato será RGB 555 ou RGB 565. Use o GUID do subtipo na estrutura AM_MEDIA_TYPE para determinar o tipo RGB específico.

biSizeImage

Especifica o tamanho, em bytes, da imagem. Isso pode ser definido como 0 para bitmaps RGB descompactados.

biXPelsPerMeter

Especifica a resolução horizontal, em pixels por medidor, do dispositivo de destino para o bitmap.

biYPelsPerMeter

Especifica a resolução vertical, em pixels por medidor, do dispositivo de destino para o bitmap.

biClrUsed

Especifica o número de índices de cores na tabela de cores que são realmente usados pelo bitmap. Confira Comentários para obter mais informações.

biClrImportant

Especifica o número de índices de cores que são considerados importantes para exibir o bitmap. Se esse valor for zero, todas as cores serão importantes.

Comentários

Tabelas de cores

A estrutura BITMAPINFOHEADER pode ser seguida por uma matriz de entradas de paleta ou máscaras de cores. As regras dependem do valor de biCompression.

Se biCompression for igual a BI_RGB e o bitmap usar 8 bpp ou menos, o bitmap terá uma tabela de cores imediatamente após a estrutura BITMAPINFOHEADER . A tabela de cores consiste em uma matriz de valores RGBQUAD . O tamanho da matriz é fornecido pelo membro biClrUsed . Se biClrUsed for zero, a matriz conterá o número máximo de cores para o bitdepth especificado; ou seja, 2^cores biBitCount .
Se biCompression for igual a BI_BITFIELDS, o bitmap usará três máscaras de cores DWORD (vermelho, verde e azul, respectivamente), que especificam o layout de bytes dos pixels. Os 1 bits em cada máscara indicam os bits dessa cor dentro do pixel.
Se biCompression for um vídeo FOURCC, a presença de uma tabela de cores será implícita pelo formato de vídeo. Você não deve assumir que existe uma tabela de cores quando a profundidade do bit é de 8 bpp ou menos. No entanto, alguns componentes herdados podem assumir que uma tabela de cores está presente. Portanto, se você estiver alocando uma estrutura BITMAPINFOHEADER , é recomendável alocar espaço para uma tabela de cores quando a profundidade do bit for de 8 bpp ou menos, mesmo que a tabela de cores não seja usada.

Quando BITMAPINFOHEADER é seguido por uma tabela de cores ou um conjunto de máscaras de cores, você pode usar a estrutura BITMAPINFO para referenciar a tabela de cores das máscaras de cores. A estrutura BITMAPINFO é definida da seguinte maneira:

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

Se você converter o BITMAPINFOHEADER em um BITMAPINFO, o membro bmiHeader se referirá a BITMAPINFOHEADER e o membro bmiColors se referirá à primeira entrada na tabela de cores ou à primeira máscara de cores.

Lembre-se de que, se o bitmap usa uma tabela de cores ou máscaras de cores, o tamanho de toda a estrutura de formato ( BITMAPINFOHEADER mais as informações de cor) não é igual a sizeof(BITMAPINFOHEADER) ou sizeof(BITMAPINFO). Você deve calcular o tamanho real de cada instância.

Calculando Surface Stride

Em um bitmap descompactado, o passo a passo é o número de bytes necessários para ir do início de uma linha de pixels até o início da próxima linha. O formato de imagem define um passo mínimo para uma imagem. Além disso, o hardware gráfico pode exigir um passo maior para a superfície que contém a imagem.

Para formatos RGB descompactados, o passo mínimo é sempre a largura da imagem em bytes, arredondada para cima até o DWORD mais próximo. Para calcular o tamanho do passo e da imagem, você pode usar as macros GDI_DIBWIDTHBYTES e/ou GDI_DIBSIZE ou a seguinte fórmula:

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

Para formatos YUV, não há nenhuma regra geral para calcular o passo mínimo. Você deve entender as regras para o formato YUV específico. Para obter uma descrição dos formatos YUV mais comuns, consulte Formatos YUV recomendados de 8 bits para renderização de vídeo.

Decodificadores e fontes de vídeo devem propor formatos em que biWidth é a largura da imagem em pixels. Se o renderizador de vídeo exigir um avanço de superfície maior que o passo da imagem padrão, ele modificará o tipo de mídia proposto definindo os seguintes valores:

Ele define biWidth igual ao passo da superfície em pixels.
Ele define o membro rcTarget da estrutura VIDEOINFOHEADER ou VIDEOINFOHEADER2 igual à largura da imagem, em pixels.

Em seguida, o renderizador de vídeo propõe o formato modificado chamando IPin::QueryAccept no pino upstream. Para obter mais informações sobre esse mecanismo, consulte Alterações de formato dinâmico.

Se houver preenchimento no buffer de imagem, nunca desreferenciar um ponteiro para a memória que foi reservada para o preenchimento. Se o buffer de imagem tiver sido alocado na memória de vídeo, o preenchimento poderá não ser memória legível.