Retrouver une image à partir du fichier .c

International Français
1

Bonjour à toutes et à tous,

Pour afficher un bitmap avec un OLED, on transforme le fichier bitmap en fichier c.

Quel est le moyen pour faire le chemin inverse ?

J'ai un fichier c, je voudrais en déduire le bitmap correspondant. Exemple :

// Battery.c
// Font type    : Battery levels (5 icons)
// Font size    : 20x28 pixels
// Memory usage : 105 bytes

#include <avr/pgmspace.h>

const uint8_t Battery[] PROGMEM={
  0x7f, 0xff, 0xf0, 
  0x40, 0x00, 0x10, 
  0xdd, 0xdd, 0xd0, 
  0xdd, 0xdd, 0xd0, 
  0xdd, 0xdd, 0xd0, 
  0x40, 0x00, 0x10, 
  0x7f, 0xff, 0xf0, 
  0x7f, 0xff, 0xf0, 
  0x40, 0x00, 0x10, 
  0xc1, 0xdd, 0xd0, 
  0xc1, 0xdd, 0xd0, 
  0xc1, 0xdd, 0xd0, 
  0x40, 0x00, 0x10, 
  0x7f, 0xff, 0xf0, 
  0x7f, 0xff, 0xf0, 
  0x40, 0x00, 0x10, 
  0xc0, 0x1d, 0xd0, 
  0xc0, 0x1d, 0xd0, 
  0xc0, 0x1d, 0xd0, 
  0x40, 0x00, 0x10, 
  0x7f, 0xff, 0xf0, 
  0x7f, 0xff, 0xf0, 
  0x40, 0x00, 0x10, 
  0xc0, 0x01, 0xd0, 
  0xc0, 0x01, 0xd0, 
  0xc0, 0x01, 0xd0, 
  0x40, 0x00, 0x10, 
  0x7f, 0xff, 0xf0,
  0x7f, 0xff, 0xf0, 
  0x40, 0x00, 0x10, 
  0xc0, 0x00, 0x10, 
  0xc0, 0x00, 0x10, 
  0xc0, 0x00, 0x10, 
  0x40, 0x00, 0x10, 
  0x7f, 0xff, 0xf0
};

Dans ma grande bonté :wink:, je vous donne le résultat :

Batterie

Cordialement.

Pierre.

2

Tu as 35 lignes de 3 octets dans ton vecteur, et ton image est en 20 x 7 pixels, donc il doit y avoir un codage quelque part. Je veux dire que ce n'est pas juste la liste des octets.

Une solution est d'utiliser les fonctions présentes dans la bibliothèque Adafruit GFX : elles sont listées dans ce message

Dès qu'une image apparait, tu auras trouvé la bonne !

Si tu fais tes images toi-même, tu peux aussi faire ton affichage toi-même. Pour une image monochrome de 7 octets verticaux, tu peux coder tes valeurs (0 ou 1 pour éteint ou allumé) dans un seul octet et ton image tiendra dans un vecteur de 20 octets. C'est bien plus compact que 105 !
Et pour les afficher, tu décodes et tu affiches les pixels un par un, colonne par colonne.

3

Non - pas vraiment :slight_smile:

image
image783×642 51 KB

le code pour voir le résultat : afficheBitmap - Wokwi ESP32, STM32, Arduino Simulator

cela dit, le code qui est au dessus laisse à penser que c'est une police de caractère. Comment avez vous obtenu ce fichier ?

4

Si j'ai posé la question, c'est que ce n'est pas moi qui a fait ce dessin. Cela fait plus de quatre ans que je l'utilise ; j'ai dû le ramasser sur la toile, ne me demandez pas où. Mais c'est sioux !
Comme le montre J-M-L, ce sont cinq images placées dans un seul fichier. Celui du haut montre une batterie chargée et les quatre suivant, une batterie de plus en plus déchargée (le dernier, que ne montre pas J-M-L, n'a plus de petit carré).

Comment lire le fichier : les trois premiers octets (un "1" est blanc et un "0" est noir) représentent la première ligne. Mais celle-ci ne comprenant que vingt points, les quatre bits de reste du troisième octets sont ignorés.
On passe au quatrième, cinquième et sixième octets qui représentent la deuxième ligne ; les quatre bits du sixième octet sont ignorés.
Et ainsi de suite jusqu'à la dernière ligne et j’arrive donc à 7 lignes de trois octets = 21 octets. Mais que sont donc les suivants ? Et bien, ce sont les octets des quatre images suivantes.

L'interprétation des octets est donc assujettie aux dimension de l'image (20 x 7).

Si j'ai posé la question, c'est aussi parce que je ne comprenais pas les lignes suivantes :

  if (vcc > V_BAT_MIN + 250) display.drawBitmap(x, y,  Battery, 20, 7, SSD1306_WHITE, SSD1306_BLACK); // 2.95 V
  else if (vcc > V_BAT_MIN + 150) display.drawBitmap(x, y,  Battery + 21, 20, 7, SSD1306_WHITE, SSD1306_BLACK); // 2.85 V
  else if (vcc > V_BAT_MIN + 50) display.drawBitmap(x, y,  Battery + 42, 20, 7, SSD1306_WHITE, SSD1306_BLACK); // 2.75 V
  else if (vcc > V_BAT_MIN) display.drawBitmap(x, y,  Battery + 63, 20, 7, SSD1306_WHITE, SSD1306_BLACK); // 2.7 V
  else display.drawBitmap(x, y,  Battery + 84, 20, 7, SSD1306_WHITE, SSD1306_BLACK); // < 2.7 V : Changer la batterie

Que venait faire l'ajout de 21, 42, 63, 84 à la valeur "Battery". En fait cela représente un offset de lecture dans le fichier (21 octets par image) pour aller chercher la bonne.

Bon ben tiens, je ne suis pas mécontent de moi :slightly_smiling_face: , mais je ne me prends pas pour Alan Turing :upside_down_face:.

Cordialement.

Pierre.

5

C’est ce qui compte ! :wink:

6

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.