salut!

j'aimerais faire un programme qui convertit un fichier en image bitmap 8 bits la plus carrée possible pour en avoir une représentation graphique

un programme pas très utile pour s'entrainer a manipuler du bitmap, en fait, et j'en aurais bien besoin car y a des choses que je ne comprend pas très bien avec le bitmap

j'ai compris les 32 bits du header, mais c'est les données d'après que je ne comprend pas, elles sont organisées comment? ils parlent de tableau, avec des sauts de ligne a la fin, etc

vous vous y connaissez en bitmap, vous? merci d'avance de votre aide

Convertir "un fichier" en bitmap ne veut pas dire grand chose
Sinon, si c'est sous Windows, tout se fait avec l'api Win32
(demander sur le newsgroup professionnel des apis win32 :
news://fr.comp.os.ms-windows.programmation
où les bitmaps ont été détaillées en long et en large.
)

okay, merci beaucoup

mais par convertir un fichier en bitmap, je voulais dire afficher de manière graphique le contenu du fichier en l'encapsulant dans un bitmap, avec un header, une largeur et une longueur dont la multiplication donne la taille du fichier original, etc

On ne peut pas "encapsuler" quoi que ce soit dans du bitmap (comme on pourrait le faire dans un avi). Soit tu fichier d'origine est une image, et alors tu peut la convertir en bitmap si ce n'est pas déjà le format, soit, ce que tu veux faire est incompréhensible.

(Bon, on peut coder de l'information dans un bitmap, par exemple en utilisant les bits de poids faible de chaque pixel pour stocker un texte, mais je ne suis pas sûr que ce soit ce que tu cherche).

j'veux juste avoir une représentation visuelle des octets que contient mon fichier

en considérant le contenu du fichier comme la zone de données du bitmap

Sur ce topic : https://www.jeuxvideo.com/forums/1-31-8339600-1-0-1-0-0.htm

Lapintade donne un code qui permet d'enregistrer des images en .tga, c'est presque du bitmap mais avec un header plus simple. Reg

Regarde le code et (fonction SaveImage) pour écrire le header de ton fichier, puis calcule une taille pour un rectangle qui peut contenir les données de ton fichier, écrit les. Puis colle directement ton fichier, en tronquant les derniers octets s'il n'y en a pas un multiple de 4 (dans le cas où tu utilise le format avec des pixel 32 bits, mais tu peut choisir autre chose).

mmm sinon il y a le format pnm qui a une version ascii (la variante p1).
ca fait des fichiers tres gros, mais c'est facil a generer. et Gimp sais le lire. ou tu peux toujours utiliser un quelconque convertisseur d'image pour l'amener dans le format de ton choix.
des details sur:
http://www.fileformat.info/format/pbm/egff.htm

Cependantm je ne suis pas sur que faire une image soit vraiment ce que tu veux faire.
Peux etre devrait tu ouvrir une fenetre et rendre tes donnees dedans. ca te permetrait d'avoir une information en temps reel...

merci beaucoup les gars

j'ai fait un programme qui remplit une image .bmp avec des pixels de toutes les couleurs!

http://rafb.net/p/E9Wutb85.html

par contre, je vais m'en tenir là... le but du programme d'encapsulation d'un fichier dans un bmp avait pour but de détourner les circuits de compression d'images bitmap du compresseur paq8p et malgré sa puissance et sa lourdeur, il ne fait pas de miracles

mais maintenant, j'ai compris comment marche le format bmp

je ne sais pas comment marche paq8p, mais ca ne m'etonnes pas beaucoup.
Ce genre de compresseur repose sur le fait que se sont de vraies images que tu compresses. et donc que la difference de couleur entre deux pixel proche est tres faible.
meme si tu representes tes donnes comme une image, tu n'auras un bon taux de compression que si deux pixels proches ont des couleurs proches.

quoique justement... il vient de me réduire un .bmp aléatoire de 45 mo en une archive de quinze mo, là

je toast avec une image de 185 mo maintenant! dans six heures, il devrait avoir fini et là, je saurais si en fait, je continue la conversion de fichiers en bmp

(mais déja, 7-zip en 7z, ultra, bzip2, archive de taille solide a gagné seulement deux mo dessus)

c'est de la compression sans perte paq8p ?

comment generes tu ton jeux de donne aleatoire ?

purée, c'est dingue... il m'a réduit les 185 mo en 16 mo

je crois que c'est sans perte! là, je teste la décompression (il a fait la compression plus vite que je ne l'imaginais), et après, un hachage md5 sur l'image d'origine et la décompressée, et si les deux fichiers sont égaux, je continue l'encapsulation de fichiers en image, il y a moyen d'avoir de jolis taux de compression

les données sont générées avec un rand()%256 trois fois par pixels et initialisé par un srand(time(NULL)) (c'est du 24 bits), ca m'étonnerait qu'il aie trouvé une astuce a partir de là

selon comment rand est implemente, ca ne m'etonerait pas.
prends les 24 bits de poids forts plutot que les 3*8 bits de poids faible. Ils ont souvent une meilleure entropie.

d'accord, je vais essayer

sinon, quand a la décompression, le fichier après compression et décompression est exactement le même que celui d'origine, somme md5 a l'appui! mince alors, paq8p l'a compressé a 8% de sa taille d'origine, et c'est pourtant une image aléatoire

Mais tu sais que le format de compression paq n'est pas spécifique aux images ? Pire que ça, il utilise des heuristiques pour ses compressions qui dépendent du type de fichiers qu'il compresse (image, texte, exécutable, etc.) Donc en "encapsulant" tes données dans une image tu l'induit en erreur et tu obtiens certainement de plus mauvais résultat.

Si ça fonctionne tout de même, c'est que ce format de compression est censé être l'un des meilleurs qui existe (mais il n'est pas beaucoup utilisé car il est bien trop lent).

D'apres wikipeida, il ne fait pas semblant de consommer de la ram. En gros, 2Go la ou bzip2 en prenait 2 par contre il semblait plus rapide que bzip2 (sur le benchmark utilise)

oui, 1.7 go de ram utilisés a pleine charge, 17 heures pour compresser 500 mo de données brutes

par contre, il ne possède pas des heuristiques de compression pour tous les fichiers et c'est justement là que je veux essayer de détourner son fonctionnement

mais j'ai un problème, maintenant mon générateur d'images aléatoires ne me sort plus que des images en niveaux de rouges, vous pensez que c'est normal?

le bout de code qui remplit les lignes de l'image bitmap est devenu ca:

for(j=0;j<iLongueur;j++) //iLongueur=longueur en pixels, codés sur trois octets
{
iEntier=rand()%4294967295;

szLigne[(j*3)]=(char)(iEntier/(256*256*256));

szLigne[(j*3)+1]=(char)((iEntier/(256*256))%2
56);
szLigne[(j*3)+2]=(char)((iEntier/256)%256);
}

(c'est pas très joli, mais c'est pour l'expérience )

rand() renvoie un nombre compris entre 0 et RAND_MAX, or je crois que rand_max est de l'ordre de 2^16, donc dès que tu divise par 256*256, il ne te reste que 0. À noter, que c'est inutile, car tu peut diviser par 1, 256 et 256*256 (il restera toujours une teinte à 0, mais pas deux sur trois).

Si le compresseur n'a pas d'heuristique pour tout les type de fichier, je ne pense pas qu'il fera mieux en utilisant ceux pour les images, plutôt que les heuristiques générale qui sont sélectionné par des reseaux de neurones.