DIBs Top-Down vs. Bottom-Up
[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.]
Se você não estiver familiarizado com a programação gráfica, talvez espere que um bitmap seja organizado na memória para que a linha superior da imagem apareça no início do buffer, seguida pela próxima linha e assim por diante. No entanto, esse não é necessariamente o caso. No Windows, os DIBs (bitmaps independentes de dispositivo) podem ser colocados na memória em duas orientações diferentes, de baixo para cima e de cima para baixo.
Em um DIB de baixo para cima, o buffer de imagem começa com a linha inferior de pixels, seguida pela próxima linha para cima e assim por diante. A linha superior da imagem é a última linha no buffer. Portanto, o primeiro byte na memória é o pixel inferior esquerdo da imagem. Na GDI, todos os DIBs são de baixo para cima. O diagrama a seguir mostra o layout físico de um DIB de baixo para cima.
Em um DIB de cima para baixo, a ordem das linhas é invertida. A linha superior da imagem é a primeira linha na memória, seguida pela próxima linha para baixo. A linha inferior da imagem é a última linha no buffer. Com um DIB de cima para baixo, o primeiro byte na memória é o pixel superior esquerdo da imagem. O DirectDraw usa DIBs de cima para baixo. O diagrama a seguir mostra o layout físico de um DIB de cima para baixo:
Para DIBs RGB, a orientação da imagem é indicada pelo membro biHeight da estrutura BITMAPINFOHEADER . Se biHeight for positivo, a imagem será de baixo para cima. Se biHeight for negativo, a imagem será de cima para baixo.
DiBs em formatos YUV são sempre de cima para baixo e o sinal do membro biHeight é ignorado. Os decodificadores devem oferecer formatos YUV com biHeight positivo, mas também devem aceitar formatos YUV com biHeight negativo e ignorar o sinal.
Além disso, qualquer tipo DIB que use um FOURCC no membro biCompression deve expressar seu biHeight como um número positivo, independentemente de sua orientação, já que o próprio FOURCC identifica um esquema de compactação cuja orientação de imagem deve ser compreendida por qualquer filtro compatível.
Tópicos relacionados