DIBs e respectiva utiliza

Segue-se o texto do artigo "DIBs e respectivos utiliza". Este artigo está disponível no formato de ficheiro Ajuda do Windows na biblioteca de software da Microsoft em conjunto com o texto apresentado abaixo.

Os ficheiros seguintes estão disponíveis para transferência a partir do Centro de transferências da Microsoft:


Dibs2.exe (http://download.microsoft.com/download/platformsdk/article/3.1/w31/en-us/dibs2.exe)
Para obter informações adicionais sobre como transferir ficheiros de suporte da Microsoft, clique no número de artigo que se segue para visualizar o artigo na Microsoft Knowledge Base: Microsoft procedeu de vírus neste ficheiro. Microsoft utilizou o mais recente software de detecção de vírus que estava disponível na data em que o ficheiro foi publicado. O ficheiro é alojado em servidores com segurança avançada que o ajudam a impedir alterações não autorizadas ao ficheiro. Este artigo descreve o conceito de (device-independent bitmap) DIB de definição e estrutura para a API que o utiliza. Incluídos é uma aplicação exemplo pequeno que ilustra alguns dos métodos mais comuns de utilizar DIBs para apresentar e manipular imagens digitais. Funções discutidas são GetDIBits() , SetDIBits() , CreateDIBitmap() , SetDIBitsToDevice() , StretchDIBits() e CreateDIBPatternBrush() . Este artigo não aborda com paletas DIBs.

DESCRIÇÃO GERAL

Um device-independent bitmap (DIB) é um formato utilizado para definir mapas de bits independente do dispositivo de várias resoluções de cor. O objectivo principal DIBs é permita mapas de bits a ser movida de um dispositivo para outro (por conseguinte, a parte independente do dispositivo do nome). Um DIB é um formato externo, por oposição a um mapa de bits dependentes do dispositivo, que aparece no sistema como um objecto de mapa de bits (criado por uma aplicação utilizando CreateBitmap() , CreateCompatibleBitmap() , CreateBitmapIndirect() ou CreateDIBitmap() ). Um DIB normalmente é transportado em metaficheiros (normalmente utilizando a função StretchDIBits() ), ficheiros BMP e a área de transferência (formato de dados CF_DIB).

Um DIB constituída por duas partes: os bits próprios e um cabeçalho que descreve o formato dos bits. O cabeçalho contém o formato de cor, uma tabela de cores e o tamanho do mapa de bits. O formato DIB actual suporta quatro resoluções de cor: 1 bit, 4 bits, 8 bits e 24 bits. Em DIBs de 1 bit 4-bit e 8 bits, os pixels são definidos pelos índices (da solução de bit adequado) na tabela de cores; 24 bits pixels são descritos como valores de 24 bits, de 1 byte cada de vermelho, verde e azul. As funções DIB são:

INDEPENDÊNCIA DO DISPOSITIVO - HÁ É BOM PARA?

Não foi possível em versões do Microsoft Windows gráfica ambiente anterior à 3.0 transferência os mapas de bits a cores de um dispositivo para outro. Com DIBs, cada dispositivo apresenta a imagem para a extensão da respectiva resolução de cor. Uma aplicação pode armazenar uma imagem no formato DIB e, em seguida, apresentá-lo, independentemente do dispositivo de saída; uma aplicação já não necessita de criar uma versão de cada imagem para cada tipo de dispositivo.

Esta capacidade de transferência de imagem pode ser utilizada para imprimir imagens de meio-tom. Por exemplo, a função StretchDIBits() pode passar um DIB directamente para um controlador de impressora inteligente. Tendo em conta as informações de cores da imagem em vez de apenas uma versão Monocromática (o método tradicional), o controlador pode utilizar meios para imprimir uma imagem realista.

Uma vez que o formato DIB publicamente estiver definido, uma aplicação pode manipulá-lo ao compor uma mensagem. De facto, uma aplicação pode criar uma imagem sem qualquer interacção com o Windows. Se o Windows não possui um desenho primitivo, a aplicação pode simulá-lo directamente DIB em vez de utilizar os primitivos de interface (GDI) de dispositivo de gráficos existente. Infelizmente, no Windows versões 3.0 e 3.1, não pode efectuar operações de saída directamente para um DIB GDI.

FORMATOS DE FICHEIROS BMP

A extensão do ficheiro de um ficheiro DIB do Windows é BMP. O ficheiro é constituída por uma estrutura BITMAPFILEHEADER seguida DIB propriamente dito. Infelizmente, porque a estrutura BITMAPFILEHEADER realmente nunca é transmitida para a API, nem todas as aplicações que gera ficheiros BMP preenche a estrutura de dados com cuidado. Para adicionar esta confusão, a definição "adequada" da estrutura está no odds com a documentação. Correctamente, a estrutura de dados contém os seguintes campos: DIB O cabeçalho imediatamente a seguir a estrutura BITMAPFILEHEADER .

Para obter um exemplo de código que lê o ficheiro BMP, consulte o programa de exemplo.

O cabeçalho DIB

O cabeçalho, na realidade, constituída por duas adjacentes partes: o cabeçalho adequado e a tabela de cores. Ambos são combinados na estrutura de BITMAPINFO , que é que todas as APIs de DIB esperado.

Windows versão 3.0 suporta dois variedades de cabeçalhos: BITMAPINFOHEADER e BITMAPCOREHEADER. Se possível, as aplicações devem utilizar apenas BITMAPINFOHEADERs. A definição BITMAPCOREHEADER baseia-se a definição de mapa de bits a partir da versão 1.1 do Gestor de apresentação e é suportada para compatibilidade.

Durante uma operação de definição de DIB, a maior parte dos campos são já preenchidos por quem gerado o DIB. No entanto, fazer uma chamada de GetDIBits() fornece maior controlo. A forma como o cabeçalho é preenchido para esta operação define o DIB resultante, particularmente a resolução de cor.

BITMAPINFOHEADER contém os seguintes campos: a tabela de cores imediatamente a seguir as informações do cabeçalho. Nenhuma tabela de cores está definida para DIBs de 24 bits. A tabela constituída por uma matriz de estruturas de dados RGBQUAD. (O índice para o formato BITMAPCOREINFO é criado com a estrutura de dados RGBTRIPLE .) Bytes de vermelhos, verdes e azuis estão na ordem inversa (posição swaps vermelho com azul) a partir da convenção de Windows. Este é outro leftover de compatibilidade do Gestor de apresentação.

O tamanho da tabela de cores depende do valor de biBitCount (e podem ser substituídas utilizando o campo biClrUsed ; consulte acima): mais DIBs flutuante actualmente ter biClrUsed definido como 0, mas se qualquer DIB full-fledged bashing é planeado, é uma boa ideia definidos correctamente. Se biClrUsed é diferente de zero, é possível que uma tabela de cores com DIBs de 24 bits. GDI não utiliza esta tabela de cores, mas a aplicação pode utilizá-lo para determinar as importantes cores utilizadas no DIB.

Todas as funções DIB incluem um parâmetro wUsage, que pode afectar a definição da tabela de cores. Este artigo evita utilizar paletas com DIBs e assume assim que wUsage é sempre definido como DIB_RGB_COLORS e que a tabela de cores, por isso, é sempre composta por valores RGB. Quando DIB_PAL_COLORS é utilizado, a tabela de cores constituída por valores WORD índices para a paleta lógico actualmente seleccionado. (Este tópico é abordado detalhadamente no artigo "Utilizar DIBs com paletas").

Formatos de transmissão

O cabeçalho define o formato do bits, mas todos os formatos de partilham as seguintes regras:

• Cada scanline é alinhado em DWORD. O scanline é armazenada em buffer para alinhamento; a memória intermédia não é necessariamente 0.
• Os scanlines são armazenadas de cabeça para baixo, com a análise primeira (análise 0) na memória a ser a digitalização bottommost na imagem. (Consulte a figura 1). Este é outro artefactos de compatibilidade do Gestor de apresentação. GDI automaticamente Inverte a imagem durante as operações de definir e obter. Figura 1. (Imagem incorporada com representações de memória e o ecrã.)
• 64 K segmento limites não são respeitados; scanlines podem atravessar esses limites (ao contrário, o formato de mapa de bits dependentes do dispositivo que está armazenada em buffer para limites de 64 K).

Cada formato tem as seguintes especificações:

• 1 bit DIBs são armazenadas com cada bit como um índice para a tabela de cores. O bit mais significativo é o pixel mais à esquerda.

DIBs de 4 bits são armazenadas com cada 4 bits que representa um índice na tabela de cores. Nibble mais significativo é o pixel mais à esquerda.

• DIBs de 8 bits são mais fáceis armazenar uma vez que cada byte é um índice.
• DIBs de 24 bits tem todas as 3 bytes que representa uma cor, utilizando o mesmo ordering como a tabela de cores. Este formato é particularmente difícil durante processamento porque pode existir um limite de 64 K no meio de uma cor Tripla--uma condição difícil que tem de ser tratada com cuidado.

UTILIZAR A API DE DIB

GetDIBits() e SetDIBits()

Estas duas funções são utilizadas para converter device-independent mapas de bits em mapas de bits dependentes do dispositivo e vice-versa. SetDIBits() converte um DIB um mapa de bits dependentes do dispositivo e GetDIBits() gera um DIB a partir de um mapa de bits dependentes do dispositivo.

O controlador de dispositivo referenciado por hDC transmitido para ambas as chamadas efectua a conversão real. Alguns controladores de dispositivo poderão não ter esta funcionalidade (por exemplo, um controlador de versão 2.0 do Windows ou um controlador de versão 3.0 do Windows primitivo). Neste caso, GDI simula a conversão mas apenas em monocromático--cor informações são convertidas para preto e branco. Na maior parte dos casos, no entanto, este não é uma preocupação. Todos os controladores de visualização self-respecting suportam esta funcionalidade e apenas alguns controladores de impressora não fornecem a conversão, normalmente monocromáticos controladores para o qual suffice simulações GDI.

GetDeviceCaps(hDC, RASTERCAPS) devolve um valor WORD com sinalizadores definidos indicando que DIB funciona o controlador suporta. RC_DI_BITMAP indica suporte GetDIBits() e SetDIBits() , RC_DIBTODEV indica o suporte de SetDIBitsToDevice() e RC_STRETCHDIB indica o suporte de StretchDIBits() . Pode ser simulada qualquer função não suportada, apesar das simulações frequentemente não serem tão útil como o item real (principalmente como perdem informações a cores). Um dispositivo poderá não conseguir suportar a funcionalidade completa, mesmo se estiver definido um pouco. Por exemplo, um dispositivo pode suportar StretchDIBits mas apenas para stretches integrais. Infelizmente, uma aplicação não tem maneira para determinar a integridade da implementação. Nestes casos, a GDI simula a função.

Os parâmetros são os mesmos para tanto GetDIBits() SetDIBits() : utilizar SetDIBits() é razoavelmente simples. Um DIB é retirado do local (por exemplo, a partir da área de transferência ou de um ficheiro de disco) e é convertido para um objecto mapa de bits, que, em seguida, pode ser seleccionado para um DC e blted no ecrã para serem apresentados. Esta é a forma mais simples para apresentar um DIB.

Nota Para muitos impressoras que podem fazer os meios tons, este método não é preferencial; StretchDIBits (discutido no seguinte) é muito mais útil.

Segue-se uma apresentação simples de um DIB a um DC (com não processamento de erros): utilizar GetDIBits() é mais complexo uma vez que a aplicação pode escolher o tipo de DIB para gerar. O tamanho do mapa de bits origem regula dimensões o DIB (um elemento pode ser extraído por blting para um mapa de bits pequeno), mas a aplicação necessita pode ditar a resolução de cor.

Para GetDIBits() funcione correctamente, a aplicação tem de definir os seguintes campos no cabeçalho: também, o espaço alocado para a tabela de cores tem de ser suficiente para conter uma tabela inteira: o espaço alocado para lpBits também tem de ser suficientemente grande para conter nNumScans de dados. A chamada preenche os seguintes campos da estrutura:

• biSizeImage = tamanho em bytes dos dados DIB
• Tabela de cores (de caso de não-24 bits) está preenchida com cores apropriadas
• lpBits é preenchido com os dados DIB

Se GetDIBits() é chamado com lpBits definido como NULL, não bits são devolvidos; apenas biSizeImage e a tabela de cores são preenchidos. Esta opção é útil para DIBs com RLE, não sendo compensador para DIBs não codificado.

Objectivos da aplicação para o DIB determinam que resolução de cores para escolher. A abordagem normal é gerar um DIB preserva as informações de cores do mapa de bits origem dependentes do dispositivo. Escolher um resulta de resolução inferior numa perda de informações de cores, que é normalmente indesejável. Utilizar sempre 24 bits resolução é desnecessária, no entanto, porque ao fazê-lo, adiciona uma resolução de cor mais se a origem tem 8 bits ou menos resolução. cálculo de resolução do mapa de bits tem de tomar em consideração que alguns mapas de bits dependentes do dispositivo estão planar (nomeadamente EGA e VGA). DIBs, por outro lado, são sempre "compactados pixel," com apenas 1 plano por pixel (biPlanes = 1).

Os parâmetros nStartScan e nNumScans (residue de compatibilidade do Gestor de apresentação) foram concebidos para ser utilizado para representação por bandas. Se não está disponível para carregar DIB inteira na memória de uma peça memória suficiente, lpBits podem ser efectuadas para apontar para apenas uma parte dos bits. Considere o seguinte exemplo: definir o código demora a faixa especificada, converte-lo e coloca a banda convertida na localização correcta, gestão de contas em todas as horas para a cabeça - premida natureza DIBs. Repare como biHeight não alterar a qualquer momento uma vez que a banda é colocada no mapa de bits com base na altura de mapa de bits completo. nStart baseia-se a altura da imagem completa (definida por biHeight).

CreateDIBitmap()

O seguinte código demonstra chamada CreateDIBitmap() com as maiúsculas e minúsculas habitual: isto é equivalente a: implementação do GDI ignora a parte SetDIBits() se o terceiro parâmetro não estiver definido com o sinalizador CBM_INIT. Faz com que esta função para atalho bonito codificação da conversão de DIB mapa de bits dependentes do dispositivo.

SetDIBitsToDevice()

SetDIBitsToDevice() permite que uma aplicação definir um DIB directamente para uma superfície de dispositivo. Uma vez que esta função é um holdout de desenvolvimento inicial, a interface não está como refinado é possível. StretchDIBits() é uma função muito mais poderosa do que SetDIBitsToDevice() . StretchDIBits() faz tudo que SetDIBitsToDevice() e tem uma interface nicer. SetDIBitsToDevice() é limitado na forma como este processa metaficheiros porque que não escala e de representação por bandas com os parâmetros nStartScan e nNumScans é nontrivial na melhor. StretchDIBits() não irá permitir a representação por bandas.

O seguinte código executa a funcionalidade SetDIBitsToDevice() o mapa de full bits (não faixas) utilizando StretchDIBits: partindo do princípio que nStartScan estiver definido como 0 e esse nNumScans estiver definido como lpInfo-> biHeight (isto é, sem faixas), a função é basicamente uma BitBlt com SRCCOPY como o ROP e com um DIB como a origem. SrcX SrcY no espaço de DIB e estão, por isso, cabeça para baixo em relação ao DC (Y = 0 é na parte inferior da imagem).

DIB lidar com a cabeça para baixo é complicado quando efectuar uma definição parcial. Por exemplo, se uma aplicação pretende obter o inferior terceiro de um DIB é w por pixels h para o dispositivo em (x, y), a chamada deverá assemelhar-se a seguinte: um mapa de bits dependentes do dispositivo teria um SrcY de 2 h/3 para o fim em terceiro lugar, mas com a cabeça - para baixo de sistema de DIB, um SrcY de h/3 pontos para o local certo relativamente ao Windows coordenadas.

StretchDIBits()

Esta função é darling fazer tudo para apresentar um DIB na superfície de um dispositivo. É especialmente útil para metafiling e para imprimir, para o qual a capacidade de esticar é importante.

É o uma orifício crítico na implementação do actual StretchDIBits() StretchDIBits() é suportada por controladores de impressora e não por muitos controladores de visualização. Deste modo, usar esta função repetidamente para esticar um DIB ao ecrã é significativamente mais lento que utilizar SetDIBits (para obter um mapa de bits dependentes do dispositivo) seguido de chamadas StretchBlt() repetidas.

A implementação desta função no GDI é muito simples. Se o controlador de dispositivo pode processar a chamada propriamente dito, não. Caso contrário e a chamada é 1 para 1 e o dispositivo suporta SetDIBitsToDevice() , a chamada é convertida para uma chamada SetDIBitsToDevice() ao controlador. (Isto funciona apenas com SRCCOPY como o ROP.) Se nenhum destes métodos possível, CreateDIBitmap() é utilizado para criar uma versão dependentes do dispositivo do mapa de bits e StretchBlt denomina-se para efectuar o trabalho real.

Os parâmetros para StretchDIBits() basicamente são a mesma que para StretchBlt() (com a origem hDC substituído por lpBits e lpInfo). Esta função não tem o nStartScan e os parâmetros nNumScans das outras funções DIB, lpBits sempre aponta para a digitalização do DIB primeira.

Quando utilizar esta função para algo diferente stretches de mapa de bits completo, lembre-se todas as coordenadas de origem (os relacionados com o DIB) estão num sistema de cabeça para baixo. A função adequadamente irá inverter a imagem, mas o rectângulo de origem for definido com Y = 0 na parte inferior e extensões vai. Felizmente, as coordenadas x utilizam as mesmas convenções como Windows.

Controladores de impressora que suportam esta funcionalidade (por exemplo, PSCRIPT e HPPCL) normalmente utilizam um algoritmo de meio-tom para exportar imagens a cores boa. Assim, manter DIBs na resolução de cor significativa máxima possível (normalmente, 8 bits) é desejável mesmo se o dispositivo de saída for monocromática, uma vez que continua útil para saída boa as informações da cor. Infelizmente, a maior parte dos controladores de impressora não suportam qualquer ROP diferente SRCCOPY.

CreateDIBPatternBrush()

Esta função permite que uma aplicação para criar um Pincel de padrão, especificando um DIB em vez de um mapa de bits dependentes do dispositivo, como utilizados na função CreatePatternBrush() . Um pincel criado utilizando esta função é utilizado semelhante a quaisquer outro Pincel. O DIB está activado para um mapa de bits dependentes do dispositivo momento SelectObject() para utilização pelo dispositivo. Este Pincel é semelhante a um Pincel de padrão padrão para o dispositivo.

DIBS NA ÁREA DE TRANSFERÊNCIA

Dois mecanismos base para efectuar DIBs na área de transferência estiverem a utilizar o formato de dados CF_DIB ou colocando o DIB num metaficheiro e utilizando o formato de dados CF_METAFILEPICT.

O formato CF_DIB utiliza um DIB compactada, siga os bits imediatamente após o cabeçalho e a tabela de cores. Ao ler ou criar um DIB compactada, uma aplicação tem de calcular correctamente o tamanho da tabela cor para garantir que os bits no local correcto. Uma vez que todas as funções DIB esperam o DIB como dois ponteiros, uma para o cabeçalho e outra para os bits, o ponteiro de bits tem ser calculado antes do utilizar. (Para cálculos de tamanho da tabela de cores, consulte o exemplo de código na descrição da tabela de cores acima.)

A forma mais simples para colocar um DIB para um metaficheiro é utilizar StretchDIBits() : esta abordagem gera um metaficheiro que, quando reproduzir apresenta DIB para o destino. Este método também dimensiona a imagem para ajustar o esquema de mapeamento actual se for necessário. Utilizar metaficheiros para transferência permite que mesmo as aplicações que não sejam DIB compatível para colar o conteúdo da área de transferência sem perder as informações de DIB.

FORMATOS DE RLE

Quando o campo biCompression no cabeçalho de um DIB está definido como qualquer BI_RLE4 (para biBitCount = 4) ou BI_RLE8 (para biBitCount = 8), a imagem foi codificado run-length. É possível encontrar uma descrição dos esquemas de codificação no "Microsoft Windows Software Development Kit referência volume 2," na secção "BITMAPINFOHEADER" "tipos de dados e estruturas de" capítulo. O esquema básico envolve comprimir várias horizontalmente adjacentes, idênticos pixels para uma execução codificação. Por exemplo, 10 pixels de cor índice 17 codificados como uma execução do comprimento 10 e do índice 17. Códigos de fim de digitalização e delta move-se também forem fornecidos, na qual um X e um desvio Y são fornecidos para o pixel seguinte.

Este tipo de codificação normalmente comprime o mapa de bits e também é útil para criar animações de tipo sprite, no qual apenas uma pequena parte de uma imagem altera em cada frame. As capacidades de animação são efectuadas utilizando códigos de delta para limitar o número de pixels, na realidade, ser definido. Ignorado por uma delta de mover os pixels são esquerda inalterados.

As limitações da RLE DIBs principais são que uma aplicação pode facilmente determinar o tamanho do mapa de bits em bytes nem aponte para um determinado scanline sem descodificar o mapa de bits da verificação primeiro. O campo biSizeImage é útil para resolver o problema primeiro. Descodificar, codificação e geralmente manipular o RLE formato é mais lento e mais complicado do que o formato (BI_RGB) noncompressed. Algumas aplicações--por exemplo, Paintbrush--recusarem RLE DIBs de leitura. Apesar de todas as APIs aceitá-las, RLE DIBs provavelmente será um formato suportado universalmente. Além disso, devido a rarity relativo destes formatos, alguns controladores de dispositivo poderão não totalmente testado suporte para os processos de codificação e descodificação.

Para gerar um DIB RLE, GetDIBits() é chamado com biCompression definido para o tipo de codificação pretendido. A quantidade de memória necessária para armazenar os bits não é calculada facilmente. Se GetDIBits() é chamado com lpBits definido como NULL, a quantidade de memória necessária para os bits é devolvida nos biSizeImage. Uma chamada subsequente com lpBits apontando para um bloco de memória correctamente tamanho devolve um mapa de bits codificado.

Converter um DIB RLE num formulário dependentes do dispositivo requer sem um processamento especial. Algumas das funções conjunto podem ser utilizadas normalmente com um cabeçalho que contém os biSizeImage adequado e biCompression valores para fazer corresponder os bits.

FALHAS DE DIBS

Provavelmente, o limite maior de DIBs é que são mais lentos que os mapas de bits dependentes do dispositivo. Converter DIBs num formulário dependentes do dispositivo antes de que, na realidade, podem ser apresentados requer processamento extra, resultando numa sobrecarga adicional. Um mundo ideal, StretchDIBits() um 1 para 1 seria tão rápida como uma BitBlt() . Esta velocidade permitiria que uma aplicação funcione com eficácia no realm de mapa de bits lógico, com cores e o acesso total a cada pixel, independentemente das limitações do dispositivo físico.

DIBs são baseadas num sistema de coordenadas é invertido relativo ao Windows, tornando a codificação um pouco frustrante e não intuitiva. Lembrar sempre este quirkiness deverá ajudar limite o número de iterações necessário para obter os mapas de bits correctamente alinhados.

Pode obter cores utilizando DIBs de 24 bits, mas são muito lentos descodificar, ler e escrever. Isto é particularmente verdade em dispositivos de paleta de 8 bits, na qual tradução literalmente pode demorar minutos. Além disso, o tamanho vasto de DIBs de 24 bits torna um pouco unwieldy para utilização geral.

PROBLEMAS RELACIONADOS COM O DIB IN WINDOWS VERSÃO 3.0

Gravação de metaficheiro de chamadas de StretchDIBits() utilizar BITMAPCOREHEADER faz com que um EAU. Converta todos os cabeçalhos para o estilo BITMAPINFO para evitar este problema. Esta solução alternativa é recomendada para DIB geral de processamento.

O código de simulação SetDIBits() para maior do que 64 K monocromático DIBs provoca falhas ou impressões erradas quando utiliza um SetDIBits() , um SetDIBitsToDevice() ou um StretchDIBits() para um controlador que não suporta SetDIBits() .

Direitos de autor 1992 pela Microsoft Corporation. Todos os direitos reservados.