Discussion :

[nlc44]

Bonjour,

Il y a peut être d'autres moyens que GTK pour faire ça, mais il fallait bien que je commence par une première piste.

Je cherche à créer une zone graphique, qui afficherait des données binaires, provenant d'un fichier passé en paramètre de l'application.
Dans ce fichier, un octet représente 8 pixels, et donc chaque bit représente un pixel : bit à 0 = pixel blanc, bit à 1 = pixel noir.

Le fichier représente l'équivalent d'une image géante, et comme ce fichier peut faire plusieurs Go, il n'est pas possible de l'ouvrir en une seule fois, la zone graphique nécessaire serait beaucoup trop lourde.
L'idée serait de n'afficher qu'un morceau de "l'image binaire" dans la zone graphique définie, et pouvoir se déplacer dedans :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
 
+----------------------------+
|                            |
|                            |
|                            |
|   Fichier binaire          |
|                            |
|                            |
|                            |
|                            |
|+--------------------------+|
||                          ||
||                          ||
||                          ||
|| Fenetre d'affichage      ||
||                          ||
||                          ||
||                          ||
|+--------------------------+|
|                            |
|                            |
|                            |
|                            |
|                            |
|                            |
|                            |
|                            |
|                            |
|                            |
+----------------------------+

Sachant qu'il n'y aurait besoin de se déplacer que verticalement dans l'image, car la largeur de la fenêtre d'affichage fera toujours la même largeur en nombre de pixels que la largeur de "l'image binaire".
Dans le fichier, si par exemple je sais que la largeur de l'image est de 70656 pixels (soit 70656/8 = 8832 octets), et bien les 8832 premiers octets du fichier représentent la 1ere ligne de l'image, les 8832 suivants la seconde ligne, etc....
Un peu comme un frame buffer quoi. D'où mon idée de trouver une solution pour simuler un frame buffer dans une fenêtre graphique, avec la zone de donnée qui va avec, et simplement copier en brut les données du fichier dans la zone frame bufffer.
Et pour se déplacer de haut en bas dans l'image, il suffirait alors de se décaler par multiples de 8832 octets (selon mon exemple ci-dessus) dans le fichier et mettre à jour la zone framebuffer pour afficher les données correspondantes.

J'arrive à faire une partie du boulot avec Gimp, en ouvrant mes fichiers en mode raw en mode 1 bit noir et blanc, mais je ne peux ouvrir qu'une zone définie, il n'est pas possible de "se déplacer dedans" :



Quelqu'un aurait-il une idée un ou conseil sur la meilleur façon de faire ça ? D'habitude je fais plutôt du code embarqué et de la ligne de commande, les interfaces graphiques je nage un peu !

Bonne soirée !

[nlc44]

J'ai peut être une piste pour faire ce que je souhaite mais de façon détournée. Comme je tourne sous Linux, je me suis penché du côté du frame buffer et il existe des émulateurs de frame buffer par dessus X. Comme celui là : https://sixpak.org/fbe/
Du coup ça me permettrait de rester sur un soft de gestion en ligne de commande, qui a juste à ouvrir le fichier frame buffer, faire un mmap() dessus, et ensuite j'ai juste à copier mes données dedans pour les afficher.

[foetus]

il y a un format de fichiers pour cela - la famille pixmap: le portable pixmap file format (PPM), le portable graymap file format (PGM), le portable bitmap file format (PBM) et le portable anymap file format (PNM)

Lien wiki, Portable pixmap
Lien wiki en anglais, Netpbm le package linux


Donc , si tu as bien du raw (des paquets de 8 bits), essaye de rajouter 1 entête pour créer 1 image pbm (il faut calculer la hauteur, et tu dis que la largeur est de 70656).
Gimp sait lire ces images par défaut (mais à vérifier )

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
P4
70656 height
# your image below

[nlc44]

Afficher mes données binaires brutes ne pose en soi aucun problème, j'arrive très bien à les importer dans Gimp par exemple (voir ma capture d'écran). Mais le problème c'est qu'il est impossible d'ouvrir mon fichier de 8Go en une seule image.
Ca ferait par exemple une image de 73728 pixels de largeur par 108506 de hauteur. Mais je n'ai pas besoin de voir l'intégralité de l'image en une seule fois, voir seulement une zone de 73728x1500 par exemple est suffisant, en revanche il me faut une possibilité de décaler la zone que j'affiche pour pouvoir me "balader" dans le fichier.

