Запись данных BMP, получение мусора

Question

Я работаю над тем, чтобы понять и нарисовать свою собственную DLL для PDF417 (2d штрих-коды). Во всяком случае, фактическое рисование файла идеально и в правильных границах 32 бит (как монохромный результат). Во время записи данных ниже приведен дамп памяти, скопированный из дамп памяти C ++ Visual Studio указателя на буфер bmp. Каждый ряд правильно распределен по 36 в ширину перед следующим рядом.

Извините за перенос слов в этом посте, но мои выходные данные должны были быть такими же, как 36 байтов шириной с дампом памяти, чтобы вы могли лучше видеть искажения.

Текущий чертеж имеет ширину 273 пикселя и высоту 12 пикселей, монохромный ...

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

Вот код для ЗАПИСИ файла - дословно сразу во время дампа памяти сверху

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

Вот что на самом деле записывается в файл.

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

Обратите внимание на начало искажения с помощью " 0d " в результате чтения файла обратно в 4-й строке, примерно на 15-м байте больше ... Затем, есть еще несколько ступеней, которые в итоге искажают изображение на 9 байт ...

Очевидно, часть рисунка работает нормально, так как все остается правильно выровненным в памяти для 12 строк.

Answer 1

Разве вы не должны открывать файл в сложном режиме, т.е. бинарный как в wb + ?

  

Обратите внимание на начало искажения с помощью " 0d "

Это код ASCII для возврата каретки (CR) - добавлен в некоторых ОС с символом новой строки (где символ новой строки на самом деле является последовательностью CR / LF). Это должно исчезнуть, как только вы начнете записывать вывод в двоичном режиме.

В противном случае ваш код выглядит аккуратно. Ура!

Answer 2

Ваш 0x0A ( \ n ) преобразуется в формат DOS 0x0D0A ( \ r \ n ), потому что вы пишете файл в текстовом режиме. Переключитесь в двоичный режим.

Answer 3

Я на самом деле только что сделал подобное в java (печать данных bmp на термопринтер). Я хочу поделиться с вами несколькими вещами:

<Ол>

bmp image data! = формат изображения от Microsoft. битовая карта MS содержит около 54 байтов информации заголовка перед любыми данными изображения. (я потратил день или два, работая над этим, прежде чем понял разницу)

bmp данные изображения читаются слева направо, сверху вниз, самый старший бит слева.

убедитесь, что изображение штрих-кода имеет битовую глубину 1. Это означает, что 1 бит = 1 пиксель. шестнадцатеричный "ab"; равно 10101011 в двоичном виде, эти 8 пикселей будут заполнены соответственно.

если у вас есть штрих-код шириной 36 байт, разрешение штрих-кода составляет 288 x 12, а не 273 x 12. (36 * 8 = 288).

данные изображения должны иметь размер 432 байта (12 строк по 36 байтов).

Я не знаю, что это значит:

  

Как бы то ни было, фактическое рисование файла идеально и в правильных границах 32 бита (как монохромный результат).

монохромный означает либо один цвет, либо другой. пиксель (думаю, бит) либо заполнен, либо нет.

Надеюсь, это поможет