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

Я работаю над пониманием и рисованием собственной DLL для PDF417 (двухмерные штрих-коды). Во всяком случае, фактическое изображение файла идеально и в правильных границах 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 строк.


person Community    schedule 04.03.2009    source источник


Ответы (3)


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

Обратите внимание на начало искажения с «0d».

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

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

person dirkgently    schedule 04.03.2009

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

person vartec    schedule 04.03.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. #P7# <блочная цитата> #P8#

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

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

person Community    schedule 04.03.2009