[foetus]

Pour moi, il y a 1 problème quelque part

Soit tu copies-colles tes données sans dimensionner le calque Gimp correctement et donc tes données sont coupées au calque (Gimp devrait te prévenir)

Soit tu as un système 32 bits ou un système de fichiers obsolète, et tu ne peux pas avoir 1 fichier de plus de 4 gigas.
Ou alors, ton Gimp 32 bits ou ton système copié-collé ne peut pas importer toutes tes données et il en prend 1 partie (par exemple seulement 2 gigas)
Enfin tu n'as pas assez de mémoire RAM (<- d'ailleurs ton ordinateur ou ton système d'exploitation n'est pas en PLS justement )

C'est pour cela que je te proposais le format pixmap : tu as 1 fichier image facilement manipulable, et non pas 1 buffer copié-collé.
Mais 8 Gigas cela demande 1 système 64 bits avec 1 bonne quantité mémoire.

Et 1 autre idée, la compression. Tu parles de GTK, donc des bibliothèques C comme libjpeg ou MagickWand (ImageMagick) devrait te faire gagner en taille et en facilité de manipulation (tu auras toujours besoin d'1 bonne quantité mémoire ... et d'1 bon processeur )

[nlc44]

J'ai 16Go de RAM sur mon PC, j'ai un système 64bits, il n'y a pas de souci de ce coté là.
C'est juste qu'il est impossible d'ouvrir une telle image en entier, et je n'en ai pas l'utilité, je n'ai besoin que d'en voir une partie à la fois.
Là j'ai en exemple un fichier binaire de "seulement" 45Mo, qui contient l'équivalent d'une image de 73728 pixels x 5000 pixels. Car 1 octet = 8 pixels, donc chaque bloc de 9216 octets représente une ligne, et donc comme il y a 5000 lignes, 9216x5000 = environ 45Mo.
Et bien en ouvrant ce fichier avec Gimp, dans le mode qui convient à ce dont j'ai besoin (mode raw, 1 bit par pixel, noir et blanc), ça bouffe déjà plus de 4Go de mémoire :



Imagine si je devais ouvrir un fichier binaire de 8Go......c'est juste pas possible.

D'où mon besoin d'avoir une sorte de zone d'affichage qui ressemble à un frame buffer, qui n'affiche qu'une zone des données à la fois, sans charger complètement le fichier. Et si je veux afficher une autre partie du fichier dans cette zone, j'ai juste à y recopier les données correspondantes dans le fichier

[gerald3d]

Bonjour.

C'est tout à fait réalisable avec Gtk+. The Gimp étant un bel exemple de faisabilité .

Bien entendu allouer une taille d'affichage réelle n'est pas possible. Tu pourrais par exemple te cantonner à une portion de 2000x2000 par exemple. La coordonnée en haut à gauche de la portion pouvant aisément être convertie en position dans le fichier. Ton application pourrait ainsi te permettre de te déplacer par pas correspondant à la taille de la portion affichée. Vu que le fichier n'est pas volumineux tu peux le charger complétement en mémoire et l'agencer pour accéder à une portion de façon simple.

Je ne suis pas sûr d'être bien clair mais pour résumer c'est faisable.

[nlc44]

Oui comme j'ai utilisé Gimp pour mes premières expérimentations, c'est pour ça que j'ai commencé par envisager GTK+
C'est exactement ce que je souhaiterais faire, avoir une zone d'affichage de taille acceptable, et ensuite y placer les données en conséquence selon l'emplacement du fichier que je souhaite analyser.
Pour la résolution horizontale de la zone, je pense rester sur la largeur réelle qui correspond à celle des données (par exemple les 73728 pixels de mon exemple ci-dessus), car dans certains cas besoin de la voir en entier (en dé-zoommant comme on peut le faire avec Gimp). Ce qui permet en plus lors d'un déplacement vertical de copier dans la zone d'affichage depuis le fichier qu'un bloc continu de données.