Запись данных BMP, получение мусора - PullRequest
Новая
       32

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

4 голосов
/ 04 марта 2009

Я работаю над пониманием и отрисовкой своей собственной 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 строк.

Ответы [ 3 ]

10 голосов
/ 04 марта 2009

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

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

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

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

5 голосов
/ 04 марта 2009

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

0 голосов
/ 04 марта 2009

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

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

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

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

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

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

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

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

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

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

...