Escrevendo dados BMP obtendo lixo

Question

Estou trabalhando para entender e desenhar minha própria DLL para PDF417 (códigos de barras 2D). De qualquer forma, o desenho real do arquivo é perfeito e nos limites corretos de 32 bits (como resultado monocromático). No momento da redação dos dados, a seguir é um despejo de memória como copiado do despejo de memória do Visual Studio C ++ do ponteiro para o buffer BMP. Cada linha é alocada adequadamente para 36 de largura antes da próxima linha.

Desculpe pelo wordwrap no post, mas minha saída pretendia ser os mesmos 36 bytes de largura que o despejo de memória para que você pudesse ver melhor a distorção.

O desenho atual tem 273 pixels de largura por 12 pixels de altura, monocromático ...

00 ab a8 61 d7 18 ed 18 f7 a3 89 1c dd 70 86 f5 f7 1a 20 91 3b c9 27 e7 67 12 1c 68 ae 3c b7 3e 02 eb 00 00
00 ab a8 61 d7 18 ed 18 f7 a3 89 1c dd 70 86 f5 f7 1a 20 91 3b c9 27 e7 67 12 1c 68 ae 3c b7 3e 02 eb 00 00
00 ab a8 61 d7 18 ed 18 f7 a3 89 1c dd 70 86 f5 f7 1a 20 91 3b c9 27 e7 67 12 1c 68 ae 3c b7 3e 02 eb 00 00
00 ab 81 4b ca 07 6b 9c 11 40 9a e6 0c 76 0a fc a3 33 70 bb 30 55 87 e9 c4 10 58 d9 ea 0d 48 3e 02 eb 00 00
00 ab 81 4b ca 07 6b 9c 11 40 9a e6 0c 76 0a fc a3 33 70 bb 30 55 87 e9 c4 10 58 d9 ea 0d 48 3e 02 eb 00 00
00 ab 81 4b ca 07 6b 9c 11 40 9a e6 0c 76 0a fc a3 33 70 bb 30 55 87 e9 c4 10 58 d9 ea 0d 48 3e 02 eb 00 00
00 ab 85 7e d0 29 e8 14 f4 0a 7a 05 3c 37 ba 86 87 04 db b6 09 dc a0 62 fc d1 31 79 bc 5c 0a 8e 02 eb 00 00
00 ab 85 7e d0 29 e8 14 f4 0a 7a 05 3c 37 ba 86 87 04 db b6 09 dc a0 62 fc d1 31 79 bc 5c 0a 8e 02 eb 00 00
00 ab 85 7e d0 29 e8 14 f4 0a 7a 05 3c 37 ba 86 87 04 db b6 09 dc a0 62 fc d1 31 79 bc 5c 0a 8e 02 eb 00 00
00 ab 85 43 c5 30 e2 26 70 4a 1a f3 e4 4d ce 2a 3f 79 cd bc e6 de 73 6f 39 b7 9c db ce 6d 5f be 02 eb 00 00
00 ab 85 43 c5 30 e2 26 70 4a 1a f3 e4 4d ce 2a 3f 79 cd bc e6 de 73 6f 39 b7 9c db ce 6d 5f be 02 eb 00 00
00 ab 85 43 c5 30 e2 26 70 4a 1a f3 e4 4d ce 2a 3f 79 cd bc e6 de 73 6f 39 b7 9c db ce 6d 5f be 02 eb 00 00

Aqui está o código para escrever o arquivo - literalmente imediatamente no momento do despejo de memória de cima

FILE *stream; 
if( fopen_s( &stream, cSaveToFile, "w+" ) == 0 ) 
{ 
   fwrite( &bmfh, 1, (UINT)sizeof(BITMAPFILEHEADER), stream ); 
   fwrite( &bmi, 1, (UINT)sizeof(BITMAPINFO), stream ); 
   fwrite( &RGBWhite, 1, (UINT)sizeof(RGBQUAD), stream );
   fwrite( ppvBits, 1, (UINT)bmi.bmiHeader.biSizeImage, stream ); 
   fclose( stream ); 
}

Aqui está o que realmente é escrito no arquivo.

