Schreiben von BMP -Daten erhalten Müll

Question

Ich arbeite daran, meine eigene DLL für PDF417 (2D Barcodes) zu verstehen und zu zeichnen. Wie auch immer, die tatsächliche Zeichnung der Datei ist perfekt und in korrekten Grenzen von 32 Bit (als monochromes Ergebnis). Zum Zeitpunkt des Schreibens der Daten ist Folgendes ein Speichermagnieren, der von C ++ Visual Studio Memory Dump des Zeigers auf den BMP -Puffer kopiert wird. Jede Zeile wird vor der nächsten Reihe ordnungsgemäß 36 breit zugewiesen.

Tut mir leid wegen der Wordwrap im Beitrag, aber meine Ausgabe sollte die gleichen 36 Bytes wie der Speichermüll sein, sodass Sie die Verzerrung besser erkennen können.

Die aktuelle Zeichnung ist 273 Pixel breit und 12 Pixel hoch, monochrom ...

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

Hier ist der Code, der die Datei herausschreibt - wörtlich sofort zum Zeitpunkt des Speichers von oben

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

Hier ist, was tatsächlich in die Datei geschrieben wird.

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

Beachten Sie den Beginn der Verzerrung mit dem "0d" im Ergebnis aus dem Lesen der Datei in der 4. Zeile, etwa das 15. Byte über ... Dann sind ein paar weitere gestaffelt, die insgesamt das Bild nach verzögern können 9 Bytes wert ...

Offensichtlich funktioniert der Zeichnungsanteil in Ordnung, da alles für die 12 Zeilen im Speicher richtig ausgerichtet ist.

Answer 1

Sollten Sie die Datei nicht in einem zusammengesetzten Modus öffnen, dh beschreibbar und binär wie in wb+?

Beachten Sie den Beginn der Verzerrung mit dem "0d"

Dies ist der ASCII -Code für die Wagenrückgabe (CR) - einige Osen mit Newline (wobei eine Newline tatsächlich eine Abfolge von CR/LF ist). Dies sollte verschwinden, sobald Sie mit dem Schreiben der Ausgabe im Binärmodus beginnen.

Ihr Code sieht ansonsten ordentlich aus. Prost!

Answer 2

Dein 0x0A (\n) wird in das DOS -Format umgewandelt 0x0D0A (\r\n), weil Sie die Datei im Textmodus schreiben. Wechseln Sie in den Binärmodus.

Answer 3

Ich habe eigentlich nur etwas Ähnliches in Java gemacht (Drucken von BMP -Daten in einen thermischen Quittungsdrucker). Es gibt ein paar Dinge, die ich mit Ihnen teilen möchte:

1. BMP -Bilddaten! = Ein Bildformat von Microsoft. Die MS Bitmap enthält etwa 54 Bytes Header -Informationen vor den Bilddaten. (Ich habe ein oder zwei Tage daran gearbeitet, bevor ich den Unterschied erkannte)

2. BMP -Bilddaten liest links nach rechts, von oben nach unten, mit dem bedeutendsten Bit links.

3. Stellen Sie sicher, dass das Barcode -Bild eine Bitde von 1 hat. Dies bedeutet 1 Bit = 1 Pixel. Hexidezimal "AB" ist 10101011 in binär, diese 8 Pixel werden entsprechend ausgefüllt.

4. Wenn Sie einen Barcode 36 -Bytes breit haben, beträgt die Barcode -Auflösung 288 x 12, nicht 273 x 12. (36 * 8 = 288).

5. Die Bilddaten sollten 432 Bytes betragen (12 Zeilen von 36 Bytes).

6. Ich weiß nicht, was das bedeutet:

   Wie auch immer, die tatsächliche Zeichnung der Datei ist perfekt und in korrekten Grenzen von 32 Bit (als monochromes Ergebnis).

Monochrom bedeutet entweder 1 Farbe oder eine andere. Das Pixel (denken) ist entweder ausgefüllt oder es ist nicht.

Hoffe das hilft