Scrittura dei dati BMP che ottengono immondizia

Question

Sto lavorando per comprendere e disegnare la mia DLL per PDF417 (codici a barre 2D). Ad ogni modo, il disegno effettivo del file è perfetto e con limiti corretti di 32 bit (come risultato monocromatico). Al momento della scrittura dei dati, il seguente è un dump della memoria copiato dal dump della memoria di Visual Studio C ++ del puntatore al buffer bmp. Ogni riga è correttamente allocata a 36 di larghezza prima della riga successiva.

Mi dispiace per il wordwrap nel post, ma il mio output doveva avere la stessa larghezza di 36 byte del dump della memoria in modo da poter vedere meglio la distorsione.

Il disegno corrente ha una larghezza di 273 pixel e un'altezza di 12 pixel, monocromatico ...

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

Ecco il codice per SCRIVERE il file, alla lettera immediatamente al momento del dump della memoria dall'alto

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 ); 
}

Ecco cosa ATTUALMENTE viene scritto nel file.

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

Notare l'inizio della distorsione con "0d" nel risultato dalla lettura del file nella quarta riga, circa il 15 byte sopra ... Quindi, ci sono alcuni altri sfalsati attorno ai quali, in totale, distorce l'immagine di 9 byte del valore ...

Ovviamente, la parte del disegno funziona bene poiché tutto rimane correttamente allineato in memoria per le 12 linee.

Answer 1

Non dovresti aprire il file in una modalità composta, cioè scrivibile & amp; binario come in wb + ?

  

Nota l'inizio della distorsione con " 0d "

Questo è il codice ASCII per Carriage Return (CR) - aggiunto su alcuni SO con newline (dove una newline è in realtà una sequenza di CR / LF). Questo dovrebbe scomparire una volta che inizi a scrivere l'output in modalità binaria.

Il tuo codice sembra pulito altrimenti. Cheers!

Answer 2

Il tuo 0x0A ( \ n ) viene convertito nel formato DOS 0x0D0A ( \ r \ n ), perché stai scrivendo il file in modalità testo. Passa alla modalità binaria.

Answer 3

In realtà ho appena fatto una cosa simile in Java (stampa dei dati bmp su una stampante termica per scontrini). Ci sono un paio di cose che voglio condividere con te:

1. dati immagine bmp! = un formato immagine di microsoft. la bitmap MS ha circa 54 byte di informazioni di intestazione prima di qualsiasi dato di immagine. (ho passato un giorno o due a lavorarci su prima di rendermi conto della differenza)

2. i dati delle immagini bmp vengono letti da sinistra a destra, dall'alto verso il basso, con il bit più significativo a sinistra.

3. assicurati che l'immagine del codice a barre abbia una profondità di bit di 1. questo significa 1 bit = 1 pixel. esadecimale "ab" è 10101011 in binario, questi 8 pixel verranno riempiti di conseguenza.

4. se si dispone di un codice a barre largo 36 byte, la risoluzione del codice a barre è 288 x 12, non 273 x 12. (36 * 8 = 288).

5. i dati dell'immagine devono avere una dimensione di 432 byte (12 righe di 36 byte).

6. Non so cosa significhi:

     

   Ad ogni modo, il disegno reale del file è perfetto e con i limiti corretti di 32 bit (come risultato monocromatico).

monocromatico indica 1 colore o un altro. il pixel (pensa al bit) è riempito o non lo è.

Spero che questo aiuti