00 ab a8 61 d7 18 ed 18 f7 a3 89 1c dd 70 86 f5 f7 1a 20 91 3b c9 27 e7 67 12 1c 68 ae 3c b7 3e 02 eb 00 00
00 ab a8 61 d7 18 ed 18 f7 a3 89 1c dd 70 86 f5 f7 1a 20 91 3b c9 27 e7 67 12 1c 68 ae 3c b7 3e 02 eb 00 00
00 ab a8 61 d7 18 ed 18 f7 a3 89 1c dd 70 86 f5 f7 1a 20 91 3b c9 27 e7 67 12 1c 68 ae 3c b7 3e 02 eb 00 00
00 ab 81 4b ca 07 6b 9c 11 40 9a e6 0c 76 0d 0a fc a3 33 70 bb 30 55 87 e9 c4 10 58 d9 ea 0d 48 3e 02 eb 00
00 00 ab 81 4b ca 07 6b 9c 11 40 9a e6 0c 76 0d 0a fc a3 33 70 bb 30 55 87 e9 c4 10 58 d9 ea 0d 48 3e 02 eb
00 00 00 ab 81 4b ca 07 6b 9c 11 40 9a e6 0c 76 0d 0a fc a3 33 70 bb 30 55 87 e9 c4 10 58 d9 ea 0d 48 3e 02
eb 00 00 00 ab 85 7e d0 29 e8 14 f4 0d 0a 7a 05 3c 37 ba 86 87 04 db b6 09 dc a0 62 fc d1 31 79 bc 5c 0d 0a
8e 02 eb 00 00 00 ab 85 7e d0 29 e8 14 f4 0d 0a 7a 05 3c 37 ba 86 87 04 db b6 09 dc a0 62 fc d1 31 79 bc 5c
0d 0a 8e 02 eb 00 00 00 ab 85 7e d0 29 e8 14 f4 0d 0a 7a 05 3c 37 ba 86 87 04 db b6 09 dc a0 62 fc d1 31 79
bc 5c 0d 0a 8e 02 eb 00 00 00 ab 85 43 c5 30 e2 26 70 4a 1a f3 e4 4d ce 2a 3f 79 cd bc e6 de 73 6f 39 b7 9c
db ce 6d 5f be 02 eb 00 00 00 ab 85 43 c5 30 e2 26 70 4a 1a f3 e4 4d ce 2a 3f 79 cd bc e6 de 73 6f 39 b7 9c
db ce 6d 5f be 02 eb 00 00 00 ab 85 43 c5 30 e2 26 70 4a 1a f3 e4 4d ce 2a 3f 79 cd bc e6 de 73 6f 39 b7 9c
db ce 6d 5f be 02 eb 00 00

Observe o início da distorção com o "0d" no resultado da leitura do arquivo de volta na 4ª linha, sobre o 15º byte sobre ... então, há alguns mais escalonados em torno do que no total, distorce a imagem por 9 bytes que valem a pena ...

Obviamente, a parte de desenho está funcionando bem, pois tudo permanece adequadamente alinhado na memória para as 12 linhas.

Answer 1

Você não deveria abrir o arquivo em um modo composto, isto é, gravável e binário como em wb+?

Observe o início da distorção com o "0d"

Esse é o código ASCII para retorno de carruagem (CR) - adicionado em alguns sistemas operacionais com newline (onde uma nova linha é na verdade uma sequência de CR/LF). Isso deve desaparecer assim que você começar a escrever a saída no modo binário.

Seu código parece legal de outra forma. Felicidades!

Answer 2

Sua 0x0A (\n) é convertido em formato DOS 0x0D0A (\r\n), porque você está escrevendo o arquivo no modo de texto. Mudar para o modo binário.

Answer 3

Na verdade, acabei de fazer uma coisa semelhante no Java (imprimindo dados BMP em uma impressora de recibo térmica). Há algumas coisas que quero compartilhar com você:

1. Dados da imagem BMP! = Um formato de imagem da Microsoft. O MS Bitmap possui cerca de 54 bytes de informações do cabeçalho antes de qualquer dados de imagem. (passei um ou dois dias trabalhando nisso antes de perceber a diferença)

2. Os dados da imagem BMP lê de esquerda para a direita, de cima para baixo, com o bit mais significativo à esquerda.

3. Verifique se a imagem do código de barras tem uma ponta de bits de 1. Isso significa 1 bit = 1 pixel. O hexidecimal "AB" é 10101011 em binário, esses 8 pixels serão preenchidos de acordo.

4. Se você tiver um código de barras 36 bytes de largura, a resolução do código de barras é de 288 x 12, não 273 x 12. (36 * 8 = 288).

5. Os dados da imagem devem ter 432 bytes de tamanho (12 linhas de 36 bytes).

6. Eu não sei o que isso significa:

   De qualquer forma, o desenho real do arquivo é perfeito e nos limites corretos de 32 bits (como resultado monocromático).

monocromático significa sua cor ou outra. O pixel (pense bit) é preenchido ou não é.

Espero que isto ajude