Schreiben von BMP-Daten, die Müll bekommen

Question

Ich arbeite daran, meine eigene DLL für PDF417 (2D-Barcodes) zu verstehen und zu zeichnen. Jedenfalls ist das tatsächliche Zeichnen der Datei perfekt und in korrekten Grenzen von 32 Bits (als monochromes Ergebnis). Zum Zeitpunkt des Schreibens der Daten ist das Folgende ein Speicherauszug, wie er aus dem C++ Visual Studio-Speicherauszug des Zeigers in den bmp-Puffer kopiert wurde. Jede Zeile wird vor der nächsten Zeile 36 Wide zugewiesen.

Sorry über die Wordwrap in der Post, aber meine Ausgabe sollte die gleichen 36 Bytes breit wie der Speicherabzug sein, so dass Sie die Verzerrung besser sehen können.

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

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 die Datei zu schreiben - wörtlich unmittelbar zum Zeitpunkt des Speicherabbild 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 ACTUELL 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 

Hinweis der Beginn der Verzerrung mit dem „0T“ im Ergebnis aus der Datei zurück in der 4. Zeile zu lesen, über das 15. Byte über ... Dann gibt es noch ein paar gestaffelt, um die sich in insgesamt, schiebe das Bild um 9 Bytes wert ...

Offensichtlich funktioniert die Zeichnung Teil in Ordnung, da alles richtig im Speicher für die 12 Zeilen ausgerichtet bleibt.

Answer 1

Sollten Sie die Datei nicht in einem zusammengesetzten Modus öffnen, d. H. Schreibbar & binär wie in wb+?

Hinweis der Beginn der Verzerrung mit dem „0T“

Das ASCII-Code ist für Carriage Return (CR) - bei einigen Betriebssystemen mit Newline hinzugefügt (wo ein Newline tatsächlich eine Folge von CR/LF). Dies sollte verschwinden, sobald Sie mit dem Schreiben der Ausgabe im Binärmodus beginnen.

Ihr Code sieht ansonsten gut aus. Prost!

Answer 2

Ihre 0x0A (\n) zu DOS-Format konvertiert wird 0x0D0A (\r\n), becouse Sie die Datei im Textmodus sind schreiben. Wechseln Sie in den Binärmodus.

Answer 3

Ich habe gerade eine ähnliche Sache in Java (Drucken von BMP-Daten auf einen Thermo-Belegdrucker). Es gibt ein paar Dinge, die ich mit Ihnen teilen möchte:

1. bmp image data! = Ein Bildformat von Microsoft. die MS-Bitmap hat etwa 54 Bytes Kopfinformation vor irgendwelchen Bilddaten. (Ich verbrachte einen oder zwei Tage damit, bevor ich den Unterschied erkannte)

2. bmp Bilddaten liest von links nach rechts, von oben nach unten, mit dem wichtigsten Bit auf der linken Seite.

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

4. Wenn Sie einen Barcode mit 36 ​​Byte Breite haben, ist die Barcode-Auflösung 288 x 12, nicht 273 x 12. (36 * 8 = 288).

5. Die Bilddaten sollten 432 Bytes groß sein (12 Zeilen mit 36 ​​Bytes).

6. ich weiß nicht, was das bedeutet:

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

monochrome bedeutet, seine Farbe entweder 1 oder ein anderes. Das Pixel (Think Bit) ist entweder ausgefüllt oder es ist nicht.

Hoffe, das hilft