L'écriture de données BMP se ramollit

Question

Je travaille à comprendre et à dessiner ma propre DLL pour PDF417 (codes à barres 2d). Quoi qu'il en soit, le dessin réel du fichier est parfait, avec des limites correctes de 32 bits (en résultat monochrome). Au moment de l'écriture des données, voici une image mémoire copiée à partir de l'image mémoire C ++ Visual Studio du pointeur sur le tampon bmp. Chaque ligne est correctement attribuée à une largeur de 36 avant la ligne suivante.

Désolé pour le wordwrap dans le message, mais ma sortie devait avoir la même largeur de 36 octets que le vidage de la mémoire afin que vous puissiez mieux voir la distorsion.

Le dessin actuel fait 273 pixels de large sur 12 pixels de haut, 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

Voici le code pour ÉCRIRE le fichier - verbatim immédiatement au moment du vidage mémoire ci-dessus

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

Voici ce qui est réellement écrit dans le fichier.

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

Notez le début de la distorsion avec le signe "0d". dans le résultat de la lecture du fichier à la 4ème ligne, environ le 15e octet terminé ... Ensuite, il y en a quelques autres plus décalés autour desquels, au total, décalez l'image de 9 octets ...

Évidemment, la partie de dessin fonctionne correctement car tout reste correctement aligné en mémoire pour les 12 lignes.

Answer 1

Ne devez-vous pas ouvrir le fichier en mode composé, c’est-à-dire qu’il est accessible en écriture & amp; binaire comme dans wb + ?

  

Notez le début de la distorsion avec le "0d"

Il s’agit du code ASCII pour Carriage Return (CR) - ajouté sur certains systèmes d’exploitation avec newline (où une nouvelle ligne est en réalité une séquence de CR / LF). Cela devrait disparaître une fois que vous avez commencé à écrire la sortie en mode binaire.

Sinon, votre code est soigné. À la vôtre!

Answer 2

Votre 0x0A ( \ n ) est converti au format DOS 0x0D0A ( \ r \ n ), parce que vous écrivez le fichier en mode texte. Passez en mode binaire.

Answer 3

Je viens de faire une chose similaire en Java (imprimer des données BMP sur une imprimante à reçu thermique). Je souhaite partager quelques points avec vous:

1. Données d'image bmp! = un format d'image de Microsoft. la bitmap MS a environ 54 octets d’informations d’en-tête avant les données d’image. (J'ai passé un jour ou deux à travailler dessus avant de réaliser la différence)

2. Les données d'image bmp sont lues de gauche à droite, de haut en bas, avec le bit le plus significatif à gauche.

3. assurez-vous que l’image du code à barres a une profondeur de 1. Cela signifie 1 bit = 1 pixel. hexidécimal " ab " 10101011 en binaire, ces 8 pixels seront remplis en conséquence.

4. si vous avez un code à barres large de 36 octets, sa résolution est de 288 x 12 et non de 273 x 12. (36 * 8 = 288).

5. la taille des données d'image doit être de 432 octets (12 lignes de 36 octets).

6. je ne sais pas ce que cela signifie:

     

   Quoi qu'il en soit, le dessin du fichier est parfait, avec des limites correctes de 32 bits (comme résultat monochrome).

monochrome signifie sa couleur ou une autre. le pixel (pense le bit) est rempli ou ce n'est pas.

J'espère que cela vous aidera